RE: TAP

["Santosh Chokhani" <[e-mail]>]

Steve and Stephan:

The TAP protocol is not about rights to access data.  It is based on using
PKI to provide long-term non-repudiation of information.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Kent
Sent: Monday, March 31, 2003 6:01 PM
To: Stefan Santesson
Cc: [e-mail]
Subject: Re: TAP



At 12:27 AM +0200 4/1/03, Stefan Santesson wrote:
>I'm not sure, but is strikes me that the efforts of the OASIS Rights
>Language TC http://www.oasis-open.org/committees/rights/charter.php
>might be used as a protocol framework to exercise rights over 
>information and policies/conditions for its archival and retrieval. 
>All supported by PKI based authentications of rights holders and 
>licensees.
>
>It would be interesting if anyone else has more deep knowledge about 
>this.
>
>/Stefan

Well, I would not like to become embroiled in any schemes that focus 
on DRM, or to depend on them for archive.  I think the two are very 
separate functions, and even through there may be functions in DRM 
that make use of archive, I would not want to make use of trusted 
archive depend on adoption of DRM technologies, given the generally 
very negative perception associated with DRM.

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h310KDJM020550 for <[e-mail]>; Mon, 31 Mar 2003 16:20:13 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h310KDnu020549 for ietf-pkix-bks; Mon, 31 Mar 2003 16:20:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h310KCJM020530 for <[e-mail]>; Mon, 31 Mar 2003 16:20:12 -0800 (PST)
Received: from chokhani (92.washington-15rh16rt.dc.dial-access.att.net[12.91.133.92]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030401002009112008q5hne>; Tue, 1 Apr 2003 00:20:09 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: TAP
Date: Mon, 31 Mar 2003 19:20:33 -0500
Message-ID: <004001c2f7e4$82e19060$ad00a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <p0510031abaae758c5a87@[128.89.88.34]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve and Stephan:

The TAP protocol is not about rights to access data.  It is based on using
PKI to provide long-term non-repudiation of information.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Kent
Sent: Monday, March 31, 2003 6:01 PM
To: Stefan Santesson
Cc: [e-mail]
Subject: Re: TAP



At 12:27 AM +0200 4/1/03, Stefan Santesson wrote:
>I'm not sure, but is strikes me that the efforts of the OASIS Rights
>Language TC http://www.oasis-open.org/committees/rights/charter.php
>might be used as a protocol framework to exercise rights over 
>information and policies/conditions for its archival and retrieval. 
>All supported by PKI based authentications of rights holders and 
>licensees.
>
>It would be interesting if anyone else has more deep knowledge about 
>this.
>
>/Stefan

Well, I would not like to become embroiled in any schemes that focus 
on DRM, or to depend on them for archive.  I think the two are very 
separate functions, and even through there may be functions in DRM 
that make use of archive, I would not want to make use of trusted 
archive depend on adoption of DRM technologies, given the generally 
very negative perception associated with DRM.

Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VN88JM017318 for <[e-mail]>; Mon, 31 Mar 2003 15:08:08 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VN886D017317 for ietf-pkix-bks; Mon, 31 Mar 2003 15:08:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VN86JM017310 for <[e-mail]>; Mon, 31 Mar 2003 15:08:06 -0800 (PST)
Received: from tsg1 (194.sanfrancisco-12rh16rt-ca.dial-access.att.net[12.81.119.194]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030331230752112008qkbbe>; Mon, 31 Mar 2003 23:07:52 +0000
From: "todd glassey" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>
Subject: RE: TAP
Date: Mon, 31 Mar 2003 15:07:14 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

THERE IS NO REASON THAT TAP CANNOT BE REPRESENTED IN XML -
IT IS MERELY AN ENCODING MODEL.

Todd.

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Stefan
Santesson
Sent: Monday, March 31, 2003 11:35 AM
To: [e-mail]
Subject: Re: TAP



Steve,

Some thoughts and questions, if you could elaborate.

Doesn't this come very close to the aspects of reality that
would be
suitable for OASIS, if it wasn't for the fact that TAP as
proposed is based
on ASN.1 and not XML.?

Has then PKIX become the body for ASN.1 based application
standards for
anything related to PKI?
Had this been suitable for PKIX if the proposed protocol was
XML based?

/Stefan

At 12:39 2003-03-28 -0500, Stephen Kent wrote:

>At 10:51 AM +0000 3/28/03, Stephen Farrell wrote:
>>Hi Steve,
>>
>>>  I think there is a big distinction between the TAP
proposal and the
>>>  Diameter & SIP work you suggest. TAP is an
infrastructure element,
>>>  potentially supportive
>>>    of a wide range of applications that require archive.
SIP and
>>>  Diameter are specific applications.
>>
>>That's true - but I wasn't suggesting otherwise.
>>
>>>  Our philosophy in PKIX has been
>>>  to let each application develop its own profile(s) for
use of PKI in
>>>  the corresponding WG. S/MIME did that, as did TLS, and
now IPsec. So,
>>
>>Also true, and here's where we probably disagree a bit. I
think we'd
>>be better served by moving focus now away from developing
new bits of
>>infrastructure and towards helping applications make use
of PKI.
>
>I don't disagree with the need for helping apps make use of
PKI. The
>question is whether this should be done in PKIX, another
PKI-centric WG,
>or by having PKI experts participate in the target WGs. I'm
open to
>suggestions, but we have tended toward the latter, after
initially
>adopting the first approach, e.g., we removed extended key
usage
>definitions for apps from our profile.
>
>>The examples you raise are interesting:
>>
>>- They're all security WGs!! As infrastructure PKI is much
more widely
>>   applicable
>>- I think its fair to say they've done a mixed job in
terms of
>>   how well they've managed to integrate PKI and how long
it took
>>- Those groups have fairly good overlap with PKIX in terms
of active
>>   people, which isn't the case generally
>
>agree with all of these observations.
>
>>All of which tell me that some concerted "PKI help" for (a
>>constrained-in-the-charter range of) other
WGs/applications/protocols
>>might be appropriate at this point.
>
>That's one approach, but why charter a WG to help these
apps, rather than
>asking interested parties to work with the WGs for the apps
of interest?
>
>>  > I would not consider the examples you suggested as
appropriate for
>>>  PKIX
>>
>>I wasn't suggesting PKIX take on those work items. I was
seconding
>>Peter's implied suggestion that we charter a new PKIXAPPS
WG to tackle
>>such issues. (Of course, another reasonable approach could
be to
>>try charter a WG to generally tackle key management for a
named
>>bunch of IETF protocols - that WG could then make PKI
and/or
>>Kerberos and/or whatever decisions for each such
protocol - which
>>sounds like a good venue for bun-fights, but not much
else:-)
>
>That's sort of what I worry about, i.e., trying to solve
problems for an
>app requires considerable knowledge of the app, and that
knowledge is
>generally held by the app WG.
>
>>
>>>  or for any other PKI-centric WG.
>>
>>A putative PKIXAPPS would be PKI centric and would
therefore be an
>>appropriate venue for such work.
>
>I am doubtful of this approach, but you should bring it to
the security
>ADs if you want to pursue it.
>
>Steve

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone]




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VN1HJM017189 for <[e-mail]>; Mon, 31 Mar 2003 15:01:17 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VN1HcE017188 for ietf-pkix-bks; Mon, 31 Mar 2003 15:01:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VN1GJM017165 for <[e-mail]>; Mon, 31 Mar 2003 15:01:16 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2VN175w011576; Mon, 31 Mar 2003 18:01:07 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510031abaae758c5a87@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 31 Mar 2003 18:01:26 -0500
To: Stefan Santesson <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: TAP
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:27 AM +0200 4/1/03, Stefan Santesson wrote:
>I'm not sure, but is strikes me that the efforts of the OASIS Rights 
>Language TC http://www.oasis-open.org/committees/rights/charter.php
>might be used as a protocol framework to exercise rights over 
>information and policies/conditions for its archival and retrieval. 
>All supported by PKI based authentications of rights holders and 
>licensees.
>
>It would be interesting if anyone else has more deep knowledge about this.
>
>/Stefan

Well, I would not like to become embroiled in any schemes that focus 
on DRM, or to depend on them for archive.  I think the two are very 
separate functions, and even through there may be functions in DRM 
that make use of archive, I would not want to make use of trusted 
archive depend on adoption of DRM technologies, given the generally 
very negative perception associated with DRM.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VMTKJM014937 for <[e-mail]>; Mon, 31 Mar 2003 14:29:20 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VMTKER014936 for ietf-pkix-bks; Mon, 31 Mar 2003 14:29:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from vmmr8.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VMTIJM014932 for <[e-mail]>; Mon, 31 Mar 2003 14:29:18 -0800 (PST)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr8.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AJD06791; Mon, 31 Mar 2003 17:29:15 -0500 (EST)
Received: from laptop-cpq.retrospekt.com (1Cust113.tnt1.stk3.swe.da.uu.net [213.116.224.113]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ACX41397; Mon, 31 Mar 2003 17:29:13 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 01 Apr 2003 00:29:09 +0200
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: TAP
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm not sure, but is strikes me that the efforts of the OASIS Rights 
Language TC http://www.oasis-open.org/committees/rights/charter.php
might be used as a protocol framework to exercise rights over information 
and policies/conditions for its archival and retrieval. All supported by 
PKI based authentications of rights holders and licensees.

It would be interesting if anyone else has more deep knowledge about this.

/Stefan

At 15:28 2003-03-31 -0500, Stephen Kent wrote:
>>Steve,
>>
>>Some thoughts and questions, if you could elaborate.
>>
>>Doesn't this come very close to the aspects of reality that would be 
>>suitable for OASIS, if it wasn't for the fact that TAP as proposed is 
>>based on ASN.1 and not XML.?
>>
>>Has then PKIX become the body for ASN.1 based application standards for 
>>anything related to PKI?
>>Had this been suitable for PKIX if the proposed protocol was XML based?
>>
>>/Stefan
>
>Stefan,
>
>I am not sufficiently familiar with OASIS to know if this overlaps their 
>work, other than in choice of syntax. Even if that's true, PKIX has stayed 
>with ASN.1, while other folks have pursued XML, and I think it is still 
>reasonable to do that given the ASN.1 basis for our other protocols.
>
>Steve

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone]  



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VJbOJM005315 for <[e-mail]>; Mon, 31 Mar 2003 11:37:24 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VJbOVA005314 for ietf-pkix-bks; Mon, 31 Mar 2003 11:37:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from vmmr9.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VJbMJM005309 for <[e-mail]>; Mon, 31 Mar 2003 11:37:22 -0800 (PST)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr9.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id PDB81739; Mon, 31 Mar 2003 14:35:05 -0500 (EST)
Received: from laptop-cpq.retrospekt.com (1Cust154.tnt1.stk3.swe.da.uu.net [213.116.224.154]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ACX05728; Mon, 31 Mar 2003 14:34:59 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 31 Mar 2003 21:34:54 +0200
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: TAP
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>

Steve,

Some thoughts and questions, if you could elaborate.

Doesn't this come very close to the aspects of reality that would be 
suitable for OASIS, if it wasn't for the fact that TAP as proposed is based 
on ASN.1 and not XML.?

Has then PKIX become the body for ASN.1 based application standards for 
anything related to PKI?
Had this been suitable for PKIX if the proposed protocol was XML based?

/Stefan

At 12:39 2003-03-28 -0500, Stephen Kent wrote:

>At 10:51 AM +0000 3/28/03, Stephen Farrell wrote:
>>Hi Steve,
>>
>>>  I think there is a big distinction between the TAP proposal and the
>>>  Diameter & SIP work you suggest. TAP is an infrastructure element,
>>>  potentially supportive
>>>    of a wide range of applications that require archive. SIP and
>>>  Diameter are specific applications.
>>
>>That's true - but I wasn't suggesting otherwise.
>>
>>>  Our philosophy in PKIX has been
>>>  to let each application develop its own profile(s) for use of PKI in
>>>  the corresponding WG. S/MIME did that, as did TLS, and now IPsec. So,
>>
>>Also true, and here's where we probably disagree a bit. I think we'd
>>be better served by moving focus now away from developing new bits of
>>infrastructure and towards helping applications make use of PKI.
>
>I don't disagree with the need for helping apps make use of PKI. The 
>question is whether this should be done in PKIX, another PKI-centric WG, 
>or by having PKI experts participate in the target WGs. I'm open to 
>suggestions, but we have tended toward the latter, after initially 
>adopting the first approach, e.g., we removed extended key usage 
>definitions for apps from our profile.
>
>>The examples you raise are interesting:
>>
>>- They're all security WGs!! As infrastructure PKI is much more widely
>>   applicable
>>- I think its fair to say they've done a mixed job in terms of
>>   how well they've managed to integrate PKI and how long it took
>>- Those groups have fairly good overlap with PKIX in terms of active
>>   people, which isn't the case generally
>
>agree with all of these observations.
>
>>All of which tell me that some concerted "PKI help" for (a
>>constrained-in-the-charter range of) other WGs/applications/protocols
>>might be appropriate at this point.
>
>That's one approach, but why charter a WG to help these apps, rather than 
>asking interested parties to work with the WGs for the apps of interest?
>
>>  > I would not consider the examples you suggested as appropriate for
>>>  PKIX
>>
>>I wasn't suggesting PKIX take on those work items. I was seconding
>>Peter's implied suggestion that we charter a new PKIXAPPS WG to tackle
>>such issues. (Of course, another reasonable approach could be to
>>try charter a WG to generally tackle key management for a named
>>bunch of IETF protocols - that WG could then make PKI and/or
>>Kerberos and/or whatever decisions for each such protocol - which
>>sounds like a good venue for bun-fights, but not much else:-)
>
>That's sort of what I worry about, i.e., trying to solve problems for an 
>app requires considerable knowledge of the app, and that knowledge is 
>generally held by the app WG.
>
>>
>>>  or for any other PKI-centric WG.
>>
>>A putative PKIXAPPS would be PKI centric and would therefore be an
>>appropriate venue for such work.
>
>I am doubtful of this approach, but you should bring it to the security 
>ADs if you want to pursue it.
>
>Steve

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone]  



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VGrEJM028789 for <[e-mail]>; Mon, 31 Mar 2003 08:53:14 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VGrE0Z028788 for ietf-pkix-bks; Mon, 31 Mar 2003 08:53:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from vmmr7.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VGrCJM028781 for <[e-mail]>; Mon, 31 Mar 2003 08:53:12 -0800 (PST)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id OTN60298; Mon, 31 Mar 2003 11:53:12 -0500 (EST)
Received: from laptop-cpq.retrospekt.com (1Cust12.tnt13.stk3.swe.da.uu.net [213.116.251.12]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ACW71877; Mon, 31 Mar 2003 11:53:09 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 31 Mar 2003 18:53:05 +0200
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: TAP
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>

Steve,

Some thoughts and questions, if you could elaborate.

Doesn't this come very close to the aspects of reality that would be 
suitable for OASIS, if it wasn't for the fact that TAP as proposed is based 
on ASN.1 and not XML.?

Has then PKIX become the body for ASN.1 based application standards for 
anything related to PKI?
Had this been suitable for PKIX if the proposed protocol was XML based?

/Stefan

At 12:39 2003-03-28 -0500, Stephen Kent wrote:

>At 10:51 AM +0000 3/28/03, Stephen Farrell wrote:
>>Hi Steve,
>>
>>>  I think there is a big distinction between the TAP proposal and the
>>>  Diameter & SIP work you suggest. TAP is an infrastructure element,
>>>  potentially supportive
>>>    of a wide range of applications that require archive. SIP and
>>>  Diameter are specific applications.
>>
>>That's true - but I wasn't suggesting otherwise.
>>
>>>  Our philosophy in PKIX has been
>>>  to let each application develop its own profile(s) for use of PKI in
>>>  the corresponding WG. S/MIME did that, as did TLS, and now IPsec. So,
>>
>>Also true, and here's where we probably disagree a bit. I think we'd
>>be better served by moving focus now away from developing new bits of
>>infrastructure and towards helping applications make use of PKI.
>
>I don't disagree with the need for helping apps make use of PKI. The 
>question is whether this should be done in PKIX, another PKI-centric WG, 
>or by having PKI experts participate in the target WGs. I'm open to 
>suggestions, but we have tended toward the latter, after initially 
>adopting the first approach, e.g., we removed extended key usage 
>definitions for apps from our profile.
>
>>The examples you raise are interesting:
>>
>>- They're all security WGs!! As infrastructure PKI is much more widely
>>   applicable
>>- I think its fair to say they've done a mixed job in terms of
>>   how well they've managed to integrate PKI and how long it took
>>- Those groups have fairly good overlap with PKIX in terms of active
>>   people, which isn't the case generally
>
>agree with all of these observations.
>
>>All of which tell me that some concerted "PKI help" for (a
>>constrained-in-the-charter range of) other WGs/applications/protocols
>>might be appropriate at this point.
>
>That's one approach, but why charter a WG to help these apps, rather than 
>asking interested parties to work with the WGs for the apps of interest?
>
>>  > I would not consider the examples you suggested as appropriate for
>>>  PKIX
>>
>>I wasn't suggesting PKIX take on those work items. I was seconding
>>Peter's implied suggestion that we charter a new PKIXAPPS WG to tackle
>>such issues. (Of course, another reasonable approach could be to
>>try charter a WG to generally tackle key management for a named
>>bunch of IETF protocols - that WG could then make PKI and/or
>>Kerberos and/or whatever decisions for each such protocol - which
>>sounds like a good venue for bun-fights, but not much else:-)
>
>That's sort of what I worry about, i.e., trying to solve problems for an 
>app requires considerable knowledge of the app, and that knowledge is 
>generally held by the app WG.
>
>>
>>>  or for any other PKI-centric WG.
>>
>>A putative PKIXAPPS would be PKI centric and would therefore be an
>>appropriate venue for such work.
>
>I am doubtful of this approach, but you should bring it to the security 
>ADs if you want to pursue it.
>
>Steve

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone]  



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VC7uJM008939 for <[e-mail]>; Mon, 31 Mar 2003 04:07:56 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VC7uuF008938 for ietf-pkix-bks; Mon, 31 Mar 2003 04:07:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VC7sJM008929 for <[e-mail]>; Mon, 31 Mar 2003 04:07:55 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h2VC7koU016916; Tue, 1 Apr 2003 00:07:46 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h2VC7lZ14371; Tue, 1 Apr 2003 00:07:47 +1200
Date: Tue, 1 Apr 2003 00:07:47 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: The case against directories
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Hallam-Baker, Phillip" <[e-mail]> writes:

>It depends whether you consider the job of the IETF to be the design of
>protocols that can be secure when deployed by experts or whether we should
>develop protocols that are robust when deployed in real world situations.

Quote from my home page, from someone who's had to work with PKI as a user:

  I think a lot of purists would rather have PKI be useless to anyone in any
  practical terms than to have it made simple enough to use, but potentially
  "flawed" -- although by definition, it's pretty "flawed".
         -- Chris Zimman.

>>What are the problems that really need the attention of the IETF?
>
>I think that we need to address the problem of how the whole PKI architecture
>hangs together in a document that can be understood by the people who are
>actually on the front lines.

I tried to do something like this in "PKI: It's not dead, just resting" (see
the link on my home page), which is intended to provide advice to someone who,
having had a pile of PKI odds and ends dumped on them, needs to figure out the
most expedient way of making it all work.  What might be useful though is an
RFC pointing out the 80-90% of most PKI RFCs that can be safely ignored with
no noticeable impact on functionality (except to make things much, much easier
to work with), a bit like the style guide does but more as an RFC than a
conversational document.

Take for example constraint extensions, which I discussed with someone
recently.  He was after some examples to test some code against.  Now in my
sizeable collection of weird and wonderful certs from all over the world I've
never come across a cert which has name constraints, policy constraints, and a
pile of other things in them.  I did generate some test certs years ago when I
was trying to find anything that would pay attention to them (I wasn't
successful), but that's all.  He eventually generated his own certs with some
constraints in them, and all I can say is that anyone putting these things in
certs better not be counting on any specific behaviour from PKI applications.
As someone once suggested for the NR keyUsage bit, CAs should set these
extensions at random to dispel the illusion that their presence has any useful
meaning for PKI software.

I'm sure I could distil something like RFC 3280 down to about 10 pages to make
it match the real world (well, maybe 15 with IETF boilerplate).  For example,
all coverage of character set issues and DN encodings and matching rules could
be simplified to:

  Encode/decode with memcpy().  Compare with memcmp().

which is what everydone does in practice anyway, and you get reliable/
repeatable behaviour with those rules as well (that is, it's difficult to get
something that simple wrong).  You can guess what the text for the kitchenSink
extension would be.  For most of the other extensions (name constraints,
policy constraints, policy mappings, etc etc) it'd just be "Don't rely on
these for anything, but if you want the details see 3280".  In fact the only
extension that really matters in practice, and that almost all PKI software
gets right so you can actually rely on it when you put it in a cert, is
keyUsage (basicConstraints can be inferred from that so even that isn't
needed).  You'd just need some rigorous text covering keyUsage, and a few
simple tests your app could do to make sure it's getting it right - checking
compliance would be fairly trivial, either you pass or you don't.

Yeah, I think 15 pages should about do it...

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VABgJM000829 for <[e-mail]>; Mon, 31 Mar 2003 02:11:42 -0800 (PST)
Received: (from majordomo@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h2VABgUU000828 for ietf-pkix-bks; Mon, 31 Mar 2003 02:11:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordomo set sender to [e-mail] using -f
Received: from vmmr8.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.12.9/8.11.6) with ESMTP id h2VABdJM000823 for <[e-mail]>; Mon, 31 Mar 2003 02:11:40 -0800 (PST)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr8.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AJC22379; Mon, 31 Mar 2003 05:11:38 -0500 (EST)
Received: from laptop-cpq.retrospekt.com (1Cust236.tnt6.stk3.swe.da.uu.net [213.116.236.236]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ACW21327 (AUTH [e-mail]); Mon, 31 Mar 2003 05:11:35 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 31 Mar 2003 12:11:30 +0200
To: Stephen Kent <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: TAP
Cc: [e-mail]
In-Reply-To: <p05111a02baaa37c65d41@[128.33.238.253]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <p05111a04baa8c1a2f7dd@[10.4.58.234]> <[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>

Steve,

Some thoughts and questions, if you could elaborate.

Doesn't this come very close to the aspects of reality that would be 
suitable for OASIS, if it wasn't for the fact that TAP as proposed is based 
on ASN.1 and not XML.?

Has then PKIX become the body for ASN.1 based application standards for 
anything related to PKI?
Had this been suitable for PKIX if the proposed protocol was XML based?

/Stefan

At 12:39 2003-03-28 -0500, Stephen Kent wrote:

>At 10:51 AM +0000 3/28/03, Stephen Farrell wrote:
>>Hi Steve,
>>
>>>  I think there is a big distinction between the TAP proposal and the
>>>  Diameter & SIP work you suggest. TAP is an infrastructure element,
>>>  potentially supportive
>>>    of a wide range of applications that require archive. SIP and
>>>  Diameter are specific applications.
>>
>>That's true - but I wasn't suggesting otherwise.
>>
>>>  Our philosophy in PKIX has been
>>>  to let each application develop its own profile(s) for use of PKI in
>>>  the corresponding WG. S/MIME did that, as did TLS, and now IPsec. So,
>>
>>Also true, and here's where we probably disagree a bit. I think we'd
>>be better served by moving focus now away from developing new bits of
>>infrastructure and towards helping applications make use of PKI.
>
>I don't disagree with the need for helping apps make use of PKI. The 
>question is whether this should be done in PKIX, another PKI-centric WG, 
>or by having PKI experts participate in the target WGs. I'm open to 
>suggestions, but we have tended toward the latter, after initially 
>adopting the first approach, e.g., we removed extended key usage 
>definitions for apps from our profile.
>
>>The examples you raise are interesting:
>>
>>- They're all security WGs!! As infrastructure PKI is much more widely
>>   applicable
>>- I think its fair to say they've done a mixed job in terms of
>>   how well they've managed to integrate PKI and how long it took
>>- Those groups have fairly good overlap with PKIX in terms of active
>>   people, which isn't the case generally
>
>agree with all of these observations.
>
>>All of which tell me that some concerted "PKI help" for (a
>>constrained-in-the-charter range of) other WGs/applications/protocols
>>might be appropriate at this point.
>
>That's one approach, but why charter a WG to help these apps, rather than 
>asking interested parties to work with the WGs for the apps of interest?
>
>>  > I would not consider the examples you suggested as appropriate for
>>>  PKIX
>>
>>I wasn't suggesting PKIX take on those work items. I was seconding
>>Peter's implied suggestion that we charter a new PKIXAPPS WG to tackle
>>such issues. (Of course, another reasonable approach could be to
>>try charter a WG to generally tackle key management for a named
>>bunch of IETF protocols - that WG could then make PKI and/or
>>Kerberos and/or whatever decisions for each such protocol - which
>>sounds like a good venue for bun-fights, but not much else:-)
>
>That's sort of what I worry about, i.e., trying to solve problems for an 
>app requires considerable knowledge of the app, and that knowledge is 
>generally held by the app WG.
>
>>
>>>  or for any other PKI-centric WG.
>>
>>A putative PKIXAPPS would be PKI centric and would therefore be an
>>appropriate venue for such work.
>
>I am doubtful of this approach, but you should bring it to the security 
>ADs if you want to pursue it.
>
>Steve

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone] 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SMUTU24170 for ietf-pkix-bks; Fri, 28 Mar 2003 14:30:29 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2SMUSg24166 for <[e-mail]>; Fri, 28 Mar 2003 14:30:28 -0800 (PST)
Received: (qmail 18726 invoked from network); 28 Mar 2003 22:30:04 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.216.48) by woodstock.binhost.com with SMTP; 28 Mar 2003 22:30:04 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 28 Mar 2003 17:20:51 -0500
To: "Hallam-Baker, Phillip" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: The case against directories
Cc: [e-mail]
In-Reply-To: <[e-mail] .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>

Phil:

> > This is nonsense.  The query is application specific.  In
> > IPsec, the query
> > key is either DNS name or IP address.  In S/MIME, the query
> > key is email
> > address.  And, so on.
>
>Actually this is precisely the set of semantics we ended up
>with in XKMS and the set of semantics I believe need to be
>added to SCVP.

As Trevor said at the meeting in San Francisco, application-specific 
validation policies are going to be developed.  It is not clear if they 
should be in the base protocol or in a separate document, but everyone 
agrees that it should be done.

Russ



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SLuZF22746 for ietf-pkix-bks; Fri, 28 Mar 2003 13:56:35 -0800 (PST)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SLuRg22734 for <[e-mail]>; Fri, 28 Mar 2003 13:56:33 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2SLuF62020783; Fri, 28 Mar 2003 16:56:22 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05111a04baaa3b8f40e6@[128.33.238.253]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 28 Mar 2003 12:52:47 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: [TAP straw poll] 'in favor'
Cc: "'ietf-pkix'" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 7:41 AM -0800 3/28/03, todd glassey wrote:
>hey Stephen - I rarely have this much fun with you, but this
>one is good... So point out to me where in RFC2026 or any
>other document where it says anything about what the WG
>Chair's Powers are relative to what is published.
>Paaaaaaaalease - Show me the Light!.
>
Well, I guess it's comforting to know that someone is having fun. 
But, as for showing you the light, I gave up on that a long time ago 
and I'm not going to waste more time on your rants now.

The right place to discuss this issue is the POISED list, since you 
claim it is an overall IETF process question. You tried there and 
failed.

I'll not entertain the discussion here.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SLuZp22747 for ietf-pkix-bks; Fri, 28 Mar 2003 13:56:35 -0800 (PST)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SLuXg22739 for <[e-mail]>; Fri, 28 Mar 2003 13:56:33 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2SLuF5w020783; Fri, 28 Mar 2003 16:56:18 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p05111a02baaa37c65d41@[128.33.238.253]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <[e-mail]> <p05111a04baa8c1a2f7dd@[10.4.58.234]> <[e-mail]>
Date: Fri, 28 Mar 2003 12:39:37 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: TAP
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:51 AM +0000 3/28/03, Stephen Farrell wrote:
>Hi Steve,
>
>>  I think there is a big distinction between the TAP proposal and the
>>  Diameter & SIP work you suggest. TAP is an infrastructure element,
>>  potentially supportive
>>    of a wide range of applications that require archive. SIP and
>>  Diameter are specific applications.
>
>That's true - but I wasn't suggesting otherwise.
>
>>  Our philosophy in PKIX has been
>>  to let each application develop its own profile(s) for use of PKI in
>>  the corresponding WG. S/MIME did that, as did TLS, and now IPsec. So,
>
>Also true, and here's where we probably disagree a bit. I think we'd
>be better served by moving focus now away from developing new bits of
>infrastructure and towards helping applications make use of PKI.

I don't disagree with the need for helping apps make use of PKI. The 
question is whether this should be done in PKIX, another PKI-centric 
WG, or by having PKI experts participate in the target WGs. I'm open 
to suggestions, but we have tended toward the latter, after initially 
adopting the first approach, e.g., we removed extended key usage 
definitions for apps from our profile.

>The examples you raise are interesting:
>
>- They're all security WGs!! As infrastructure PKI is much more widely
>   applicable
>- I think its fair to say they've done a mixed job in terms of
>   how well they've managed to integrate PKI and how long it took
>- Those groups have fairly good overlap with PKIX in terms of active
>   people, which isn't the case generally

agree with all of these observations.

>All of which tell me that some concerted "PKI help" for (a
>constrained-in-the-charter range of) other WGs/applications/protocols
>might be appropriate at this point.

That's one approach, but why charter a WG to help these apps, rather 
than asking interested parties to work with the WGs for the apps of 
interest?

>  > I would not consider the examples you suggested as appropriate for
>>  PKIX
>
>I wasn't suggesting PKIX take on those work items. I was seconding
>Peter's implied suggestion that we charter a new PKIXAPPS WG to tackle
>such issues. (Of course, another reasonable approach could be to
>try charter a WG to generally tackle key management for a named
>bunch of IETF protocols - that WG could then make PKI and/or
>Kerberos and/or whatever decisions for each such protocol - which
>sounds like a good venue for bun-fights, but not much else:-)

That's sort of what I worry about, i.e., trying to solve problems for 
an app requires considerable knowledge of the app, and that knowledge 
is generally held by the app WG.

>
>>  or for any other PKI-centric WG.
>
>A putative PKIXAPPS would be PKI centric and would therefore be an
>appropriate venue for such work.

I am doubtful of this approach, but you should bring it to the 
security ADs if you want to pursue it.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SIJJk10059 for ietf-pkix-bks; Fri, 28 Mar 2003 10:19:19 -0800 (PST)
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SIJHg10055 for <[e-mail]>; Fri, 28 Mar 2003 10:19:17 -0800 (PST)
Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.8/) with ESMTP id h2SIGpMX007291; Fri, 28 Mar 2003 10:16:51 -0800 (PST)
Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id <HXCS82NR>; Fri, 28 Mar 2003 10:19:18 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>
Cc: [e-mail]
Subject: RE: The case against directories
Date: Fri, 28 Mar 2003 10:19:18 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>I probably should not get sucked into this thread, but I feel a need to 
>reply to some of the suff in this thread.

That is what I thought.. but as you know directories suck
you in to threads like these.

> This is nonsense.  The query is application specific.  In 
> IPsec, the query 
> key is either DNS name or IP address.  In S/MIME, the query 
> key is email 
> address.  And, so on.

Actually this is precisely the set of semantics we ended up
with in XKMS and the set of semantics I believe need to be
added to SCVP.

> The LDAP community is working on this issue. 

That is good, but in the meantime they should not claim that
they have already solved the problem.

> I would hope that there is more than one thing for which the 
> directory is useful. ;-)

Yes, it is a have standardized a hammer and will insist that
we call everything a nail...

> So, some people do not understand the technology that they 
> purchase and 
> install.  What does that have to do with this discussion?

It depends whether you consider the job of the IETF to be
the design of protocols that can be secure when deployed by
experts or whether we should develop protocols that are robust
when deployed in real world situations.

It irritates me somewhat that the people who keep asserting
that I am compromised by a financial interest here do not
recognise that high priced consultants might have a similar 
interest here - and no I am not talking about you Russ.

> What are the problems that really need the attention of the 
> IETF?  

I think that we need to address the problem of how the
whole PKI architecture hangs together in a document that
can be understood by the people who are actually on the
front lines.

I don't think that simply repeating the mantra of the
end-to-end ideology helps either. Yes end-to-end is a
good thing, but there are a lot of security issues
itt does not and canot address. Defining these issues
as non-problems as the IETF has done for many years
or railing against firewalls, NAT, etc. as members of
the IAB are wont to do is not helpful.


		Phill


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SHgKh08870 for ietf-pkix-bks; Fri, 28 Mar 2003 09:42:20 -0800 (PST)
Received: from nb2.stroeder.com (krl9-d9bb4f21.pool.mediaWays.net [217.187.79.33]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SHgHg08866 for <[e-mail]>; Fri, 28 Mar 2003 09:42:18 -0800 (PST)
Received: from localhost (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 88DA72516A for <[e-mail]>; Fri, 28 Mar 2003 18:42:10 +0100 (CET)
Received: from stroeder.com (localhost.stroeder.com [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 83A012515B for <[e-mail]>; Fri, 28 Mar 2003 18:42:09 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 28 Mar 2003 17:42:09 +0000
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: The case against directories
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.73.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by AMaViS 0.3.12pre8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hallam-Baker, Phillip wrote:
>>Yet another thread against directories. I wonder when "cases 
>>against XML" will be issued after we have found yet another 
>>new technology that markets well.
> 
> Actually the issue is not angle brackets or not, the issue is
> the primary search key.
 >
 > The only query that a PKI enabled application wants to make
 > is to map a network address to a public key. There is no
 > direct support for this in hierarchical directories - unless
 > you structure the DIT using DNS names and then you have DNS
 > in ASN.1.

You did not read the quite concrete replies in the former thread thoroughly 
enough. IMO you don't *want* to read them. While pointing out real-world 
problems in e.g. LDAP your responses regarding the very same issues in 
name-your-favourite-buzz-word-technology-here are nothing more than 
marketing blurb. This has absolutely nothing to do with technology. That's 
just promoting your new gadget.

This behaviour is the real obstacle to PKI deployment because it confuses 
vendors who don't want to invest yet more money in yet another half-cooked 
blown-up PKI blurb technology. (Someone out there having a good translation 
of the german term "Investitionssicherheit"? Would be appropriate here.)

I'm not the one who is saying that LDAP/X.500 is *the* requirement for PKI 
deployment. I'm also no DIT fetishist. If you don't know how decouple 
directory DIT and certificate naming you have the wrong job. But having a 
PKI repository accessible via LDAP helps for quite a bunch of existing 
applications. name-your-favourite-buzz-word-technology-here are yet to be 
implemented.

I have no objection against other technology. But I'm really getting sick of 
yet another PKI "standard" which promises to solve the old problems but 
never will reach remarkable market share since the old problems aren't 
solved. If this is the business model of some PKI vendors they will fail in 
the long run. That's for sure.

Ciao, Michael.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SGGnK05205 for ietf-pkix-bks; Fri, 28 Mar 2003 08:16:49 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2SGGlg05201 for <[e-mail]>; Fri, 28 Mar 2003 08:16:47 -0800 (PST)
Received: (qmail 607 invoked from network); 28 Mar 2003 16:16:20 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.186.104) by woodstock.binhost.com with SMTP; 28 Mar 2003 16:16:20 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 28 Mar 2003 11:16:31 -0500
To: "Hallam-Baker, Phillip" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: The case against directories
Cc: [e-mail]
In-Reply-To: <[e-mail] .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>

Phil:

I probably should not get sucked into this thread, but I feel a need to 
reply to some of the suff in this thread.

> > Yet another thread against directories. I wonder when "cases
> > against XML" will be issued after we have found yet another
> > new technology that markets well.
>
>Actually the issue is not angle brackets or not, the issue is
>the primary search key.
>
>The only query that a PKI enabled application wants to make
>is to map a network address to a public key. There is no
>direct support for this in hierarchical directories - unless
>you structure the DIT using DNS names and then you have DNS
>in ASN.1.

This is nonsense.  The query is application specific.  In IPsec, the query 
key is either DNS name or IP address.  In S/MIME, the query key is email 
address.  And, so on.

>SCVP can with modifications serve the exact same purpose as
>XKMS and be equally useful.

We talked about one -- the return of the raw public key.  That was added 
several document generations ago.  I have not dear any other comments.

>In general it is simply not useful to have information that
>is structured for both machine retrieval and human retrieval.

Agree.

> > As already has been stated, the problems are mostly
> > organizational than technical.
>
>The technical issue is still substantial. There is no standard
>query I can issue that is supported ALL by the DEPLOYED directories
>that will allow me to do a lookup on the email address of the
>person I want to contact.

The LDAP community is working on this issue.  And, I hope that a SINGLE 
solution emerges quickly.  The PKIX community has already experienced the 
lack of interoperability that comes from more than one way to achieve the 
same result.

>Therefore there is no standard to do the thing that is useful.

I would hope that there is more than one thing for which the directory is 
useful. ;-)

> > Even if you don't like it, directory supported PKI is being
> > more and more implemented.
>
>No it isn't. We deploy the PKI and then link it to the customer's
>directory if they have one. The applications don't actually
>interact with the PKI though so this does not meet any reasonable
>definiton of 'directory supported'.
>
>You can shut down the directory and degauss the hard drives and
>most PKIs will work exactly as well. Many will work better.

He said, she said...  I am aware of some large environments where 
directories are being used by the infrastructure, and applications are in 
the process of being updated to make use of the directory.  Fine.  You know 
of environments where the applications are not being updated.  Fine 
too.  This is probably as much a statement about the economy as the technology.

Firewalls play a big part in this too.  Most places do not enable directory 
access from the outside.  This means that the certificates that are 
intended to be used by parties outside the enterprise need to be published 
in at least two places.  The only solution I have seen discussed for this 
one is Peter Gutmann's HTTP certificate store.

I would rather have a discussion of the problems with deployment and their 
potential solutions....

> > Banks and other big companies are deploying directories for
> > PKI as well. Are all of them on a dead end road?
>
>Ask if any of those banks intend to make their directory
>accessible beyond the firewall. I think you will find the
>answer is over my dead body.

At least one large enterprise is running two directories, one inside and 
one outside.  The one on the outside contains a subset of the 
population.  This imposes a huge burden on the administrator.

Again, I would rather have a discussion of the problems with deployment and 
their potential solutions....

> > > 2. Internal information  (including employment) is
> > generally not public
> >
> > No problem for directories, since you have well established
> > and good working authentication and access control
> > mechanisms, so everyone can define who is allowed to see the
> > certs.
>
>Nobody trusts those mechanisms, nor should they. Even if
>the software is correct (doubtful even if it is advertised
>as unbreakable) the configuration probably isn't.
>
>We do managed security services as an outsourced service.
>Quite often when we take over a customer's firewalls we
>discover horrors. It is unusualbut not as unusual as it should
>be to find that a $100,000 fault tolerant, redundant etc.
>firewall is being run with all trafic allowed in both directions.

So, some people do not understand the technology that they purchase and 
install.  What does that have to do with this discussion?

What are the problems that really need the attention of the IETF?  Notice 
that I did not say the PKIX WG.  We may find that some of the problems need 
to be worked by PKIX, but there may be others that need to be worked in 
other working groups.

> > Yes, and as I said before, ther might be scenarios in which
> > XML/Web Services technology are more appropriate (I am not
> > making a "case against XML"). Still I know of a lot of
> > scenarios, where existing, well established technology is
> > better for production services.
>
>We have tried X.500 for 15 years now with zero utility
>demonstrated with respect to PKI. LDAP has been arround for
>less time but there is no major architectural difference
>except for the fact that once upon a time LDAP was simpler.
>
>This reminds me of the arguments the physicists used to
>make for FORTRAN. It is tried technology, why move to
>something that is newer, has been designed with a knowledge
>of the architectural limitations of FORTRAN, a better
>understanding of program language design and which empirically
>results in more accurate code with fewer bugs that is
>completed in much less time and is much more maintainable
>afterwards?

Again, we are off topic.  Since we are, I feel obligated to add some fuel 
to the discussion.  We do not know that XML offers us "more accurate code" 
or "fewer bugs."  We do know that some very nice tools have been generated 
to aid programmers.  These tools will lead to "more accurate code" or 
"fewer bugs."  But, in my opinion, similar tools could be developed for 
other approaches, but the product managers of the world have not chosen to 
do so.

Hopefully we can return to fruitful discussion now ...

> > > Unlike directory systems, SAML allows secure access to any kind
> > > of active or passive information source, including purchasing and
> > > work-flow systems.
> >
> > SAML is a good but complex means for communicating
> > authorizations ans assertions, it is not a whole middleware
> > infrastructure.
>
>Actually SAML is two things, the AAA application statements and
>the assertion framework. The assertion framework absolutely is
>a middleware infrastructure and was designed as such. It is
>intended to be possible to support every X.509 signed data
>construct within that framework and in fact any other statement.
>
>As Tim B-L pointed out the SAML assertion framework is a
>competitor to RDF.

So, how does this help us deploy certificate repositories?  Is SAML going 
to be the access control to such repositories?  Is SAML a consumer of 
certificates, and it needs to access repositories?  Or, both?

Russ



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SFfl602624 for ietf-pkix-bks; Fri, 28 Mar 2003 07:41:47 -0800 (PST)
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SFfgg02613 for <[e-mail]>; Fri, 28 Mar 2003 07:41:42 -0800 (PST)
Received: from tsg1 (230.sanfrancisco-12rh16rt-ca.dial-access.att.net[12.81.119.230]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030328154136112008pjnae>; Fri, 28 Mar 2003 15:41:36 +0000
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "'ietf-pkix'" <[e-mail]>
Subject: RE: [TAP straw poll] 'in favor'
Date: Fri, 28 Mar 2003 07:41:00 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <p05111a01baa918a980b2@[192.168.0.52]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

hey Stephen - I rarely have this much fun with you, but this
one is good... So point out to me where in RFC2026 or any
other document where it says anything about what the WG
Chair's Powers are relative to what is published.
Paaaaaaaalease - Show me the Light!.

---
I didn't think so - I couldn't find anything either
---

As to whether PKIX and the IETF have an formal obligation to
accept each and every crackpots I-D - the answer is simple
and its "yeah, there is". And lets be real clear on that -
there is nothing in any of the documents I have carefully
studied that says anything about whether the WG or its
chairs have anything to say about the publication of an I-D.
The purpose of the I-D is to provide an introduction of
technologies to a WG so that they can be discussed in that
forum.

It's one of the loopholes that was left out of the "can of
spaghetti" we call RFC2026 - No really check it out, here is
a link - (http://www.faqs.org/rfcs/rfc2026.html). Anything
properly submitted to the I-D Editors that is properly
formatted is to be published.

And - that's the point of the I-D's anyway, to stimulate
group discussion in the "vetting team" on whether a
standards track effort should be started for this idea,
protocol, or BCP.

Duh -

As to the publication of RFC's, that also is nebulous since
2026 is inconsistent about how it refers to RFC's. For
instance there are words in 2026 that refer to the process
of creating a RFC "and that it is done as part of the
Standards Track startup of a technology that was vetted
through the precursor I-D process". This implies that the
only way to get a RFC is to start a standards track effort
and that this is a requirement of that process. And then it
also refers to the BCP's which are not intended to be
Standards but rather just published as RFC's and that never
will be standards - so there is a disconnect in the
interpretation of what is what in 2026.

My take is that it is the UniStandard Model that is flawed
and that the IETF needs both Product and Reference
Standards. And yes I will take that up with POISED.

--

Meanwhile - back at the ranch - what does that leave you
with? My reading is that possibly that you might have some
control over RFC's that are part of the larger standards
process - but my reading of the words and intent of 2026 is
that you have nothing to say about Non-Standards track RFC's
what so ever. And this could possibly have serious legal
repercussions for the IETF and you personally if you tried
to stop a project the WG's Vetting team wanted to do -

No, as I read 2026 you essentially have NOTHING to say about
what is published and what is worked on and any attempt by
you or Tim to submarine a project or protocol that the group
wants influence what the group is focusing on could
constitute actionable activities...

Todd


-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Thursday, March 27, 2003 1:26 PM
To: todd glassey
Cc: 'ietf-pkix'
Subject: RE: [TAP straw poll] 'in favor'


At 10:50 AM -0800 3/27/03, todd glassey wrote:
>But that's what you always say Steve and still you have
failed to make PKIX
>fair and open as RFC2026 mandates. Its your game show and
that's that. You
>know its pretty funny that you never refute the core of
what I say to you
>just how competent I am to say it.
>
>Is this how a Chair in an open and fair standards practice
should act?
>
>Todd

Todd,

In previous messages (on the POISED list) you have insisted
that if
the IETF operated as a true "open standards" body, it would
publish
all submissions as RFCs, irrespective of merit. The fact
neither the
IETF not any other standards body operates in this fashion
does not
seem to dissuade you from this fantasy.

You raised the same issues in your most recent message,
arguing that
"I-D's are accepted whether the larger group wants to or
not."  This
is utter nonsense. No standards body exists to serve as an
unmoderated publication medium for every crackpot who comes
along.
Your whole notion of an appropriate publication process
servers no
valid standards purpose. Ypou misunderstand, or simply
misstate, the
primary purpose and utility of RFCs; the IETF is the primary
standards creator for the Internet. If other bodies want to
cite our
standards that's good, in that it avoids duplicative efforts
and
divergent standards, but even if that never happened the
IETF would
be doing its job. Moreover, this is a reciprocal
environment, in that
the IETF often cites and builds upon the work of other
standards
bodies. PKIX is an excellent example of that, though by no
means the
only one.

There is a well-defined "vetting and standards escalation
process,"
contrary to your comment. What you don't like is the way the
process
works. It entails value judgements by WG chairs and by ADs,
and
because you don't like the judgements of these individuals
you would
like the system to change. This is an IETF process matter,
not a PKIX
matter per se, and you have tried and failed to persuade the
IESG or
the POISED WG members that the process is broken.

Again I've wasted too much time on this, contrary to my
earlier
promise.  Going forward I'll try to rely on the WG members
to draw
their own conclusions about the worth of your postings.

Steve




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SFcYV02272 for ietf-pkix-bks; Fri, 28 Mar 2003 07:38:34 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SFcXg02259 for <[e-mail]>; Fri, 28 Mar 2003 07:38:33 -0800 (PST)
Subject: Re: The case against directories
To: Peter Gietz <[e-mail]>
Cc: Anders Rundgren <[e-mail]>, [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 28 Mar 2003 08:34:32 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 03/28/2003 10:39:35 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

the one detailed implementation presentation I've seen on a SAML based
product .... looked exactly like Kerberos .... but the transmissions were
SAML-encoded (and carried authorizations in addition to authentication)

misc kerberos
http://www.garlic.com/~lynn/subpubkey.html#kerberos

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm


[e-mail] on 3/28/2003 4:55 am wrote:

> Using authentication systems like OASIS' SAML, organizations can
> (through their employees), authenticate to each others' intranets and
> through this get access to exactly the information they should have
> and in a format that make sense.  The latter may be a directory tree,
> a PDF-file, a database listing, an HTML form, etc.
>
> Unlike directory systems, SAML allows secure access to any kind
> of active or passive information source, including purchasing and
> work-flow systems.

SAML is a good but complex means for communicating
authorizations ans assertions, it is not a whole middleware
infrastructure.





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SErFJ27384 for ietf-pkix-bks; Fri, 28 Mar 2003 06:53:15 -0800 (PST)
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SErEg27378 for <[e-mail]>; Fri, 28 Mar 2003 06:53:14 -0800 (PST)
Received: from mou1wnexc01.verisign.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.8/) with ESMTP id h2SEoiMX005021; Fri, 28 Mar 2003 06:50:44 -0800 (PST)
Received: by mou1wnexc01.verisign.com with Internet Mail Service (5.5.2653.19) id <HXCS79N5>; Fri, 28 Mar 2003 06:53:12 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Peter Gietz'" <[e-mail]>, Anders Rundgren <[e-mail]>
Cc: [e-mail]
Subject: RE: The case against directories
Date: Fri, 28 Mar 2003 06:53:11 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Yet another thread against directories. I wonder when "cases 
> against XML" will be issued after we have found yet another 
> new technology that markets well.

Actually the issue is not angle brackets or not, the issue is
the primary search key.

The only query that a PKI enabled application wants to make
is to map a network address to a public key. There is no
direct support for this in hierarchical directories - unless
you structure the DIT using DNS names and then you have DNS
in ASN.1.

SCVP can with modifications serve the exact same purpose as
XKMS and be equally useful.

In general it is simply not useful to have information that
is structured for both machine retrieval and human retrieval.

> As already has been stated, the problems are mostly 
> organizational than technical.

The technical issue is still substantial. There is no standard
query I can issue that is supported ALL by the DEPLOYED directories
that will allow me to do a lookup on the email address of the
person I want to contact.

Therefore there is no standard to do the thing that is useful.

> Even if you don't like it, directory supported PKI is being 
> more and more implemented. 

No it isn't. We deploy the PKI and then link it to the customer's
directory if they have one. The applications don't actually
interact with the PKI though so this does not meet any reasonable
definiton of 'directory supported'.

You can shut down the directory and degauss the hard drives and 
most PKIs will work exactly as well. Many will work better.

> Banks and other big companies are deploying directories for 
> PKI as well. Are all of them on a dead end road?

Ask if any of those banks intend to make their directory
accessible beyond the firewall. I think you will find the
answer is over my dead body.

> > 2. Internal information  (including employment) is 
> generally not public
> 
> No problem for directories, since you have well established 
> and good working authentication and access control 
> mechanisms, so everyone can define who is allowed to see the 
> certs.

Nobody trusts those mechanisms, nor should they. Even if 
the software is correct (doubtful even if it is advertised
as unbreakable) the configuration probably isn't.

We do managed security services as an outsourced service.
Quite often when we take over a customer's firewalls we
discover horrors. It is unusualbut not as unusual as it should
be to find that a $100,000 fault tolerant, redundant etc. 
firewall is being run with all trafic allowed in both directions.


> Yes, and as I said before, ther might be scenarios in which 
> XML/Web Services technology are more appropriate (I am not 
> making a "case against XML"). Still I know of a lot os 
> scenarios, where existing, well established technology is 
> better for production services.


We have tried X.500 for 15 years now with zero utility 
demonstrated with respect to PKI. LDAP has been arround for 
less time but there is no major architectural difference
except for the fact that once upon a time LDAP was simpler.

This reminds me of the arguments the physicists used to 
make for FORTRAN. It is tried technology, why move to
something that is newer, has been designed with a knowledge
of the architectural limitations of FORTRAN, a better 
understanding of program language design and which empirically
results in more accurate code with fewer bugs that is 
completed in much less time and is much more maintainable 
afterwards?


> > Unlike directory systems, SAML allows secure access to any kind
> > of active or passive information source, including purchasing and
> > work-flow systems.
> 
> SAML is a good but complex means for communicating 
> authorizations ans assertions, it is not a whole middleware 
> infrastructure.

Actually SAML is two things, the AAA application statements and
the assertion framework. The assertion framework absolutely is 
a middleware infrastructure and was designed as such. It is 
intended to be possible to support every X.509 signed data 
construct within that framework and in fact any other statement.

As Tim B-L pointed out the SAML assertion framework is a 
competitor to RDF.


		Phill 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SDshT25406 for ietf-pkix-bks; Fri, 28 Mar 2003 05:54:43 -0800 (PST)
Received: from isis.directory.dfn.de (isis.directory.dfn.de [134.2.217.130]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SDsfg25401 for <[e-mail]>; Fri, 28 Mar 2003 05:54:41 -0800 (PST)
Received: from clara.directory.dfn.de (clara.directory.dfn.de [134.2.217.66]) by isis.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id h2SDsaG25535; Fri, 28 Mar 2003 14:54:36 +0100
Received: from daasi.de (mercury.directory.dfn.de [134.2.217.50]) (authenticated (0 bits)) by clara.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id h2SDsYJ30036 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Fri, 28 Mar 2003 14:54:36 +0100
Message-ID: <[e-mail]>
Date: Fri, 28 Mar 2003 14:54:34 +0100
From: Peter Gietz <[e-mail]>
Organization: DAASI International GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: de-de, en-us, en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: IETF-PKIX <[e-mail]>
Subject: Re: draft minutes
References: <p05100311baa52e765ff7@[128.89.88.34]>
In-Reply-To: <p05100311baa52e765ff7@[128.89.88.34]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2SDsgg25402
Sender: [e-mail]
Precedence: 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 to reply to the minutes that late.
In my perspective following half sentence is missing at the end:

 > A quick straw poll indicates that the attendees favor
 > component matching, but the number of attendees voting was
 > very small.
", thus it was decided to take it to the list."

Cheers,

Peter


Stephen Kent wrote:
> Folks,
> 
> Attached are the draft minutes from last week's PKIX meeting.  Please 
> review them and send comment to me by Wednesday, 3/26.  Also, each 
> presenter should send a copy of his slides to me.  I already have slides 
> from Riccardo, Jim, Jong-Wook, Trevor, and Stefan.
> 
> As noted in the minutes, we will conduct a straw poll, starting now, to 
> determine the sense of the WG re initiating a new work item, for the 
> trusted archive spec.  The co-chairs approved publication of this 
> document as a WG I-D, as it seems like another aspect of PKI 
> infrastructure, e.g., it makes use of our time stamp authority standard 
> and is an obvious component for NR support. However, given the limited 
> support shown at the meeting for pursuing this work, we want to revisit 
> this decision before proceeding. Please look at the document 
> (draft-ietf-pkix-tap-00.txt) and indicate whether you believe this is an 
> appropriate WG activity, or not.
> 
> Thanks,
> 
> Steve

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]
D-72074 Tübingen                        email: 
[e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information 
Management
_______________________________________________________________________



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SBu2Z16190 for ietf-pkix-bks; Fri, 28 Mar 2003 03:56:02 -0800 (PST)
Received: from isis.directory.dfn.de (isis.directory.dfn.de [134.2.217.130]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SBu0g16186 for <[e-mail]>; Fri, 28 Mar 2003 03:56:01 -0800 (PST)
Received: from clara.directory.dfn.de (clara.directory.dfn.de [134.2.217.66]) by isis.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id h2SBttG23689; Fri, 28 Mar 2003 12:55:55 +0100
Received: from daasi.de (mercury.directory.dfn.de [134.2.217.50]) (authenticated (0 bits)) by clara.directory.dfn.de (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id h2SBtsJ28925 (using TLSv1/SSLv3 with cipher RC4-MD5 (128 bits) verified NO); Fri, 28 Mar 2003 12:55:54 +0100
Message-ID: <[e-mail]>
Date: Fri, 28 Mar 2003 12:55:50 +0100
From: Peter Gietz <[e-mail]>
Organization: DAASI International GmbH
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: de-de, en-us, en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail]
Subject: Re: The case against directories
References: <00df01c2ef82$d19ed6f0$0500a8c0@arport>
In-Reply-To: <00df01c2ef82$d19ed6f0$0500a8c0@arport>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2SBu1g16187
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yet another thread against directories. I wonder when "cases 
against XML" will be issued after we have found yet another 
new technology that markets well.

Please see my commenst inline:

Anders Rundgren wrote:
> I would like to add a few things to what Phillip Hallam-Baker of
> VeriSign wrote about directories as an obstacle to PKI deployment
> 
> Many  PKI experts are involved in huge public-sector-driven projects,
> that are based on establishing directory interoperability between
> organizations.  At first sight this looks like a great idea but digging
> a bit further, you soon note that this is not a universal solution but
> rather a dead end.

As already has been stated, the problems are mostly 
organizational than technical.

Even if you don't like it, directory supported PKI is being 
more and more implemented. Look at what governments have 
been and will in future be putting effort to provide PKI as 
infrastructure to the citizens. This is happening in on both 
sides of the Atlantic. Fedbridge and Canada as well as in EU 
legislation and a lot of European countries. I am not very 
familiar with other parts of the world in this respect.

Banks and other big companies are deploying directories for 
PKI as well. Are all of them on a dead end road?

> 
> Directory problem issues 
> 1. Technical.  Unifying schemas + firewall issues

There is commonly accepted schema for phase one (one user 
has one or few certs) that is in use and works. Phase two 
(lots of certs and functionality to provide searches within 
the cert information is currently in discussion for phase 
two where people have lots of certs, including attribute 
certificates.

A firewall that only permits HTTP ports is nice, but since 
more and more things gets tunneled within HTTP they get more 
and more useless. On the contrary to permit special ports 
for very clear defined purposes like directory communication 
seems to be much nicer.

> 2. Internal information  (including employment) is generally not public

No problem for directories, since you have well established 
and good working authentication and access control 
mechanisms, so everyone can define who is allowed to see the 
certs.

As said before: this organizational problem applies top all 
technical solutions, only that directories are quite good in 
providing help (and directory experts are often privacy 
experts as well)

> 3. The level of openness depends on who is asking

Yes see remarks on 2.

> 4. Directories represent just one way to organize data

Yes, and as I said before, ther might be scenarios in which 
XML/Web Services technology are more appropriate (I am not 
making a "case against XML"). Still I know of a lot os 
scenarios, where existing, well established technology is 
better for production services.

> 
> But, there is no reason to despair, as there are work-arounds that
> properly addresses all these issues:
> 
> Using authentication systems like OASIS' SAML, organizations can
> (through their employees), authenticate to each others' intranets and
> through this get access to exactly the information they should have
> and in a format that make sense.  The latter may be a directory tree,
> a PDF-file, a database listing, an HTML form, etc.  
> 
> Unlike directory systems, SAML allows secure access to any kind
> of active or passive information source, including purchasing and
> work-flow systems.

SAML is a good but complex means for communicating 
authorizations ans assertions, it is not a whole middleware 
infrastructure.

> 
> All using the truly universal Internet browser interface.

Do you know that a very high percentage of directory usage 
goes through a Web-to-LDAP gateway?

> 
> For machine-to-machine (=automated) access to external information,
> specialized Web Services seems to be a much more extensible route
> than directories, as the former introduces no restrictions on data.

And thus provide a lot of interoperability issues. WSDL/UDDI 
is good for providing information about the existance and 
function of services. You will  end up in schema 
standardization nonetheless to provide interop.


Cheers,

Peter


> 
> Anders Rundgren
> Independent consultant PKI and secure e-business
> 
> 
> 

-- 
_______________________________________________________________________

Peter Gietz (CEO)
DAASI International GmbH                phone: [phone]
Wilhelmstr. 106                         Fax:   [phone]
D-72074 Tübingen                        email: 
[e-mail]
Germany                                 Web:   www.daasi.de

Directory Applications for Advanced Security and Information 
Management
_______________________________________________________________________



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SB3Kr12354 for ietf-pkix-bks; Fri, 28 Mar 2003 03:03:20 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SB3Eg12337 for <[e-mail]>; Fri, 28 Mar 2003 03:03:14 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h2SB0R809111 for <[e-mail]>; Fri, 28 Mar 2003 11:00:27 GMT
Received: from  ([10.153.25.53]) by Baltimore-FW1; Fri, 28 Mar 2003 10:58:42 +0000 (GMT)
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Fri, 28 Mar 2003 11:02:52 +0000
Received: from  ([10.153.25.10]) by Baltimore-FW1; Fri, 28 Mar 2003 10:58:40 +0000 (GMT)
Received: from baltimore.ie (wks165-4.ie.baltimore.com [10.153.4.165]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA18589; Fri, 28 Mar 2003 11:03:07 GMT
Message-ID: <[e-mail]>
Date: Fri, 28 Mar 2003 11:02:40 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: TAP
References: <004201c2f46b$43fe1c00$d600a8c0@Chokhani>
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 Santosh,

> I do not know what Diameter and SIP are.

They are IETF protocols with security requirements which are being
partly met via combinations of TLS, IPsec and CMS but where no-one
(afaik) has really written down how to sensibly setup a PKI. For
example, some Diameter folks were thinking once that a single root 
CA for all ISPs in the world would be a good idea. (Diameter's 
being done in the AAA WG, SIP has various WGs, depending when you 
look.)

I'm sure there are other similar cases in the IETF, those are just 
two with which I'm a bit familiar.

Its a bit like what happened with IKE and PKI and which (I believe) 
held up IPsec interop, and therefore VPN deployment for some time. 

> If the PKIX is overwhelmed and another group needs to be spun off, that is a
> workload issue.

I don't believe its only a workload issue, though there are clearly
fewer cycles available to this community when compared to a few years 
ago.

> I do see the TAP as more of an infrastructure service in support of
> non-repudiation as opposed to an application.

Sure, I agree with you there. Where we probably disagree is whether 
or not we should add yet more protocols to the infrastructure or whether
we're better off showing people how to use what we've got already. I 
believe the latter.

Stephen.

> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Stephen Farrell
> Sent: Thursday, March 27, 2003 5:56 AM
> To: Yee, Peter
> Cc: [e-mail]; [e-mail]
> Subject: Re: TAP
> 
> I totally agree with Peter here - the PKIX WG has enough on its plate
> already as is probably evidenced by the tiny amount of time that seems
> to be devoted to "non-core" I-Ds these days, and in any case, there
> may well be more compelling applications on which to work if we were
> to properly consider a PKIXEXT or PKIXAPPS WG charter (I'd argue that
> chartering PKIXAPPS is the appropriate thing for this community at
> this point).
> 
> Just to mention two possible examples - there is a need for PKI
> support for Diameter and SIP and I don't believe (though I'm open
> to correction here) that such things are getting the level of
> attention in the IETF that they deserve - leaving open (or likely?)
> the possibility that people who want to secure those protocols
> will not use PKI, or will use it badly, or even (heaven forbid)
> start to develop another certificate management protocol! I'm sure that a
> PKIXAPPS chartering process will turn up some more such cases, and probably
> even more interesting ones too.
> 
> Stephen.
> 
> "Yee, Peter" wrote:
> >
> > Although I believe TAP is a useful addition to the set of tools
> > surrounding a PKI, I feel that it is further removed from the core PKI
> > functionality on which PKIX should be working to standardize in this
> > group.  Perhaps a PKIXEXT or PKIXAPPS working group is merited.
> >
> >                                                 -Peter Yee
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) [phone]
> 39 Parkgate Street,                     fax: [phone]
> Dublin 8.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2SAqDQ11436 for ietf-pkix-bks; Fri, 28 Mar 2003 02:52:13 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2SAqAg11431 for <[e-mail]>; Fri, 28 Mar 2003 02:52:11 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h2SAnQ808518 for <[e-mail]>; Fri, 28 Mar 2003 10:49:26 GMT
Received: from  ([10.153.25.53]) by Baltimore-FW1; Fri, 28 Mar 2003 10:47:41 +0000 (GMT)
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Fri, 28 Mar 2003 10:51:50 +0000
Received: from  ([10.153.25.10]) by Baltimore-FW1; Fri, 28 Mar 2003 10:47:39 +0000 (GMT)
Received: from baltimore.ie (wks165-4.ie.baltimore.com [10.153.4.165]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id KAA18268; Fri, 28 Mar 2003 10:52:07 GMT
Message-ID: <[e-mail]>
Date: Fri, 28 Mar 2003 10:51:39 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: TAP
References: <[e-mail]> <[e-mail]> <p05111a04baa8c1a2f7dd@[10.4.58.234]>
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 Steve,

> I think there is a big distinction between the TAP proposal and the
> Diameter & SIP work you suggest. TAP is an infrastructure element,
> potentially supportive
>   of a wide range of applications that require archive. SIP and
> Diameter are specific applications. 

That's true - but I wasn't suggesting otherwise.

> Our philosophy in PKIX has been
> to let each application develop its own profile(s) for use of PKI in
> the corresponding WG. S/MIME did that, as did TLS, and now IPsec. So,

Also true, and here's where we probably disagree a bit. I think we'd
be better served by moving focus now away from developing new bits of 
infrastructure and towards helping applications make use of PKI. 

The examples you raise are interesting:

- They're all security WGs!! As infrastructure PKI is much more widely
  applicable
- I think its fair to say they've done a mixed job in terms of
  how well they've managed to integrate PKI and how long it took
- Those groups have fairly good overlap with PKIX in terms of active
  people, which isn't the case generally

All of which tell me that some concerted "PKI help" for (a 
constrained-in-the-charter range of) other WGs/applications/protocols 
might be appropriate at this point.

> I would not consider the examples you suggested as appropriate for
> PKIX 

I wasn't suggesting PKIX take on those work items. I was seconding
Peter's implied suggestion that we charter a new PKIXAPPS WG to tackle
such issues. (Of course, another reasonable approach could be to
try charter a WG to generally tackle key management for a named 
bunch of IETF protocols - that WG could then make PKI and/or 
Kerberos and/or whatever decisions for each such protocol - which
sounds like a good venue for bun-fights, but not much else:-)

> or for any other PKI-centric WG.

A putative PKIXAPPS would be PKI centric and would therefore be an 
appropriate venue for such work.

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2RLqD514906 for ietf-pkix-bks; Thu, 27 Mar 2003 13:52:13 -0800 (PST)
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2RLq8g14894 for <[e-mail]>; Thu, 27 Mar 2003 13:52:08 -0800 (PST)
Received: from tsg1 (unknown[12.81.121.251]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030327215203112008sd56e>; Thu, 27 Mar 2003 21:52:04 +0000
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "'ietf-pkix'" <[e-mail]>
Subject: RE: [TAP straw poll] 'in favor'
Date: Thu, 27 Mar 2003 13:51:26 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <p05111a01baa918a980b2@[192.168.0.52]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Good idea.

Todd


-----Original Message-----
From: Stephen Kent [mailto:[e-mail]]
Sent: Thursday, March 27, 2003 1:26 PM
To: todd glassey
Cc: 'ietf-pkix'
Subject: RE: [TAP straw poll] 'in favor'


At 10:50 AM -0800 3/27/03, todd glassey wrote:
>But that's what you always say Steve and still you have failed to make PKIX
>fair and open as RFC2026 mandates. Its your game show and that's that. You
>know its pretty funny that you never refute the core of what I say to you
>just how competent I am to say it.
>
>Is this how a Chair in an open and fair standards practice should act?
>
>Todd

Todd,

In previous messages (on the POISED list) you have insisted that if
the IETF operated as a true "open standards" body, it would publish
all submissions as RFCs, irrespective of merit. The fact neither the
IETF not any other standards body operates in this fashion does not
seem to dissuade you from this fantasy.

You raised the same issues in your most recent message, arguing that
"I-D's are accepted whether the larger group wants to or not."  This
is utter nonsense. No standards body exists to serve as an
unmoderated publication medium for every crackpot who comes along.
Your whole notion of an appropriate publication process servers no
valid standards purpose. Ypou misunderstand, or simply misstate, the
primary purpose and utility of RFCs; the IETF is the primary
standards creator for the Internet. If other bodies want to cite our
standards that's good, in that it avoids duplicative efforts and
divergent standards, but even if that never happened the IETF would
be doing its job. Moreover, this is a reciprocal environment, in that
the IETF often cites and builds upon the work of other standards
bodies. PKIX is an excellent example of that, though by no means the
only one.

There is a well-defined "vetting and standards escalation process,"
contrary to your comment. What you don't like is the way the process
works. It entails value judgements by WG chairs and by ADs, and
because you don't like the judgements of these individuals you would
like the system to change. This is an IETF process matter, not a PKIX
matter per se, and you have tried and failed to persuade the IESG or
the POISED WG members that the process is broken.

Again I've wasted too much time on this, contrary to my earlier
promise.  Going forward I'll try to rely on the WG members to draw
their own conclusions about the worth of your postings.

Steve




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2RLQmJ13208 for ietf-pkix-bks; Thu, 27 Mar 2003 13:26:48 -0800 (PST)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2RLQkg13204 for <[e-mail]>; Thu, 27 Mar 2003 13:26:47 -0800 (PST)
Received: from [192.168.0.52] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2RLQe62011769; Thu, 27 Mar 2003 16:26:43 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05111a01baa918a980b2@[192.168.0.52]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 27 Mar 2003 16:25:43 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: [TAP straw poll] 'in favor'
Cc: "'ietf-pkix'" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:50 AM -0800 3/27/03, todd glassey wrote:
>But that's what you always say Steve and still you have failed to make PKIX
>fair and open as RFC2026 mandates. Its your game show and that's that. You
>know its pretty funny that you never refute the core of what I say to you
>just how competent I am to say it.
>
>Is this how a Chair in an open and fair standards practice should act?
>
>Todd

Todd,

In previous messages (on the POISED list) you have insisted that if 
the IETF operated as a true "open standards" body, it would publish 
all submissions as RFCs, irrespective of merit. The fact neither the 
IETF not any other standards body operates in this fashion does not 
seem to dissuade you from this fantasy.

You raised the same issues in your most recent message, arguing that 
"I-D's are accepted whether the larger group wants to or not."  This 
is utter nonsense. No standards body exists to serve as an 
unmoderated publication medium for every crackpot who comes along. 
Your whole notion of an appropriate publication process servers no 
valid standards purpose. Ypou misunderstand, or simply misstate, the 
primary purpose and utility of RFCs; the IETF is the primary 
standards creator for the Internet. If other bodies want to cite our 
standards that's good, in that it avoids duplicative efforts and 
divergent standards, but even if that never happened the IETF would 
be doing its job. Moreover, this is a reciprocal environment, in that 
the IETF often cites and builds upon the work of other standards 
bodies. PKIX is an excellent example of that, though by no means the 
only one.

There is a well-defined "vetting and standards escalation process," 
contrary to your comment. What you don't like is the way the process 
works. It entails value judgements by WG chairs and by ADs, and 
because you don't like the judgements of these individuals you would 
like the system to change. This is an IETF process matter, not a PKIX 
matter per se, and you have tried and failed to persuade the IESG or 
the POISED WG members that the process is broken.

Again I've wasted too much time on this, contrary to my earlier 
promise.  Going forward I'll try to rely on the WG members to draw 
their own conclusions about the worth of your postings.

Steve



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2RJbNt07759 for ietf-pkix-bks; Thu, 27 Mar 2003 11:37:23 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2RJbMg07752 for <[e-mail]>; Thu, 27 Mar 2003 11:37:22 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA05821 for <[e-mail]>; Thu, 27 Mar 2003 20:37:21 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Thu, 27 Mar 2003 20:37:21 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id UAA07801 for [e-mail]; Thu, 27 Mar 2003 20:37:20 +0100 (MET)
Date: Thu, 27 Mar 2003 20:37:20 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: [TAP straw poll] 'in favor'
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Only the participants at the S.F. meeting had a chance
to see the slides of the presentation before the
stawpoll was launched.

since it may take some time until we see this elsewhere:

   http://www.edelweb.fr/tap.zip


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2RIol303946 for ietf-pkix-bks; Thu, 27 Mar 2003 10:50:47 -0800 (PST)
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2RIojg03941 for <[e-mail]>; Thu, 27 Mar 2003 10:50:45 -0800 (PST)
Received: from tsg1 (unknown[12.81.121.251]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030327185040112008pkrde>; Thu, 27 Mar 2003 18:50:41 +0000
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "'ietf-pkix'" <[e-mail]>
Subject: RE: [TAP straw poll] 'in favor'
Date: Thu, 27 Mar 2003 10:50:04 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <p05111a0abaa8cea7070b@[10.4.58.234]>
Sender: [e-mail]
Precedence: 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 that's what you always say Steve and still you have failed to make PKIX
fair and open as RFC2026 mandates. Its your game show and that's that. You
know its pretty funny that you never refute the core of what I say to you
just how competent I am to say it.

Is this how a Chair in an open and fair standards practice should act?

Todd


-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Stephen Kent
Sent: Thursday, March 27, 2003 7:54 AM
To: todd glassey
Cc: 'ietf-pkix'
Subject: RE: [TAP straw poll] 'in favor'



Todd,

Your message contains so many errors about current and historical
IETF processes that a response correcting all of them would be a
significant effort, not worthy of my time nor of the WG's indulgence.

Steve



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2RGKd427311 for ietf-pkix-bks; Thu, 27 Mar 2003 08:20:39 -0800 (PST)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2RGKag27306 for <[e-mail]>; Thu, 27 Mar 2003 08:20:38 -0800 (PST)
Received: from [10.4.58.234] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2RGKV5w018489; Thu, 27 Mar 2003 11:20:31 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05111a0abaa8cea7070b@[10.4.58.234]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 27 Mar 2003 10:53:37 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: [TAP straw poll] 'in favor'
Cc: "'ietf-pkix'" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd,

Your message contains so many errors about current and historical 
IETF processes that a response correcting all of them would be a 
significant effort, not worthy of my time nor of the WG's indulgence.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2RF9AW22435 for ietf-pkix-bks; Thu, 27 Mar 2003 07:09:10 -0800 (PST)
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2RF99g22424 for <[e-mail]>; Thu, 27 Mar 2003 07:09:09 -0800 (PST)
Received: from tsg1 (unknown[12.81.120.207]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030327150858112008u08ie>; Thu, 27 Mar 2003 15:08:58 +0000
From: "todd glassey" <[e-mail]>
To: "'ietf-pkix'" <[e-mail]>
Subject: RE: [TAP straw poll] 'in favor'
Date: Thu, 27 Mar 2003 07:08:22 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0051_01C2F42F.A75DFC70"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <001a01c2f461$f0c17310$d600a8c0@Chokhani>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0051_01C2F42F.A75DFC70
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit

MessagePersonally I want to see TAP advanced as I want to add XML timestamps
and/or the BERT/NTP Tokens to it, and like Santosh, I think PKIX is the
right place for it. However - what is not part of PKIX's domain is the core
underlying scientific modeling of PKI technology. That belongs in the IRTF
and into in the mainstream IETF. That is unless the standards process is
split up as I suggested to POISED and the WG members are allowed to file for
Standards under the IRTF or IETF banners.

---

On the issue of why this conversation is even necessary -  what is really
funny about this is watching what is happening to Santosh Chokani, a
brilliant and renowned key player in the Standards Community and Federal
Systems World as he tries to navigate the same waters that I have been
slammed by this WG for years now for treading into. Its more than funny - it
clearly demonstrates the lake of "true standards process" that this WG and
in fact the whole IETF allows with its undefined vetting process and
requirements therein. Arbitrary Arbitrary Arbitrary... Special Interest
Groups extraordinaire eh?

Look, with the lack of a formally defined vetting and standards escalation
process, each WG little more that a Special Interest Group and for some
reason the majority of players here have this idea that they need to be
involved with everything that this group does, and that the group cannot do
anything that they are not involved in more importantly.  Which if you think
about it is why there is this conversation in the first place - so I ask you
in a fair and open standards environment - why is there any say as to what
proto-typical efforts are accepted and which are not??? If you don't have a
fear that some young upstart protocol is going to unseat yours, then why is
this an issue?

So once again I will voice that what PKIX and the whole IETF needs is a real
fair process put in place, and that means that I-D's are accepted whether
the larger group wants to or not. In fact the larger group should only be
involved after the I-D is published. And the vetting process for taking the
I-D's to RFC is made mechanical, not one that requires total focus of the
group, but rather those that committed at the filing of the draft to be a
part of its vetting team. Say then that the "Stage One" vetting team needs
to be at minimum three separate orgs or players. Then - this might actually
be fair and an equal opportunity for all.

Under that model Santosh or CygnaCOM would file the I-D and it would get
vetted through RFC and then the WG would start its decisions on whether to
focus on it as a standard's effort. By that time the RFC would have enough
detail to allow the group to see whether it made sense and others to see
whether it was right for their adoption.

The problem for many with this proposal is that this devalues the RFC by
making getting it a much easier process - and that is something that many do
not want to happen since they actively proffer RFC's as standards to other
orgs and this will hurt their political or commercial agendas in their own
efforts to manipulate the standards process.

As part of defining the vetting process, it needs to be clearly stated that
it is not allowed for a WG to refuse a filing or vetting effort unless the
underlying technology is outside the WG's charter. In fact if uncorrected,
these actions, happening inside of what is publicly touted as a fair and
open standards org  may also constitute restraint of trade or possibly
something like antitrust. I am not a lawyer so I cant say for sure, but
clearly this would never pass the sniff test of any big auditor.  And it
certainly causes damage to those that would need to avail themselves of the
IETF's standards process for commercial or professions reasons.

The real point in all of this is that over the years the focus of the IETF
has shifted form standards to RFC's as the final deliverable and this  is
the real biting issue. The problem is that according to the original IETF
concept I-D's were not public documents outside the specific WG and they are
now regularly referenced by other WG's as though they were vetted RFC's and
the IETF's commentary is the "they are not responsible for what people do
with their work" except that it is them that benefits by corrupting the
standards process once defined for equality. With that as an underlying
precept, the idea of enforcing fair-play then the first document that the
public should see is the RFC... if that's true then, the process of creating
a RFC needs to be mechanical in nature.

By the way - this adoption of constraints and operating ideas would increase
the value of the IETF standards process since it would allow for anyone to
file a I-D and get it vetted to a RFC. The real issue here is that there are
a number of you out there that want to continue to be able to represent a
IETF RFC as a standard and that is the problem in a nut shell. That and all
that goes along with it.

Just my two cents, but until these things happen PKIX will just be the Steve
and Tim Show.

Todd Glassey
  -----Original Message-----
  From: [e-mail] [mailto:[e-mail]]On
Behalf Of Santosh Chokhani
  Sent: Thursday, March 27, 2003 5:08 AM
  To: 'Yee, Peter'; 'ietf-pkix'
  Subject: RE: [TAP straw poll] 'in favour'


  Peter:

  In my mind, TAP provides one of the infrastructure services and builds on
trusted time stamp in order to support non-repudiation.

  Thus, it belongs in PKIX and no separate WG is required.

  -----Original Message-----
  From: Yee, Peter [mailto:[e-mail]]
  Sent: Wednesday, March 26, 2003 10:04 PM
  To: 'Santosh Chokhani'; 'ietf-pkix'
  Subject: RE: [TAP straw poll] 'in favour'


    Yes, but are you in favor of TAP being done in PKIX or elsewhere?

                                    -Peter
      -----Original Message-----
      From: Santosh Chokhani [mailto:[e-mail]]
      Sent: Wednesday, March 26, 2003 3:28 PM
      To: 'tho'; 'ietf-pkix'
      Subject: RE: [TAP straw poll] 'in favour'


      I am also in favor of TAP

         -----Original Message-----
        From:   [e-mail]
[mailto:[e-mail]]  On Behalf Of tho
        Sent:   Wednesday, March 26, 2003 11:42 AM
        To:     ietf-pkix
        Subject:        [TAP straw poll] 'in favour'



------=_NextPart_000_0051_01C2F42F.A75DFC70
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252">
<META content=3D"MSHTML 6.00.2800.1141" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D010501414-27032003><FONT face=3DArial color=3D#0000ff =

size=3D2>Personally I want to see TAP advanced as I want to add&nbsp;XML =

timestamps and/or the BERT/NTP Tokens to it, and like Santosh, I think =
PKIX is=20
the right place for it. However - what is not part of PKIX's domain is =
the core=20
underlying scientific modeling of PKI technology. That belongs in the =
IRTF and=20
into in the mainstream IETF. That is unless&nbsp;the standards process =
is split=20
up as I suggested to POISED and the WG members are allowed to file for =
Standards=20
under the IRTF or IETF banners.</FONT></SPAN></DIV>
<DIV><SPAN class=3D010501414-27032003><FONT face=3DArial color=3D#0000ff =

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

size=3D2>---</FONT></SPAN></DIV>
<DIV><SPAN class=3D010501414-27032003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D010501414-27032003><FONT face=3DArial color=3D#0000ff =
size=3D2>On the=20
issue of why this conversation is even necessary -&nbsp; what is really =
funny=20
about this is watching what is happening to Santosh Chokani, a brilliant =
and=20
renowned key player in the Standards Community and&nbsp;Federal Systems =
World as=20
he tries&nbsp;to navigate the same waters that I have been slammed by =
this WG=20
for years now for treading into. Its more than funny - it clearly =
demonstrates=20
the lake of "true standards process" that this WG and in fact the whole =
IETF=20
allows with its undefined vetting process and requirements therein. =
Arbitrary=20
Arbitrary Arbitrary... Special Interest Groups extraordinaire=20
eh?</FONT></SPAN></DIV>
<DIV><SPAN class=3D010501414-27032003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D010501414-27032003><FONT face=3DArial color=3D#0000ff =
size=3D2>Look,=20
with the lack of a formally defined vetting and standards escalation =
process,=20
each WG little more that&nbsp;a Special Interest Group and for some =
reason the=20
majority of players here&nbsp;have this idea that they need to be =
involved with=20
everything that this group does, and that the group cannot do anything =
that they=20
are not involved in more importantly.&nbsp; Which if you think about it =
is why=20
there is this conversation in the first place - so I ask you in a fair =
and open=20
standards environment - why is there any say as to what proto-typical =
efforts=20
are accepted and which are not??? </FONT></SPAN><SPAN=20
class=3D010501414-27032003><FONT face=3DArial color=3D#0000ff =
size=3D2>If you don't have=20
a fear that some young upstart protocol is going to unseat yours, then =
why is=20
this an issue?</FONT></SPAN></DIV><SPAN class=3D010501414-27032003>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><FONT =
face=3DArial color=3D#0000ff=20
size=3D2></FONT><BR><FONT face=3DArial><FONT color=3D#0000ff><FONT=20
size=3D2>So&nbsp;<SPAN class=3D010501414-27032003>once again I will =
voice that what=20
</SPAN>PKIX&nbsp;<SPAN class=3D010501414-27032003>and the whole IETF =
</SPAN>needs=20
is a real fair process put in place, and that means that I-D's are =
accepted=20
whet<SPAN class=3D010501414-27032003>h</SPAN>er the larger group wants =
to or=20
not.&nbsp;<SPAN class=3D010501414-27032003>In fact the larger group =
should only be=20
involved after the I-D is published. </SPAN>And the vetting process=20
for&nbsp;<SPAN class=3D010501414-27032003>taking the I-D's to RFC</SPAN> =

is&nbsp;<SPAN class=3D010501414-27032003>made </SPAN>mechanical<SPAN=20
class=3D010501414-27032003>, n</SPAN>ot one that requires total focus of =
the=20
grou<SPAN class=3D010501414-27032003>p</SPAN>, but rather those that =
committed at=20
the filing of the draft to be a part of its vetting team. Say&nbsp;<SPAN =

class=3D010501414-27032003>then </SPAN>that the&nbsp;<SPAN=20
class=3D010501414-27032003>"Stage One" </SPAN>vetting team needs to be =
at minimum=20
three separate orgs or players.<SPAN class=3D010501414-27032003> =
</SPAN><SPAN=20
class=3D010501414-27032003>Then - this might actually be fair and an =
equal=20
opportunity for all.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV></SPAN><SPAN class=3D010501414-27032003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Under that model Santosh or CygnaCOM would file the I-D and it =
would get=20
vetted through RFC and then the WG would start its decisions on whether =
to focus=20
on it as a standard's effort. By that time the RFC would have enough =
detail to=20
allow the group to see whether it made sense and others to see whether =
it was=20
right for their adoption.&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D010501414-27032003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D010501414-27032003><FONT face=3DArial color=3D#0000ff =
size=3D2>The=20
problem for many with this proposal&nbsp;is that&nbsp;this devalues the =
RFC by=20
making getting it a much easier process - and that is something that =
many do not=20
want to happen since they actively proffer RFC's as standards to other =
orgs and=20
this will&nbsp;hurt their political or commercial agendas in their own =
efforts=20
to manipulate the standards process.</FONT></SPAN></DIV>
<DIV><SPAN class=3D010501414-27032003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D010501414-27032003><FONT face=3DArial color=3D#0000ff =
size=3D2>As=20
part of defining the vetting process, it&nbsp;needs to be clearly stated =
that it=20
is not allowed for a&nbsp;WG to refuse&nbsp;a filing or vetting=20
effort&nbsp;unless the underlying technology is outside the WG's =
charter. In=20
fact&nbsp;if uncorrected, these actions, happening =
inside&nbsp;of&nbsp;what is=20
publicly touted as a fair and open standards org &nbsp;may also=20
constitute&nbsp;restraint of trade or possibly something like antitrust. =
I am=20
not a lawyer&nbsp;so I cant say for sure, but clearly this&nbsp;would =
never pass=20
the sniff test of any big auditor.&nbsp; </FONT></SPAN><SPAN=20
class=3D010501414-27032003><FONT face=3DArial color=3D#0000ff =
size=3D2>And it certainly=20
causes damage to those that would need to avail themselves of the IETF's =

standards process for commercial or professions reasons.&nbsp;=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D010501414-27032003></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D010501414-27032003></SPAN><SPAN =
class=3D010501414-27032003><FONT=20
face=3DArial color=3D#0000ff size=3D2>The real&nbsp;point in all of this =
is that over=20
the years the focus of the IETF has shifted form standards to RFC's as =
the final=20
deliverable and this&nbsp; is the real biting issue. The problem is that =

according to the original IETF concept I-D's were not public documents =
outside=20
the specific WG and they are now regularly referenced by other WG's as =
though=20
they were vetted RFC's and the IETF's commentary is the "they are not=20
responsible for what people do with their work" except that it is them =
that=20
benefits by corrupting the standards process once defined for equality. =
With=20
that as an underlying precept, the idea of enforcing fair-play then the =
first=20
document that the public should see is the RFC...&nbsp;if that's true =
then, the=20
process&nbsp;of creating a RFC needs to be mechanical in=20
nature.</FONT></SPAN></DIV>
<DIV><SPAN class=3D010501414-27032003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D010501414-27032003><FONT face=3DArial color=3D#0000ff =
size=3D2>By the=20
way - this adoption of constraints and operating ideas would increase =
the value=20
of the IETF standards process since it would allow for anyone to file a =
I-D and=20
get it vetted to a RFC. The real issue&nbsp;here is that there are a =
number of=20
you out there that want to continue to be able to represent a IETF RFC =
as a=20
standard and that is the problem in a nut shell. That and all that goes =
along=20
with it.</FONT></SPAN></DIV>
<DIV><SPAN class=3D010501414-27032003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D010501414-27032003><FONT face=3DArial color=3D#0000ff =
size=3D2>Just=20
my two cents, but until these things happen PKIX will just be the Steve =
and Tim=20
Show. </FONT></SPAN></DIV>
<DIV><SPAN class=3D010501414-27032003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D010501414-27032003><FONT face=3DArial color=3D#0000ff =
size=3D2>Todd=20
Glassey</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> =
[e-mail]=20
  [mailto:[e-mail]]<B>On Behalf Of </B>Santosh=20
  Chokhani<BR><B>Sent:</B> Thursday, March 27, 2003 5:08 =
AM<BR><B>To:</B> 'Yee,=20
  Peter'; 'ietf-pkix'<BR><B>Subject:</B> RE: [TAP straw poll] 'in=20
  favour'<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D282090613-27032003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Peter:</FONT></SPAN></DIV>
  <DIV><SPAN class=3D282090613-27032003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D282090613-27032003><FONT face=3DArial =
color=3D#0000ff size=3D2>In=20
  my mind, TAP provides one of the infrastructure services and builds on =
trusted=20
  time stamp in order to support non-repudiation.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D282090613-27032003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D282090613-27032003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Thus, it belongs in PKIX and no separate WG is=20
  required.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D282090613-27032003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV></DIV>
  <DIV><FONT face=3DTahoma size=3D2>-----Original =
Message-----<BR><B>From:</B> Yee,=20
  Peter [mailto:[e-mail]] <BR><B>Sent:</B> Wednesday, March =
26, 2003=20
  10:04 PM<BR><B>To:</B> 'Santosh Chokhani'; =
'ietf-pkix'<BR><B>Subject:</B> RE:=20
  [TAP straw poll] 'in favour'<BR><BR></DIV></FONT>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV><SPAN class=3D949510303-27032003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>Yes, but are you in favor of TAP being done in PKIX or=20
    elsewhere?</FONT></SPAN></DIV>
    <DIV><SPAN class=3D949510303-27032003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN=20
    =
class=3D949510303-27032003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    <FONT face=3DArial color=3D#0000ff =
size=3D2>-Peter</FONT></SPAN></DIV>
    <BLOCKQUOTE=20
    style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid">
      <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
      size=3D2>-----Original Message-----<BR><B>From:</B> Santosh =
Chokhani=20
      [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, March =
26, 2003=20
      3:28 PM<BR><B>To:</B> 'tho'; 'ietf-pkix'<BR><B>Subject:</B> RE: =
[TAP straw=20
      poll] 'in favour'<BR><BR></FONT></DIV><!-- Converted from text/rtf =
format -->
      <P><FONT face=3DArial color=3D#0000ff size=3D2>I am also in favor =
of TAP</FONT>=20
      </P>
      <UL>
        <P><FONT face=3DArial></FONT>&nbsp;<FONT face=3DTahoma =
size=3D1>-----Original=20
        Message-----</FONT> <BR><B><FONT face=3DTahoma size=3D1>From:=20
        &nbsp;</FONT></B> <FONT face=3DTahoma =
size=3D1>[e-mail]=20
        [</FONT><A href=3D"mailto:[e-mail]"><U><FONT =

        face=3DTahoma color=3D#0000ff=20
        size=3D1>mailto:[e-mail]</FONT></U></A><FONT =

        face=3DTahoma size=3D1>]&nbsp;</FONT><B> <FONT face=3DTahoma =
size=3D1>On Behalf=20
        Of</FONT></B> <FONT face=3DTahoma size=3D1>tho</FONT> =
<BR><B><FONT=20
        face=3DTahoma size=3D1>Sent:&nbsp;&nbsp;</FONT></B> <FONT =
face=3DTahoma=20
        size=3D1>Wednesday, March 26, 2003 11:42 AM</FONT> <BR><B><FONT=20
        face=3DTahoma size=3D1>To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> =
<FONT=20
        face=3DTahoma size=3D1>ietf-pkix</FONT> <BR><B><FONT =
face=3DTahoma=20
        =
size=3D1>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B>=20
        <FONT face=3DTahoma size=3D1>[TAP straw poll] 'in favour'</FONT> =

    </P><BR></UL></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0051_01C2F42F.A75DFC70--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2RF1xo21436 for ietf-pkix-bks; Thu, 27 Mar 2003 07:01:59 -0800 (PST)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2RF1wg21430 for <[e-mail]>; Thu, 27 Mar 2003 07:01:58 -0800 (PST)
Received: from [10.4.58.234] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2RF1R60012887; Thu, 27 Mar 2003 10:01:29 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05111a04baa8c1a2f7dd@[10.4.58.234]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Thu, 27 Mar 2003 10:01:18 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: TAP
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>I totally agree with Peter here - the PKIX WG has enough on its plate
>already as is probably evidenced by the tiny amount of time that seems
>to be devoted to "non-core" I-Ds these days, and in any case, there
>may well be more compelling applications on which to work if we were
>to properly consider a PKIXEXT or PKIXAPPS WG charter (I'd argue that
>chartering PKIXAPPS is the appropriate thing for this community at
>this point).
>
>Just to mention two possible examples - there is a need for PKI
>support for Diameter and SIP and I don't believe (though I'm open
>to correction here) that such things are getting the level of
>attention in the IETF that they deserve - leaving open (or likely?)
>the possibility that people who want to secure those protocols
>will not use PKI, or will use it badly, or even (heaven forbid)
>start to develop another certificate management protocol! I'm sure
>that a PKIXAPPS chartering process will turn up some more such
>cases, and probably even more interesting ones too.
>
>Stephen.

Stephen & Peter,

I think there is a big distinction between the TAP proposal and the 
Diameter & SIP work you suggest. TAP is an infrastructure element, 
potentially supportive
  of a wide range of applications that require archive. SIP and 
Diameter are specific applications. Our philosophy in PKIX has been 
to let each application develop its own profile(s) for use of PKI in 
the corresponding WG. S/MIME did that, as did TLS, and now IPsec. So, 
I would not consider the examples you suggested as appropriate for 
PKIX or for any other PKI-centric WG.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2REJ9x17153 for ietf-pkix-bks; Thu, 27 Mar 2003 06:19:09 -0800 (PST)
Received: from smtp1.cp.tin.it (vsmtp1.tin.it [212.216.176.221]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2REJ7g17149 for <[e-mail]>; Thu, 27 Mar 2003 06:19:07 -0800 (PST)
Received: from congo.homeunix.net (80.181.227.100) by smtp1.cp.tin.it (6.5.033) id 3E70BBAC005C0F7E; Thu, 27 Mar 2003 15:17:15 +0100
Received: from host100-227.pool80181.interbusiness.it (localhost [127.0.0.1]) by congo.homeunix.net (8.12.3/8.12.3) with ESMTP id h2REHBgE000894; Thu, 27 Mar 2003 15:17:12 +0100 (CET) (envelope-from [e-mail])
Received: (from tho@localhost) by host100-227.pool80181.interbusiness.it (8.12.3/8.12.3/Submit) id h2REHA7u000893; Thu, 27 Mar 2003 15:17:10 +0100 (CET)
Date: Thu, 27 Mar 2003 15:17:09 +0100
From: tho <[e-mail]>
To: "Yee, Peter" <[e-mail]>
Cc: ietf-pkix <[e-mail]>
Subject: Re: [TAP straw poll] 'in favour'
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Mar 26, 2003 at 07:04:19PM -0800
X-Operating-System: FreeBSD
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Mar 26, 2003 at 07:04:19PM -0800, Yee, Peter wrote:
> Yes, but are you in favor of TAP being done in PKIX or elsewhere?

The TAP document fits particularly well into the fifth area discussed
in the 'roadmap' (time-stamping and data certification services), so I
think it should be treated as a PKIX work item.

Thomas


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2REEnE17059 for ietf-pkix-bks; Thu, 27 Mar 2003 06:14:49 -0800 (PST)
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2REEjg17053 for <[e-mail]>; Thu, 27 Mar 2003 06:14:45 -0800 (PST)
Received: from chokhani (4.washington-15rh15rt.dc.dial-access.att.net[12.91.132.4]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003032714144011300k3imee>; Thu, 27 Mar 2003 14:14:40 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>, "'Yee, Peter'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: TAP
Date: Thu, 27 Mar 2003 09:15:04 -0500
Message-ID: <004201c2f46b$43fe1c00$d600a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2REEjg17054
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve:

I do not know what Diameter and SIP are.

If the PKIX is overwhelmed and another group needs to be spun off, that is a
workload issue.

I do see the TAP as more of an infrastructure service in support of
non-repudiation as opposed to an application.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Farrell
Sent: Thursday, March 27, 2003 5:56 AM
To: Yee, Peter
Cc: [e-mail]; [e-mail]
Subject: Re: TAP




I totally agree with Peter here - the PKIX WG has enough on its plate 
already as is probably evidenced by the tiny amount of time that seems 
to be devoted to "non-core" I-Ds these days, and in any case, there 
may well be more compelling applications on which to work if we were 
to properly consider a PKIXEXT or PKIXAPPS WG charter (I'd argue that
chartering PKIXAPPS is the appropriate thing for this community at 
this point). 

Just to mention two possible examples - there is a need for PKI 
support for Diameter and SIP and I don't believe (though I'm open 
to correction here) that such things are getting the level of 
attention in the IETF that they deserve - leaving open (or likely?) 
the possibility that people who want to secure those protocols 
will not use PKI, or will use it badly, or even (heaven forbid) 
start to develop another certificate management protocol! I'm sure that a
PKIXAPPS chartering process will turn up some more such cases, and probably
even more interesting ones too.

Stephen.

"Yee, Peter" wrote:
> 
> Although I believe TAP is a useful addition to the set of tools 
> surrounding a PKI, I feel that it is further removed from the core PKI 
> functionality on which PKIX should be working to standardize in this 
> group.  Perhaps a PKIXEXT or PKIXAPPS working group is merited.
> 
>                                                 -Peter Yee

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2RDa8u15832 for ietf-pkix-bks; Thu, 27 Mar 2003 05:36:08 -0800 (PST)
Received: from smtp.comcast.net (smtp-out.comcast.net [24.153.64.116]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2RDa2g15824 for <[e-mail]>; Thu, 27 Mar 2003 05:36:02 -0800 (PST)
Received: from SJOSEPH (pcp239416pcs.elictc01.md.comcast.net [68.55.244.2]) by mtaout08.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with SMTP id <[e-mail]> for [e-mail]; Thu, 27 Mar 2003 08:34:34 -0500 (EST)
Date: Thu, 27 Mar 2003 08:33:05 -0500
From: Al Arsenault <[e-mail]>
Subject: Re: TAP
To: [e-mail], "Yee, Peter" <[e-mail]>
Cc: [e-mail], [e-mail]
Message-id: <067f01c2f465$67c25b20$6501a8c0@SJOSEPH>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree whole-heartedly with Stephen Farrell here.  I think TAP is a
potentially useful protocol.  I don't think it should go into PKIX right
now.  And I think chartering a PKIAPPS working group might be the right way
to go.

                Al Arsenault


----- Original Message -----
From: "Stephen Farrell" <[e-mail]>
To: "Yee, Peter" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Thursday, March 27, 2003 5:55 AM
Subject: Re: TAP


>
>
> I totally agree with Peter here - the PKIX WG has enough on its plate
> already as is probably evidenced by the tiny amount of time that seems
> to be devoted to "non-core" I-Ds these days, and in any case, there
> may well be more compelling applications on which to work if we were
> to properly consider a PKIXEXT or PKIXAPPS WG charter (I'd argue that
> chartering PKIXAPPS is the appropriate thing for this community at
> this point).
>
> Just to mention two possible examples - there is a need for PKI
> support for Diameter and SIP and I don't believe (though I'm open
> to correction here) that such things are getting the level of
> attention in the IETF that they deserve - leaving open (or likely?)
> the possibility that people who want to secure those protocols
> will not use PKI, or will use it badly, or even (heaven forbid)
> start to develop another certificate management protocol! I'm sure
> that a PKIXAPPS chartering process will turn up some more such
> cases, and probably even more interesting ones too.
>
> Stephen.
>
> "Yee, Peter" wrote:
> >
> > Although I believe TAP is a useful addition to the set of tools
surrounding
> > a PKI, I feel that it is further removed from the core PKI functionality
> > on which PKIX should be working to standardize in this group.  Perhaps a
> > PKIXEXT or PKIXAPPS working group is merited.
> >
> >                                                 -Peter Yee
>
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) [phone]
> 39 Parkgate Street,                     fax: [phone]
> Dublin 8.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2RD87U14237 for ietf-pkix-bks; Thu, 27 Mar 2003 05:08:07 -0800 (PST)
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2RD86g14232 for <[e-mail]>; Thu, 27 Mar 2003 05:08:06 -0800 (PST)
Received: from chokhani (108.washington-15rh15rt.dc.dial-access.att.net[12.91.132.108]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003032713075511300k3u2ve>; Thu, 27 Mar 2003 13:07:55 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Yee, Peter'" <[e-mail]>, "'ietf-pkix'" <[e-mail]>
Subject: RE: [TAP straw poll] 'in favour'
Date: Thu, 27 Mar 2003 08:08:20 -0500
Message-ID: <001a01c2f461$f0c17310$d600a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C2F438.07EB6B10"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_001B_01C2F438.07EB6B10
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Peter:
=20
In my mind, TAP provides one of the infrastructure services and builds =
on
trusted time stamp in order to support non-repudiation.
=20
Thus, it belongs in PKIX and no separate WG is required.
=20
-----Original Message-----
From: Yee, Peter [mailto:[e-mail]]=20
Sent: Wednesday, March 26, 2003 10:04 PM
To: 'Santosh Chokhani'; 'ietf-pkix'
Subject: RE: [TAP straw poll] 'in favour'



Yes, but are you in favor of TAP being done in PKIX or elsewhere?
=20
                                -Peter

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Wednesday, March 26, 2003 3:28 PM
To: 'tho'; 'ietf-pkix'
Subject: RE: [TAP straw poll] 'in favour'



I am also in favor of TAP=20

	 -----Original Message-----=20
From:   [e-mail] [ =
<mailto:[e-mail]>
mailto:[e-mail]]  On Behalf Of tho=20
Sent:   Wednesday, March 26, 2003 11:42 AM=20
To:     ietf-pkix=20
Subject:        [TAP straw poll] 'in favour'=20



------=_NextPart_000_001B_01C2F438.07EB6B10
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1141" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D282090613-27032003><FONT face=3DArial color=3D#0000ff =

size=3D2>Peter:</FONT></SPAN></DIV>
<DIV><SPAN class=3D282090613-27032003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D282090613-27032003><FONT face=3DArial color=3D#0000ff =
size=3D2>In my=20
mind, TAP provides one of the infrastructure services and builds on =
trusted time=20
stamp in order to support non-repudiation.</FONT></SPAN></DIV>
<DIV><SPAN class=3D282090613-27032003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D282090613-27032003><FONT face=3DArial color=3D#0000ff =
size=3D2>Thus,=20
it belongs in PKIX and no separate WG is required.</FONT></SPAN></DIV>
<DIV><SPAN class=3D282090613-27032003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV></DIV>
<DIV><FONT face=3DTahoma size=3D2>-----Original =
Message-----<BR><B>From:</B> Yee,=20
Peter [mailto:[e-mail]] <BR><B>Sent:</B> Wednesday, March =
26, 2003=20
10:04 PM<BR><B>To:</B> 'Santosh Chokhani'; =
'ietf-pkix'<BR><B>Subject:</B> RE:=20
[TAP straw poll] 'in favour'<BR><BR></DIV></FONT>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV><SPAN class=3D949510303-27032003><FONT face=3DArial =
color=3D#0000ff size=3D2>Yes,=20
  but are you in favor of TAP being done in PKIX or=20
  elsewhere?</FONT></SPAN></DIV>
  <DIV><SPAN class=3D949510303-27032003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN=20
  =
class=3D949510303-27032003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  <FONT face=3DArial color=3D#0000ff size=3D2>-Peter</FONT></SPAN></DIV>
  <BLOCKQUOTE=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani =

    [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, March 26, =
2003=20
    3:28 PM<BR><B>To:</B> 'tho'; 'ietf-pkix'<BR><B>Subject:</B> RE: [TAP =
straw=20
    poll] 'in favour'<BR><BR></FONT></DIV><!-- Converted from text/rtf =
format -->
    <P><FONT face=3DArial color=3D#0000ff size=3D2>I am also in favor of =
TAP</FONT>=20
    </P>
    <UL>
      <P><FONT face=3DArial></FONT>&nbsp;<FONT face=3DTahoma =
size=3D1>-----Original=20
      Message-----</FONT> <BR><B><FONT face=3DTahoma size=3D1>From:=20
      &nbsp;</FONT></B> <FONT face=3DTahoma =
size=3D1>[e-mail]=20
      [</FONT><A href=3D"mailto:[e-mail]"><U><FONT =
face=3DTahoma=20
      color=3D#0000ff=20
      size=3D1>mailto:[e-mail]</FONT></U></A><FONT =
face=3DTahoma=20
      size=3D1>]&nbsp;</FONT><B> <FONT face=3DTahoma size=3D1>On Behalf =
Of</FONT></B>=20
      <FONT face=3DTahoma size=3D1>tho</FONT> <BR><B><FONT face=3DTahoma =

      size=3D1>Sent:&nbsp;&nbsp;</FONT></B> <FONT face=3DTahoma =
size=3D1>Wednesday,=20
      March 26, 2003 11:42 AM</FONT> <BR><B><FONT face=3DTahoma=20
      size=3D1>To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT =
face=3DTahoma=20
      size=3D1>ietf-pkix</FONT> <BR><B><FONT face=3DTahoma=20
      =
size=3D1>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> =
<FONT=20
      face=3DTahoma size=3D1>[TAP straw poll] 'in favour'</FONT>=20
  </P><BR></UL></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_001B_01C2F438.07EB6B10--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2RAudG03312 for ietf-pkix-bks; Thu, 27 Mar 2003 02:56:39 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2RAuZg03308 for <[e-mail]>; Thu, 27 Mar 2003 02:56:37 -0800 (PST)
Received: from Baltimore-FW2 ([172.19.1.2]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h2RArs818721 for <[e-mail]>; Thu, 27 Mar 2003 10:53:54 GMT
Received: from  ([10.153.25.53]) by Baltimore-FW2; Thu, 27 Mar 2003 10:54:24 +0000 (GMT)
Received: from Baltimore-FW2 (wilde-i-2.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Thu, 27 Mar 2003 10:56:13 +0000
Received: from  ([10.153.25.10]) by Baltimore-FW2; Thu, 27 Mar 2003 10:54:22 +0000 (GMT)
Received: from baltimore.ie (wks188-25.ie.baltimore.com [10.153.25.188]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id KAA22679; Thu, 27 Mar 2003 10:56:27 GMT
Message-ID: <[e-mail]>
Date: Thu, 27 Mar 2003 10:55:59 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Yee, Peter" <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: TAP
References: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I totally agree with Peter here - the PKIX WG has enough on its plate 
already as is probably evidenced by the tiny amount of time that seems 
to be devoted to "non-core" I-Ds these days, and in any case, there 
may well be more compelling applications on which to work if we were 
to properly consider a PKIXEXT or PKIXAPPS WG charter (I'd argue that
chartering PKIXAPPS is the appropriate thing for this community at 
this point). 

Just to mention two possible examples - there is a need for PKI 
support for Diameter and SIP and I don't believe (though I'm open 
to correction here) that such things are getting the level of 
attention in the IETF that they deserve - leaving open (or likely?) 
the possibility that people who want to secure those protocols 
will not use PKI, or will use it badly, or even (heaven forbid) 
start to develop another certificate management protocol! I'm sure
that a PKIXAPPS chartering process will turn up some more such
cases, and probably even more interesting ones too.

Stephen.

"Yee, Peter" wrote:
> 
> Although I believe TAP is a useful addition to the set of tools surrounding
> a PKI, I feel that it is further removed from the core PKI functionality
> on which PKIX should be working to standardize in this group.  Perhaps a
> PKIXEXT or PKIXAPPS working group is merited.
> 
>                                                 -Peter Yee

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2R34bm25243 for ietf-pkix-bks; Wed, 26 Mar 2003 19:04:37 -0800 (PST)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2R34Zg25235 for <[e-mail]>; Wed, 26 Mar 2003 19:04:35 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 27 Mar 2003 03:04:44 UT
Received: from exrsa01.rsa.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (8.11.6/8.11.6) with ESMTP id h2R34NE02173; Wed, 26 Mar 2003 22:04:29 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <GMCR3SKY>; Wed, 26 Mar 2003 19:04:22 -0800
Message-ID: <[e-mail]>
From: "Yee, Peter" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, "'ietf-pkix'" <[e-mail]>
Subject: RE: [TAP straw poll] 'in favour'
Date: Wed, 26 Mar 2003 19:04:19 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2F40D.8F2EDB00"
Sender: [e-mail]
Precedence: 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_01C2F40D.8F2EDB00
Content-Type: text/plain;
	charset="iso-8859-1"

Yes, but are you in favor of TAP being done in PKIX or elsewhere?
 
                                -Peter

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Wednesday, March 26, 2003 3:28 PM
To: 'tho'; 'ietf-pkix'
Subject: RE: [TAP straw poll] 'in favour'



I am also in favor of TAP 

	 -----Original Message----- 
From:   [e-mail] [
<mailto:[e-mail]> mailto:[e-mail]]
On Behalf Of tho 
Sent:   Wednesday, March 26, 2003 11:42 AM 
To:     ietf-pkix 
Subject:        [TAP straw poll] 'in favour' 



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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: [TAP straw poll] 'in favour'</TITLE>

<META content=3D"MSHTML 6.00.2800.1141" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D949510303-27032003><FONT face=3DArial =
color=3D#0000ff size=3D2>Yes,=20
but are you in favor of TAP being done in PKIX or =
elsewhere?</FONT></SPAN></DIV>
<DIV><SPAN class=3D949510303-27032003><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
class=3D949510303-27032003>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<FONT face=3DArial color=3D#0000ff size=3D2>-Peter</FONT></SPAN></DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, March 26, =
2003 3:28=20
  PM<BR><B>To:</B> 'tho'; 'ietf-pkix'<BR><B>Subject:</B> RE: [TAP straw =
poll]=20
  'in favour'<BR><BR></FONT></DIV><!-- Converted from text/rtf format =
-->
  <P><FONT face=3DArial color=3D#0000ff size=3D2>I am also in favor of =
TAP</FONT> </P>
  <UL>
    <P><FONT face=3DArial></FONT>&nbsp;<FONT face=3DTahoma =
size=3D1>-----Original=20
    Message-----</FONT> <BR><B><FONT face=3DTahoma size=3D1>From: =
&nbsp;</FONT></B>=20
    <FONT face=3DTahoma size=3D1>[e-mail] =
[</FONT><A=20
    href=3D"mailto:[e-mail]"><U><FONT face=3DTahoma =

    color=3D#0000ff =
size=3D1>mailto:[e-mail]</FONT></U></A><FONT=20
    face=3DTahoma size=3D1>]&nbsp;</FONT><B> <FONT face=3DTahoma =
size=3D1>On Behalf=20
    Of</FONT></B> <FONT face=3DTahoma size=3D1>tho</FONT> <BR><B><FONT =
face=3DTahoma=20
    size=3D1>Sent:&nbsp;&nbsp;</FONT></B> <FONT face=3DTahoma =
size=3D1>Wednesday,=20
    March 26, 2003 11:42 AM</FONT> <BR><B><FONT face=3DTahoma=20
    size=3D1>To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT face=3DTahoma =

    size=3D1>ietf-pkix</FONT> <BR><B><FONT face=3DTahoma=20
    =
size=3D1>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> =
<FONT=20
    face=3DTahoma size=3D1>[TAP straw poll] 'in favour'</FONT>=20
</P><BR></UL></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C2F40D.8F2EDB00--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2R24pr22723 for ietf-pkix-bks; Wed, 26 Mar 2003 18:04:51 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2R24ng22719 for <[e-mail]>; Wed, 26 Mar 2003 18:04:49 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.8/8.12.8) with ESMTP id h2R24X5d032598; Thu, 27 Mar 2003 14:04:33 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h2R24Xv22573; Thu, 27 Mar 2003 14:04:33 +1200
Date: Thu, 27 Mar 2003 14:04:33 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: draft minutes
Sender: [e-mail]
Precedence: 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:

>My Eudora mail client scores messages with chili peppers if the content may be
>offensive.
>
>(1 chilli pepper = You may be offended,
> 3 chili peppers = Really bad language)
>
>This message scored 2 out of 3 chili peppers

Hmm, if it got 2 for Hunter S.Thompson I guess it's a good thing I didn't base
it the work of Rodney Rude or Kevin Bl***y Wilson (Australian cultural icons).

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QNRjs15487 for ietf-pkix-bks; Wed, 26 Mar 2003 15:27:45 -0800 (PST)
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QNRgg15483 for <[e-mail]>; Wed, 26 Mar 2003 15:27:42 -0800 (PST)
Received: from chokhani (2.washington-14rh15rt.dc.dial-access.att.net[12.91.130.2]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003032623274411100hid4ve>; Wed, 26 Mar 2003 23:27:44 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'tho'" <[e-mail]>, "'ietf-pkix'" <[e-mail]>
Subject: RE: [TAP straw poll] 'in favour'
Date: Wed, 26 Mar 2003 18:28:08 -0500
Message-ID: <003d01c2f3ef$5c935d10$d600a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01C2F3C5.73BD5510"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_003E_01C2F3C5.73BD5510
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I am also in favor of TAP

>  -----Original Message-----
> From: 	[e-mail]
> [mailto:[e-mail]]  On Behalf Of tho
> Sent:	Wednesday, March 26, 2003 11:42 AM
> To:	ietf-pkix
> Subject:	[TAP straw poll] 'in favour'
> 
> 

------=_NextPart_000_003E_01C2F3C5.73BD5510
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4630.0">
<TITLE>RE: [TAP straw poll] 'in favour'</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I am also in favor of =
TAP</FONT>
</P>
<UL>
<P><FONT FACE=3D"Arial"></FONT>&nbsp;<FONT SIZE=3D1 =
FACE=3D"Tahoma">-----Original Message-----</FONT>

<BR><B><FONT SIZE=3D1 FACE=3D"Tahoma">From: &nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Tahoma">[e-mail] [</FONT><A =
HREF=3D"mailto:[e-mail]"><U><FONT COLOR=3D"#0000FF" =
SIZE=3D1 =
FACE=3D"Tahoma">mailto:[e-mail]</FONT></U></A><FONT =
SIZE=3D1 FACE=3D"Tahoma">]&nbsp;</FONT><B> <FONT SIZE=3D1 =
FACE=3D"Tahoma">On Behalf Of</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Tahoma">tho</FONT>

<BR><B><FONT SIZE=3D1 FACE=3D"Tahoma">Sent:&nbsp;&nbsp;</FONT></B> <FONT =
SIZE=3D1 FACE=3D"Tahoma">Wednesday, March 26, 2003 11:42 AM</FONT>

<BR><B><FONT SIZE=3D1 =
FACE=3D"Tahoma">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=3D1 =
FACE=3D"Tahoma">ietf-pkix</FONT>

<BR><B><FONT SIZE=3D1 =
FACE=3D"Tahoma">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT>=
</B> <FONT SIZE=3D1 FACE=3D"Tahoma">[TAP straw poll] 'in favour'</FONT>
</P>
<BR>
</UL>
</BODY>
</HTML>
------=_NextPart_000_003E_01C2F3C5.73BD5510--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QKAcT06768 for ietf-pkix-bks; Wed, 26 Mar 2003 12:10:38 -0800 (PST)
Received: from vmmr9.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QKAZg06760 for <[e-mail]>; Wed, 26 Mar 2003 12:10:36 -0800 (PST)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr9.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id PCW89885; Wed, 26 Mar 2003 15:08:38 -0500 (EST)
Received: from laptop-cpq.retrospekt.com (1Cust182.tnt12.stk3.swe.da.uu.net [213.116.249.182]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ACQ30757; Wed, 26 Mar 2003 15:08:35 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 26 Mar 2003 21:08:24 +0100
To: [e-mail] (Peter Gutmann), [e-mail], [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: Re: draft minutes
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Just an interesting observation.

My Eudora mail client scores messages with chili peppers if the content may 
be offensive.
(1 chilli pepper = You may be offended,
3 chili peppers = Really bad language)

This message scored 2 out of 3 chili peppers

Otherwise I agree with Steve :)

/Stefan

At 14:14 2003-03-25 +1200, Peter Gutmann wrote:

>Stephen Kent <[e-mail]> writes:
>
> >Attached are the draft minutes from last week's PKIX meeting.
>
>Boooooring!  Here's my take on how it went:
>
>We were somewhere in San Francisco on the edge of the 56th IETF when the drugs
>began to take hold.  I remember saying something like "I feel a bit
>lightheaded; maybe you should take notes...."  And suddenly there was a
>terrible roar all around us and the sky was full of what looked like huge
>OIDs, all swooping and screeching and diving around the RFC, which was about a
>hundred pages long.  And a voice was screaming: "Holy Jesus!  Where are these
>goddamn business cases?"
>
>Then it was quiet again.  My attorney had taken his shirt off and was pouring
>beer into his mouth, to facilitate the PKI standards-creation process.  "What
>the hell are you yelling about?" he muttered, staring up at the neon lights
>with his eyes closed and covered with wraparound Spanish sunglasses.  "Never
>mind," I said. "It.s your turn to figure out the interop requirements."  I hit
>the brakes and dropped the Great Pile of Paperwork at the side of the room.
>No point mentioning those OIDs, I thought.  The poor bastard will see them
>soon enough.
>
>We had two bags of X.509 standards, seventy-five pages of PKIX mailing list
>printouts, five sheets of high-powered constraints, a saltshaker half-full of
>vendor hype, and a whole galaxy of requirements, restrictions, promises,
>threats...  Also, a quart of OSI, a quart of LDAP, a case of XML, a pint of
>raw X.500, and two dozen PGPs.  Not that we needed all that for the trip, but
>once you get into a serious PKI RFC binge, the tendency is to push it as far
>as you can.  The only thing that really worried me was the X.500.  There is
>nothing in the world more helpless and irresponsible and depraved than a man
>in the depths of an X.500 binge, and I knew we'd get into that rotten stuff
>pretty soon.
>
>Peter.

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone] 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QJVCk02655 for ietf-pkix-bks; Wed, 26 Mar 2003 11:31:12 -0800 (PST)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.6) with SMTP id h2QJVBg02651 for <[e-mail]>; Wed, 26 Mar 2003 11:31:11 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Mar 2003 19:31:18 UT
Received: from exrsa01.rsa.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (8.11.6/8.11.6) with ESMTP id h2QJV7E00861; Wed, 26 Mar 2003 14:31:07 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <GMCR3RBT>; Wed, 26 Mar 2003 11:31:06 -0800
Message-ID: <[e-mail]>
From: "Yee, Peter" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: TAP
Date: Wed, 26 Mar 2003 11:31:06 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Although I believe TAP is a useful addition to the set of tools surrounding
a PKI, I feel that it is further removed from the core PKI functionality
on which PKIX should be working to standardize in this group.  Perhaps a
PKIXEXT or PKIXAPPS working group is merited.

						-Peter Yee



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QIKUd27759 for ietf-pkix-bks; Wed, 26 Mar 2003 10:20:30 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QIKTg27753 for <[e-mail]>; Wed, 26 Mar 2003 10:20:29 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA29993; Wed, 26 Mar 2003 19:20:31 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Wed, 26 Mar 2003 19:20:32 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id TAA02841; Wed, 26 Mar 2003 19:20:28 +0100 (MET)
Date: Wed, 26 Mar 2003 19:20:28 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: TAP
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Since TAP does resurrect a work item that led to RFC 3029, DVCS,
I am in favour to treat this work item in PKIX.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2QGfpD24427 for ietf-pkix-bks; Wed, 26 Mar 2003 08:41:51 -0800 (PST)
Received: from smtp1.cp.tin.it (vsmtp1.tin.it [212.216.176.221]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2QGfng24423 for <[e-mail]>; Wed, 26 Mar 2003 08:41:49 -0800 (PST)
Received: from congo.homeunix.net (80.181.227.184) by smtp1.cp.tin.it (6.5.033) id 3E70BBAC005627CE for [e-mail]; Wed, 26 Mar 2003 17:41:40 +0100
Received: from congo.homeunix.net (localhost [127.0.0.1]) by congo.homeunix.net (8.12.3/8.12.3) with ESMTP id h2QGfbF7001377 for <[e-mail]>; Wed, 26 Mar 2003 17:41:38 +0100 (CET) (envelope-from [e-mail])
Received: (from tho@localhost) by congo.homeunix.net (8.12.3/8.12.3/Submit) id h2QGfa6l001376 for [e-mail]; Wed, 26 Mar 2003 17:41:36 +0100 (CET)
Date: Wed, 26 Mar 2003 17:41:35 +0100
From: tho <[e-mail]>
To: ietf-pkix <[e-mail]>
Subject: [TAP straw poll] 'in favour'
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5.1i
X-Operating-System: FreeBSD
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2PEAW213722 for ietf-pkix-bks; Tue, 25 Mar 2003 06:10:32 -0800 (PST)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PEATg13713 for <[e-mail]>; Tue, 25 Mar 2003 06:10:29 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2PEA560018404; Tue, 25 Mar 2003 09:10:13 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100301baa6132d1c6d@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 25 Mar 2003 09:09:34 -0500
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: draft minutes
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2:14 PM +1200 3/25/03, Peter Gutmann wrote:
>Stephen Kent <[e-mail]> writes:
>
>>Attached are the draft minutes from last week's PKIX meeting.
>
>Boooooring!  Here's my take on how it went:
>
>We were somewhere in San Francisco on the edge of the 56th IETF when the drugs
>began to take hold.  I remember saying something like "I feel a bit
>lightheaded; maybe you should take notes...."  And suddenly there was a
>terrible roar all around us and the sky was full of what looked like huge
>OIDs, all swooping and screeching and diving around the RFC, which was about a
>hundred pages long.  And a voice was screaming: "Holy Jesus!  Where are these
>goddamn business cases?"
>
>Then it was quiet again.  My attorney had taken his shirt off and was pouring
>beer into his mouth, to facilitate the PKI standards-creation process.  "What
>the hell are you yelling about?" he muttered, staring up at the neon lights
>with his eyes closed and covered with wraparound Spanish sunglasses.  "Never
>mind," I said. "It.s your turn to figure out the interop requirements."  I hit
>the brakes and dropped the Great Pile of Paperwork at the side of the room.
>No point mentioning those OIDs, I thought.  The poor bastard will see them
>soon enough.
>
>We had two bags of X.509 standards, seventy-five pages of PKIX mailing list
>printouts, five sheets of high-powered constraints, a saltshaker half-full of
>vendor hype, and a whole galaxy of requirements, restrictions, promises,
>threats...  Also, a quart of OSI, a quart of LDAP, a case of XML, a pint of
>raw X.500, and two dozen PGPs.  Not that we needed all that for the trip, but
>once you get into a serious PKI RFC binge, the tendency is to push it as far
>as you can.  The only thing that really worried me was the X.500.  There is
>nothing in the world more helpless and irresponsible and depraved than a man
>in the depths of an X.500 binge, and I knew we'd get into that rotten stuff
>pretty soon.
>
>Peter.


No argument; your version is a lot more interesting :-)

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2PDFYx09506 for ietf-pkix-bks; Tue, 25 Mar 2003 05:15:34 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PDFSg09497 for <[e-mail]>; Tue, 25 Mar 2003 05:15:28 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08684; Tue, 25 Mar 2003 08:13:06 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-pr-tsa-03.txt
Date: Tue, 25 Mar 2003 08:13:06 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Policy Requirements for Time-Stamping Authorities
	Author(s)	: D. Pinkas, N. Pope, J. Ross
	Filename	: draft-ietf-pkix-pr-tsa-03.txt
	Pages		: 40
	Date		: 2003-3-24
	
This document defines requirements for a baseline time-stamp policy 
for TSAs issuing time-stamp tokens, supported by public key 
certificates, with an accuracy of one second or better. A TSA may 
define its own policy which enhances the policy defined in the 
current document. Such a policy shall incorporate or further 
constrain the requirements identified in the current document. 
The contents of this Informational RFC is technically equivalent 
to ETSI TS 102 023 V 1.2.1 (2002-06) [TS 102023] Copyright (C). 
Individual copies of this ETSI deliverable can be downloaded from 
http://www.etsi.org

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-pr-tsa-03.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-pr-tsa-03.txt

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2PDFUn09502 for ietf-pkix-bks; Tue, 25 Mar 2003 05:15:30 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2PDFRg09496 for <[e-mail]>; Tue, 25 Mar 2003 05:15:27 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08664; Tue, 25 Mar 2003 08:13:02 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-certstore-http-05.txt
Date: Tue, 25 Mar 2003 08:13:02 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Operational 
                          Protocols: Certificate Store Access via HTTP
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-pkix-certstore-http-05.txt
	Pages		: 0
	Date		: 2003-3-24
	
The protocol conventions described in this document satisfy some of the
operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP/HTTPS) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories.  Additional mechanisms addressing PKIX operational requirements are specified in separate documents.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-certstore-http-05.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-certstore-http-05.txt

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2P2cZ917440 for ietf-pkix-bks; Mon, 24 Mar 2003 18:38:35 -0800 (PST)
Received: from smtp-1.llnl.gov (smtp-1.llnl.gov [128.115.250.81]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2P2cYg17436 for <[e-mail]>; Mon, 24 Mar 2003 18:38:34 -0800 (PST)
Received: from catalyst2b.llnl.gov (localhost [127.0.0.1]) by smtp-1.llnl.gov (8.12.3/8.12.3/LLNL evision: 1.5 $) with ESMTP id h2P2cLJl015565; Mon, 24 Mar 2003 18:38:22 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Mon, 24 Mar 2003 18:37:04 -0800
To: [e-mail] (Peter Gutmann), [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: Re: draft minutes
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 02:14 PM 3/25/2003 +1200, Peter Gutmann wrote:

>Stephen Kent <[e-mail]> writes:
>
> >Attached are the draft minutes from last week's PKIX meeting.
>
>Boooooring!  Here's my take on how it went:
>
>We were somewhere in San Francisco on the edge of the 56th IETF when the drugs

Shoot!  I always miss the FUN parties :(


Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2P2FeN15928 for ietf-pkix-bks; Mon, 24 Mar 2003 18:15:40 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2P2Fdg15921 for <[e-mail]>; Mon, 24 Mar 2003 18:15:39 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.8/8.12.8) with ESMTP id h2P2EfVs019734; Tue, 25 Mar 2003 14:14:41 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h2P2EgM02539; Tue, 25 Mar 2003 14:14:42 +1200
Date: Tue, 25 Mar 2003 14:14:42 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: draft minutes
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent <[e-mail]> writes:

>Attached are the draft minutes from last week's PKIX meeting. 

Boooooring!  Here's my take on how it went:

We were somewhere in San Francisco on the edge of the 56th IETF when the drugs
began to take hold.  I remember saying something like "I feel a bit
lightheaded; maybe you should take notes...."  And suddenly there was a
terrible roar all around us and the sky was full of what looked like huge
OIDs, all swooping and screeching and diving around the RFC, which was about a
hundred pages long.  And a voice was screaming: "Holy Jesus!  Where are these
goddamn business cases?"

Then it was quiet again.  My attorney had taken his shirt off and was pouring
beer into his mouth, to facilitate the PKI standards-creation process.  "What
the hell are you yelling about?" he muttered, staring up at the neon lights
with his eyes closed and covered with wraparound Spanish sunglasses.  "Never
mind," I said. "It.s your turn to figure out the interop requirements."  I hit
the brakes and dropped the Great Pile of Paperwork at the side of the room.
No point mentioning those OIDs, I thought.  The poor bastard will see them
soon enough.

We had two bags of X.509 standards, seventy-five pages of PKIX mailing list
printouts, five sheets of high-powered constraints, a saltshaker half-full of
vendor hype, and a whole galaxy of requirements, restrictions, promises,
threats...  Also, a quart of OSI, a quart of LDAP, a case of XML, a pint of
raw X.500, and two dozen PGPs.  Not that we needed all that for the trip, but
once you get into a serious PKI RFC binge, the tendency is to push it as far
as you can.  The only thing that really worried me was the X.500.  There is
nothing in the world more helpless and irresponsible and depraved than a man
in the depths of an X.500 binge, and I knew we'd get into that rotten stuff
pretty soon.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2P1x5314919 for ietf-pkix-bks; Mon, 24 Mar 2003 17:59:05 -0800 (PST)
Received: from mx1.fujixerox.co.jp (mx1.fujixerox.co.jp [192.26.96.11]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2P1x4g14915 for <[e-mail]>; Mon, 24 Mar 2003 17:59:04 -0800 (PST)
Received: from isvw2.fujixerox.co.jp ([129.249.27.132]) by mx1.fujixerox.co.jp (8.11.6+Sun/3.7W) with ESMTP id h2P1x6F16377 for <[e-mail]>; Tue, 25 Mar 2003 10:59:06 +0900 (JST)
Received: from ns1.fujixerox.co.jp (localhost [127.0.0.1]) by isvw2.fujixerox.co.jp (8.11.1/3.7W) with ESMTP id h2P1x6U26426 for <[e-mail]>; Tue, 25 Mar 2003 10:59:06 +0900 (JST)
Received: from mail.next.ksp.fujixerox.co.jp (mail.next.ksp.fujixerox.co.jp [129.249.209.162]) by ns1.fujixerox.co.jp (8.11.6/3.7W) with SMTP id h2P1x5K27358 for <[e-mail]>; Tue, 25 Mar 2003 10:59:05 +0900 (JST)
Received: (qmail 76724 invoked by uid 0); 25 Mar 2003 01:59:04 -0000
Received: from fxmxgw.fujixerox.co.jp (HELO carry-on5) (129.249.118.106) by mail.next.ksp.fujixerox.co.jp with SMTP; 25 Mar 2003 01:59:04 -0000
To: [e-mail]
Cc: [e-mail]
Subject: Re: draft minutes
From: Ryu Inada <[e-mail]>
References: <p05100311baa52e765ff7@[128.89.88.34]>
In-Reply-To: <p05100311baa52e765ff7@[128.89.88.34]>
Message-Id: <[e-mail]>
X-Mailer: Winbiff [Version 2.42 PL2]
X-Accept-Language: ja,en
Date: Tue, 25 Mar 2003 10:59:07 +0900
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve.

> Attached are the draft minutes from last week's PKIX meeting.  Please 
> review them and send comment to me by Wednesday, 3/26.  Also, each 
> presenter should send a copy of his slides to me.  I already have 
> slides from Riccardo, Jim, Jong-Wook, Trevor, and Stefan.
I've already send a slide to you and Tim.

But, I'll send you my slide for just to make sure.
--
Ryu Inada
[e-mail]


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2OM5Ze04000 for ietf-pkix-bks; Mon, 24 Mar 2003 14:05:35 -0800 (PST)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2OM5Sg03995 for <[e-mail]>; Mon, 24 Mar 2003 14:05:34 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2OM5O5w014305 for <[e-mail]>; Mon, 24 Mar 2003 17:05:25 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100311baa52e765ff7@[128.89.88.34]>
Date: Mon, 24 Mar 2003 17:00:40 -0500
To: "IETF-PKIX" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: draft minutes
Content-Type: multipart/mixed; boundary="============_-1163578906==_============"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Folks,

Attached are the draft minutes from last week's PKIX meeting.  Please 
review them and send comment to me by Wednesday, 3/26.  Also, each 
presenter should send a copy of his slides to me.  I already have 
slides from Riccardo, Jim, Jong-Wook, Trevor, and Stefan.

As noted in the minutes, we will conduct a straw poll, starting now, 
to determine the sense of the WG re initiating a new work item, for 
the trusted archive spec.  The co-chairs approved publication of this 
document as a WG I-D, as it seems like another aspect of PKI 
infrastructure, e.g., it makes use of our time stamp authority 
standard and is an obvious component for NR support. However, given 
the limited support shown at the meeting for pursuing this work, we 
want to revisit this decision before proceeding. Please look at the 
document (draft-ietf-pkix-tap-00.txt) and indicate whether you 
believe this is an appropriate WG activity, or not.

Thanks,

Steve
--============_-1163578906==_============
Content-Id: <p05100311baa52e765ff7@[128.89.88.34].0.0>
Content-Type: application/msword; name="Minutes_3-20-03.doc"
 ; x-mac-type="5738424E"
 ; x-mac-creator="4D535744"
Content-Disposition: attachment; filename="Minutes_3-20-03.doc"
Content-Transfer-Encoding: base64

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAMgAA
AAAAAAAAEAAANAAAAAEAAAD+////AAAAADEAAAD/////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
///spcEAPyAJBAAA8BK/AAAAAAABEQABAAEABgAAsSMAAA4AamJqYqMfox8AAAAAAAAA
AAAAAAAAAAAAAAAJBBYAHjAAAMl9AADJfQAAsR0AAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAA
AGwAAAAAAPIAAAAAAAAA8gAAAPIAAAAAAAAA8gAAAAAAAADyAAAAAAAAAPIAAAAAAAAA
8gAAABQAAAAAAAAAAAAAAEoBAAAAAAAASgEAAAAAAABKAQAAAAAAAEoBAAAAAAAASgEA
AAwAAABWAQAAFAAAAEoBAAAAAAAAnwUAACIBAAB2AQAABAAAAHoBAAAAAAAAegEAAAAA
AAB6AQAAAAAAAHoBAAAAAAAAegEAAAAAAAB6AQAAAAAAAHoBAAAAAAAAXAUAAAIAAABe
BQAAAAAAAF4FAAAAAAAAXgUAAAAAAABeBQAAAAAAAF4FAAAAAAAAXgUAACwAAADBBgAA
IAIAAOEIAACAAAAAigUAABUAAAAAAAAAAAAAAAAAAAAAAAAA8gAAAAAAAAB6AQAAAAAA
AAAAAAAAAAAAAAAAAAAAAAB6AQAAAAAAAHoBAAAAAAAAegEAAAAAAAB6AQAAAAAAAIoF
AAAAAAAAUAIAAAAAAADyAAAAAAAAAPIAAAAAAAAAegEAAAAAAAAAAAAAAAAAAHoBAAAA
AAAAdgEAAAAAAABQAgAAAAAAAFACAAAAAAAAUAIAAAAAAAB6AQAA1gAAAPIAAAAAAAAA
egEAAAAAAADyAAAAAAAAAHoBAAAAAAAAXAUAAAAAAAAAAAAAAAAAAFACAAAAAAAABgEA
ACIAAAAoAQAAIgAAAPIAAAAAAAAA8gAAAAAAAADyAAAAAAAAAPIAAAAAAAAAegEAAAAA
AABcBQAAAAAAAFACAADwAgAAUAIAAAAAAAAAAAAAAAAAAEAFAAAAAAAA8gAAAAAAAADy
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAQAUAAAAAAAAAAAAAAAAAAGoBAAAMAAAAQi+lugAAAABKAQAAAAAA
AEoBAAAAAAAAUAIAAAAAAABABQAAAAAAAAAAAAAAAAAAQAUAABwAAACfBQAAAAAAAJ8F
AAAAAAAAQAUAAAAAAABhCQAAAAAAAFACAAAAAAAAYQkAAAAAAABABQAAAAAAAFACAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
BADDAA8A5QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAABQS0lYIFdHIE1lZXRpbmcgMy8yMC8wMw0NRWRpdGVkIGJ5IFN0ZXZlIEtl
bnQNDUNoYWlyczogU3RlcGhlbiBLZW50IDxrZW50QGJibi5jb20+LCBUaW0gUG9sayA8
dGltLnBvbGtAbmlzdC5nb3Y+DQ1UaGUgUEtJWCBXRyBtZXQgb25jZSBkdXJpbmcgdGhl
IDU2dGggSUVURi4gQSB0b3RhbCBvZiBhcHByb3hpbWF0ZWx5IDc2IGluZGl2aWR1YWxz
IHBhcnRpY2lwYXRlZCBpbiB0aGUgbWVldGluZy4NDQ1BZ2VuZGEgcmV2aWV3IGFuZCBk
b2N1bWVudCBzdGF0dXMgLSBUaW0gUG9sayAoTklTVCkgDVRoZXJlIGFyZSBhYm91dCAx
OSBXRyBkb2N1bWVudHMgaW4gdmFyaW91cyBzdGFnZXMgaW4gdGhlIHByb2Nlc3MsIHNv
bWUgb2Ygd2hpY2ggZmVsbCB0aHJvdWdoIHRoZSBjcmFja3MgZHVlIHRvIHByb2Nlc3Mg
Z2xpdGNoZXMuIEFsc28sIElEcyBhcmUgbm8gbG9uZ2VyIGF1dG9tYXRpY2FsbHkgdGlt
ZWQtb3V0IGFuZCBtdXN0IGJlIGV4cGxpY2l0bHkgcmVtb3ZlZCBieSBXRyBjaGFpciBh
Y3Rpb24sIHdoaWNoIGFjY291bnRzIGZvciBzb21lIG9mIHRoZSBiYWNrbG9nLiBbc2xp
ZGVzXQ0NDURQRC9EUFYgc3RhbmRhcmQgc2VsZWN0aW9uIHByb2Nlc3OWIFRpbSBQb2xr
IChOSVNUKQ0gRmlyc3QgdGhlIFdHIGRldmVsb3BlZCBSRkMgMzM3MSBhcyBhIHJlcXVp
cmVtZW50cyBiYXNpcy4gVGhlIFdHIGNoYWlycyBkZXZlbG9wZWQgYSBjb21wbGlhbmNl
IG1hdHJpeCBhbmQgZWFjaCBwcm90b2NvbCB3YXMgcmF0ZWQgcmVsYXRpdmUgdG8gdGhp
cyBtYXRyaXguIEEgc3RyYXcgcG9sbCB3YXMgY29uZHVjdGVkIGFuZCBTQ1ZQIHJlY2Vp
dmVkIGEgbWFqb3JpdHkgKG5vdCBqdXN0IGEgcGx1cmFsaXR5KSBvZiB0aGUgdm90ZXMu
IEFuIGluZGVwZW5kZW50IHJldmlldyBvZiB0aGUgY29tcGxpYW5jZSBtYXRyaXggY29u
ZmlybWVkIHRoYXQgU0NWUCB3YXMgdmVyeSBjbG9zZSB0byBjb21wbGlhbmNlLCByZXF1
aXJpbmcgbWluaW1hbCBjaGFuZ2VzL2VuaGFuY2VtZW50cy4gW3NsaWRlc10NDVNDVlAg
RGlzY3Vzc2lvbiCWIFRyZXZvciBGcmVlbWVuIChNaWNyb3NvZnQpDVdvcmtpbmcgdG8g
bWVldCBmZXcgcmVtYWluaW5nIG1hbmRhdG9yeSByZXF1aXJlbWVudHMgZm9yIDMzNzEs
IGFuZCB0byByZWFjaCBjb25zZW5zdXMgb24gb3B0aW9uYWwgZmVhdHVyZXMuIEFkZGlu
ZyBNQUMgKGluIGFkZGl0aW9uIHRvIHNpZ25hdHVyZSkgc3VwcG9ydCBmb3IgcmVxdWVz
dCBhdXRoZW50aWNhdGlvbi4gV2lsbCBkZWZpbmUgk3N0YW5kYXJklCBwb2xpY2llcyBh
cyBkZWZhdWx0LiBUYXJnZXQgZW5kIG9mIE1heSBmb3IgcHVibGljYXRpb24gb2YgbmV4
dCBkcmFmdC4gSW50ZW50IGlzIHRvIG1vdmUgdG8gV0cgbGFzdCBjYWxsIGJlZm9yZSBW
aWVubmEgbWVldGluZy4gW3NsaWRlc10NDVByb3h5IENlcnRpZmljYXRlcyBWb24gV2Vs
Y2ggKEFyZ29ubmUgTGFicykNCURvY3VtZW50IGlzIGFsc28gYmVpbmcgd29ya2VkIG9u
IGluIEdsb2JhbCBHcmlkIEZvcnVtLiBYLjUwOSBFRSBjZXJ0aWZpY2F0ZXMgdGhhdCBh
cmUgaXNzdWVkIGJ5IG90aGVyIEVFcywgbm90IENBcy4gQ29udGFpbiBjcml0aWNhbCBl
eHRlbnNpb24gbWFya2luZyBpdCBhcyBhIHByb3h5IGNlcnRpZmljYXRlLiBGYWNpbGl0
eSB0byByZXByZXNlbnQgZGVsZWdhdGlvbiBvZiBmdWxsIG9yIGxpbWl0ZWQgcmlnaHRz
IChjYXBhYmlsaXR5IG1vZGVsKSB0byB0aGUgcHJveHksIGJ5IHRoZSBFRS4gTWFqb3Ig
Y2hhbmdlIGZyb20gbGFzdCBtZWV0aW5nIGlzIHRvIGRlc2NyaWJlIGFkZGl0aW9ucyB0
byBwYXRoIHZhbGlkYXRpb24gdG8gYWNjb21tb2RhdGUgcHJveHkgY2VydGlmaWNhdGVz
LCBpLmUuLCBoYW5kIG9mZiBwcm94eSBjZXJ0aWZpY2F0ZSB0byB0aGUgZXh0ZW5kZWQg
YWRkaXRpb25hbCB2YWxpZGF0aW9uIGNvZGUuIFRoaXMgaXMgY29uc2lzdGVudCB3aXRo
IHRoZSB3YXkgdGhlc2UgY2VydGlmaWNhdGVzIGFyZSBjdXJyZW50bHkgcHJvY2Vzc2Vk
IGJ5IG1vZGlmaWVkIHNvZnR3YXJlIGluIHRoZSBHbG9iYWwgR3JpZCBjb250ZXh0LiBU
aGlzIElEIGlzIHJlYWR5IGZvciBXRyBsYXN0IGNhbGwuIFtzbGlkZXNdDQ1TaWduYXR1
cmUgQWxnb3JpdGhtcyAmIEtleSBVc2FnZSCWIEppbSBTY2hhYWQgKFNvYXJpbmcgSGF3
ayBDb25zdWx0aW5nKQ0JT2Z0ZW4gcHVibGljIGtleSBkYXRhIChmb3IgdXNlIHdpdGgg
c2lnbmF0dXJlcykgY291bGQgaW4gcHJpbmNpcGxlLCBiZSB1c2VkIHdpdGggbW9yZSB0
aGFuIG9uZSBhbGdvcml0aG0sIGUuZy4sIFJTQSBQU1MvT0FFUCBvciBESC9EU0EuIFRv
ZGF5IHdlIGJpbmQgc2lnbmF0dXJlIHZhbGlkYXRpb24ga2V5cyB0byBhIHBhaXIgb2Yg
YWxnb3JpdGhtcywgdmlhIGEgc2luZ2xlIE9JRC4gT25lIHF1ZXN0aW9uIGlzIGhvdyB0
byBleHByZXNzIHRoYXQgb25lIGtleSBjb3VsZCBiZSB1c2VkIHdpdGggbXVsdGlwbGUg
YWxnb3JpdGhtcywgZS5nLiwgYSBtaXggb2YgaGFzaCBhbGdvcml0aG1zIG9yIGV2ZW4g
ZGlmZmVyZW50IHB1YmxpYyBrZXkgYWxnb3JpdGhtcywgdG8gYXZvaWQgcmVkdW5kYW50
IGNlcnRpZmljYXRlIGlzc3VhbmNlLCBidXQgc3RpbGwgcmV0YWluIGFiaWxpdHkgdG8g
ZXhwcmVzcyBjdXJyZW50IG5vdGlvbiBvZiByZXN0cmljdGl2ZSB1c2UuIEFuYWxvZ291
cyBpc3N1ZXMgYXJpc2UgaW4gdmFsaWRhdGlvbiBvZiBzaWduYXR1cmVzLCBpLmUuLCBw
cm9jZXNzaW5nIHNpZ25hdHVyZSBmaWVsZHMgYW5kIG1hdGNoaW5nIGFnYWluc3QgZGF0
YSBmcm9tIHRoZSBjZXJ0aWZpY2F0ZSB1c2VkIHRvIHZhbGlkYXRlIGEgc2lnbmF0dXJl
LiBXZSBjb3VsZCBkbyBub3RoaW5nLCBvciB3ZSBjb3VsZCBpbmNsdWRlIGFkZGl0aW9u
YWwgZGF0YSB0byBmYWNpbGl0YXRlIG1vcmUgZ2VuZXJhbCB1c2Ugb2YgdGhlIGtleSBi
aXRzLCBlLmcuLCBieSBjcmVhdGluZyBhbiBleHRlbnNpb24uIFRoZXJlIHdhcyBkaXNh
Z3JlZW1lbnQgb3ZlciB3aGV0aGVyIHRoZXJlIGlzIGEgc2VjdXJpdHkgY29uY2VybiB0
aGF0IGlzIGFkZHJlc3NlZCBieSB0aGUgcHJvcG9zZWQgY2hhbmdlLiBbc2xpZGVzXQsN
VHJ1c3RlZCBBcmNoaXZlIFByb3RvY29sIChUQVApliBDYXJsIFdhbGxhY2UgKEN5Z25h
Y29tKQ0JTmV3IHByb3RvY29sIGRlZmluaW5nIGEgc2VydmljZSBmb3IgdHJ1c3RlZCBh
cmNoaXZlIG9mIGRhdGEsIGluIHN1cHBvcnQgb2YgTlIuIFNpbXBsZSB0cmFuc2FjdGlv
biBwcm90b2NvbCBmb3IgdGltZWx5IHJlZnJlc2ggb2YgdGltZXN0YW1wcywgY2VydGlm
aWNhdGVzLCBDUkxzLCBldGMuIFJlcXVlc3RzIHN1cHBvcnQgc3VibWlzc2lvbiBvZiBk
YXRhIGZvciBhcmNoaXZlLCBhbmQgYSBsaW1pdGVkIHNlYXJjaC9yZXRyaWV2YWwgY2Fw
YWJpbGl0eS4gRXh0ZW5zaW9ucyB0byBUQVAgYWxsb3cgYSBzZXJ2ZXIgdG8gY29uc3Ry
YWluIHRoZSB0eXBlcyBvZiBkYXRhIGFjY2VwdGVkLCB0byB2ZXJpZnkgVEFQIHRva2Vu
cywgc2VudCBieSBhIGNsaWVudCwgZXRjLiBSRkMgWFhYWCB0aW1lc3RhbXAgdG9rZW5z
IGFyZSBlbXBsb3llZC4gT3B0aW9uYWwgc2VydmljZXMgaW5jbHVkZSB0cnVzdCBhbmNo
b3IgcmV0cmlldmFsLCByZWxhdGl2ZSB0byBhIHByaW9yIHBvaW50IGluIHRpbWUuIENN
UyBmb3JtYXQgdXNlZCBmb3IgVFNQIG1lc3NhZ2VzLiBBIHN0cmF3IHBvbGwgb2YgdGhl
IG1lZXRpbmcgYXR0ZW5kZWVzIGRpZCBub3Qgc2hvdyBzaWduaWZpY2FudCBzdXBwb3J0
IGZvciB0aGlzIHRvIGJlY29tZSBhIG5ldyBXRyB3b3JrIGl0ZW0uIFRoZSBXRyBjaGFp
cnMgd2lsbCByYWlzZSB0aGUgcXVlc3Rpb24gb24gdGhlIGxpc3QsIGFuZCBhc2sgd2hh
dCBpbnRlcmVzdCBleGlzdHMgcmUgaW1wbGVtZW50YXRpb24gc3VwcG9ydCwgaWYgdGhp
cyB3ZXJlIHRvIGJlY29tZSBhIFdHIGl0ZW0uIFtzbGlkZXNdDQ1RdWFsaWZpZWQgQ2Vy
dGlmaWNhdGVzIFByb2ZpbGUgLSBTdGVmYW4gU2FudGVzc29uIChSZXRyb1NwZWt0KQ0J
VGhlIGF1dGhvciBpcyByZWFkeSB0byB1cGRhdGUgdGhlIGRvY3VtZW50IGFuZCBpcyBh
c2tpbmcgd2hldGhlciB0aGUgdXBkYXRlIHNob3VsZCBhZGRyZXNzIHRoZSBzY29wZSBv
ZiB0aGUgZG9jdW1lbnQsIGkuZS4sIHNob3VsZCB0aGlzIGJlIHZpZXdlZCBhcyBhIChu
b24tZXhjbHVzaXZlKSBwcm9maWxlIGZvciB1c2VyIGlkZW50aXR5IGNlcnRpZmljYXRl
cyAoZm9yIHVzZSB3aXRoIGRpZ2l0YWwgc2lnbmF0dXJlKSBtb3JlIGdlbmVyYWxseSwg
dnMuIG9ubHkgZm9yIHF1YWxpZmllZCBjZXJ0aWZpY2F0ZXMuIEFuZCBpZiBzbywgd291
bGQgdGhhdCByZXN1bHQgaW4gY2hhbmdlcyB0byB0aGUgc3Vic3RhbmNlIG9mIHRoZSBk
b2N1bWVudCwgZS5nLiwgdGhlIEtleVVzYWdlIHRleHQgbWlnaHQgYmUgY2hhbmdlZCB0
byBiZSBsZXNzIHJlc3RyaWN0aXZlLiBBIG1pbm9yIGlzc3VlIGlzIHRoZSBmYWN0IHRo
YXQgUG9zdGFsQWRkcmVzcyBpcyBjYWxsZWQgZm9yIGhlcmUsIGJ1dCBSRkMgMzI4MCBk
b2VzIG5vdCBtYW5kYXRlIHN1cHBvcnQgb2YgdGhhdCBhdHRyaWJ1dGUuIFdlIG5lZWQg
dG8gYmUgc2Vuc2l0aXZlIHRvIGNoYW5nZXMgdGhhdCB3ZSBtYWtlIGhlcmUsIHNpbmNl
IEVUU0kgcmVsaWVzIG9uIGl0IGluIHRoZWlyIHN0YW5kYXJkcy4gW3NsaWRlc10NDUxp
YWlzb24gUmVwb3J0OiBMREFQL1guNTAwIGFsaWdubWVudCCWIFNraXAgU2xvbmUgKExv
Y2toZWVkLU1hcnRpbikNCUlUVSB3b3JrLCB3aWxsIHNob3cgdXAgaW4gNXRoIGVkaXRp
b24gb2YgWC41MDAuIE1ham9yIHRvcGljcyBvZiBpbnRlcmVzdCBmb3IgUEtJWDogc2Vt
aS1jb2xvbiBiaW5hcnkgbWF0Y2hpbmcsIHN0cmluZyBtYXRjaGluZywgZW5oYW5jZWQg
bWF0Y2hpbmcsIGRvbWFpbiBjb21wb25lbnQgbmFtZXMsIE5SIGJpdC4gUHJvcG9zYWwg
aXMgdG8gcmVuYW1lIHRoZSBOUiBiaXQgYXMgk2NvbnRlbnQgY29tbWl0bWVudJQgdG8g
ZGVmdXNlIHRoZSBsb25nIHJ1bm5pbmcgZGViYXRlIGFib3V0IHRoZSBuYW1lIGFuZCBz
ZW1hbnRpY3MuW3NsaWRlc10NDVN1YmplY3QgSWRlbnRpZmljYXRpb24gTWV0aG9kIC0g
UGFyayBKb25nLVdvb2sgliAoS0lTQSkNCUdvYWwgaXMgdG8gcHJvdmlkZSBhIHdheSB0
byByZXByZXNlbnQgYSBwZXJzb25hbCBJRCB2YWx1ZSAoZS5nLiwgbmF0aW9uYWwgSUQg
bnVtYmVyKSBpbiBhIGNlcnRpZmljYXRlIChlLmcuLCBpbiBhIHN1YmplY3QgYWx0bmFt
ZSkgaW4gYSB3YXkgdGhhdCBkb2VzIG5vdCBkaXNjbG9zZSBpdHMgdmFsdWUsIGZvciBw
cml2YWN5IHJlYXNvbnMuIFRoZSBwcm9wb3NhbCBhbHNvIGluY2x1ZGVzIGEgcHJvdG9j
b2wgZm9yIHRyYW5zZmVycmluZyB0aGlzIGRhdGEgdG8gdGhlIENBLiBUaGVyZSB3aWxs
IGJlIHNvbWUgdGVybWlub2xvZ3kgY2hhbmdlcywgYmFzZWQgb24gV0cgZmVlZGJhY2su
IFRoZXJlIGlzIG92ZXJsYXAgaGVyZSB3aXRoIG91ciBwZXJtYW5lbnQgaWRlbnRpZmll
ciB3b3JrLCBhcyB0aGUgbmF0aW9uYWwgSUQgbnVtYmVyIHRoYXQgbW90aXZhdGVzIHRo
aXMgd29yayBpcyBhIFBJLCBhbmQgdGhpcyBvdmVybGFwIG5lZWRzIHRvIGJlIGJldHRl
ciBkZXNjcmliZWQgaW4gdGhlIElELiBBbHNvLCBtb3JlIGV4YW1wbGUgd2lsbCBiZSBw
cm92aWRlZCBpbiB0aGUgSUQuIFRoZSBhdXRob3IgcmVxdWVzdHMgbW9yZSBmZWVkYmFj
ayBmcm9tIHRoZSBXRy4gW3NsaWRlc10NDUxpYWlzb24gUmVwb3J0OiBFRVNTSSCWIFJp
Y2NhcmRvIEdlbmdoaW5pIChTdHVkaW8gTm90YXJpbGUgR2VuZ2hpbmkpDQlQcmVzZW50
YXRpb24gb24gRXVyb3BlYW4gRWxlY3Ryb25pYyBTaWduYXR1cmUgU3RhbmRhcmRpemF0
aW9uIEluaXRpYXRpdmUuIEluY2x1ZGVzIGJyaWVmIHJldmlldyBvZiByZWxldmFudCBF
VSBkaWdpdGFsIHNpZ25hdHVyZSBzdGFuZGFyZHMsIGFuZCBkaXNjdXNzaW9uIG9mIHZh
cmlvdXMgRVUtYmFzZWQgY29tbWl0dGVlcyBhbmQgd29ya2luZyBncm91cHMgaW4gdGhp
cyBhcmVhLiBTdWdnZXN0aW9uIHRoYXQgRUVTU0kgYW5kIFBLSVggV0cgYXR0ZW5kZWVz
IG1pZ2h0IGdldCB0b2dldGhlciBhZnRlciBWaWVubmEgbWVldGluZy4gW3NsaWRlc10N
DUxpYWlzb24gUmVwb3J0OiBKTlNBIENoYWxsZW5nZSBQS0kgMjAwMiBTdGF0dXMgUmVw
b3J0IC0gUnl1IEluYWRhIChKTlNBKQ0JQSBzdGF0dXMgcmVwb3J0IG9uIHRoZSBpbnRl
cm9wZXJhYmlsaXR5IHRlc3RpbmcgYWN0aXZpdGllcyBpbiBKYXBhbi4gVGhlIHJlc3Vs
dHMgb2YgdGVzdGluZyBhcmUgb2YgdXNlZnVsIGZvciB1bmNvdmVyaW5nIHNwZWNpZmlj
YXRpb24gcHJvYmxlbXMgd2l0aCBQS0lYIHN0YW5kYXJkcyBhbmQgb2YgcHJvZHVjdHMg
dnMuIHRoZXNlIHN0YW5kYXJkcy4gVGVzdCBlbnZpcm9ubWVudCBpbmNsdWRlcyBDQXMg
YW5kIFZBcyBjYXBhYmxlIG9mIGdlbmVyYXRpbmcgZGF0YSBmb3IgdGVzdCBjYXNlcywg
c29tZSBvZiB3aGljaCBpbnRlbnRpb25hbGx5IGRvIG5vdCBjb25mb3JtIHRvIFBLSVgg
c3RhbmRhcmRzLiBUaGV5IHByb3ZpZGVkIGEgc2hvcnQgZGVtbyBvZiB0aGVpciB0ZXN0
IHRlY2hub2xvZ3kuIFtzbGlkZXNdDQ1MREFQIFBLSSBJc3N1ZXMgliBEYXZpZCBDaGFk
d2ljayAoVW5pdmVyc2l0eSBvZiBTYWxmb3JkKSANCVByb2JsZW0gaXMgdGhhdCB3ZSBj
YW5ub3Qgc2VhcmNoIGZvciBjZXJ0aWZpY2F0ZXMgYW5kIENSTHMgaW4gTERBUCBiYXNl
ZCBvbiBhbnl0aGluZyBhdHRyaWJ1dGUgb3RoZXIgdGhhbiBhIFN1YmplY3QgRE4sIGdp
dmVuIGN1cnJlbnQgTERBUCBzZWFyY2ggbGltaXRhdGlvbnMuIEJ1dCB3ZSB3b3VsZCBs
aWtlIHRvIGxvY2F0ZSB0aGVzZSBkYXRhIGluIGFuIExEQVAgc2VydmVyIGJhc2VkIG9u
IG90aGVyIGF0dHJpYnV0ZXMuIFRoZSBwcmV2aW91c2x5IGRlc2NyaWJlZCBjb21wb25l
bnQgbWF0Y2hpbmcgc29sdXRpb24gZG9lcyBub3QgaGF2ZSBMREFQIHZlbmRvciBzdXBw
b3J0IGFuZCByZXF1aXJlcyBjaGFuZ2VzIHRvIGNsaWVudHMuIEFub3RoZXIgYXBwcm9h
Y2ggaXMgYXR0cmlidXRlIGV4dHJhY3Rpb24sIGdlbmVyYXRpbmcgbmV3IGF0dHJpYnV0
ZXMgZm9yIGRpcmVjdG9yeSBlbnRyaWVzIGJ5IGV4dHJhY3RpbmcgdGhlbSBmcm9tIGNl
cnRpZmljYXRlcyBhbmQgQ1JMcy4gVGhpcyBjYW4gYmUgZWZmZWN0ZWQgYnkgaGF2aW5n
IGEgZnJvbnQgZW5kIHRoYXQgZG9lcyB0aGUgcHJvY2Vzc2luZyBmb3IgcG9wdWxhdGlu
ZyBkaXJlY3RvcnkgZW50cmllcy4gQnV0IHRoaXMgc3RyYXRlZ3kgc2lnbmlmaWNhbnRs
eSBpbmNyZWFzZSBzdG9yYWdlIHNwYWNlIGZvciBlYWNoIGVudHJ5IHRoYXQgaG9sZHMg
Y2VydGlmaWNhdGVzL0NSTHMsIGFuZCB0aGUgZnJvbnQgZW5kIG11c3QgYmUgdXBkYXRl
ZCB3aGVuZXZlciB0aGUgc2V0IG9mIGF0dHJpYnV0ZXMgdG8gYmUgbWF0Y2hlZCBhZ2Fp
bnN0IGNoYW5nZXMuIFRoZSBTZWN1cml0eSBBRCBoYXMgZW1waGFzaXplZCB0aGUgbmVl
ZCB0byBoYXZlIG9ubHkgb25lIHNvbHV0aW9uLiBBIHF1aWNrIHN0cmF3IHBvbGwgaW5k
aWNhdGVzIHRoYXQgdGhlIGF0dGVuZGVlcyBmYXZvciBjb21wb25lbnQgbWF0Y2hpbmcs
IGJ1dCB0aGUgbnVtYmVyIG9mIGF0dGVuZGVlcyB2b3Rpbmcgd2FzIHZlcnkgc21hbGwu
IFtzbGlkZXNdDQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAHcYAAB5
GAAAWRwAAHIcAACxIwAAAP0A+AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlCKgFwaAAAAAADSCoBAAUABgAAGAYA
ABkGAAAuBgAALwYAAHEGAAByBgAA4gYAAOMGAADkBgAAGQcAAC4IAAAvCAAAMAgAAGQI
AADuCQAA7wkAABwKAABxCwAAcgsAAJ4LAAAbDgAAHA4AAGQOAADsEQAAJBIAAEEVAABC
FQAAgRUAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA
AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA
AAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAA
AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A
AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9
AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA
/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA
AP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFDwARhNACYITQAgABDwAAHAAGAAAY
BgAAGQYAAC4GAAAvBgAAcQYAAHIGAADiBgAA4wYAAOQGAAAZBwAALggAAC8IAAAwCAAA
ZAgAAO4JAADvCQAAHAoAAHELAAByCwAAngsAABsOAAAcDgAAZA4AAOwRAAAkEgAAQRUA
AEIVAACBFQAAFhgAABcYAABbGAAAkBkAAJEZAADJGQAALRwAAC4cAABzHAAArR0AAK4d
AAD3HQAAjh8AAI8fAADJHwAAsSMAAP39/f39/f39/f39/f39/f39/f39/f39/f39/f39
/f39/f39/f39/f39/f39AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwIPAAAsgRUA
ABYYAAAXGAAAWxgAAJAZAACRGQAAyRkAAC0cAAAuHAAAcxwAAK0dAACuHQAA9x0AAI4f
AACPHwAAyR8AALEjAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA
AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA
AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA
AAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA
AAAAAAD9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ8AABAc
AB+w0C8gsO49IbBnASKwZwEjkKAFJJCgBSWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ABIAEQAKAAEAaQAPAAIAAwAAAAMAKAAAQPH/AgAoAAAABgBOAG8AcgBtAGEAbAAAAAIA
AAAIAENKGABtSAkEAAAAAAAAAAAAAAAAAAAAAAAAPABBQPL/oQA8AAAAFgBEAGUAZgBh
AHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAAAAAAAAAAADAA
WkABAPIAMAAAAAoAUABsAGEAaQBuACAAVABlAHgAdAAAAAIADwAIAE9KBABRSgQAKABV
QKIAAQEoAAAACQBIAHkAcABlAHIAbABpAG4AawAAAAYAPioBQioCAAAAALEdAAAEAAAw
AAAAAP////8DAAAABCH//wEAWp2ZAAAh//8CAFqdmQAEIP//AwBanZkAAAAAAJQJAACe
FQAAsR0AAAAAWAIAAAEAjwAAAAIAAAAAAAAGAACxIwAAFAAAAAAGAACBFQAAsSMAABUA
AAAXAAAAAAYAALEjAAAWAAAAsR0AAAAAAACQBQAAlwUAAAUGAAAIBgAAQwgAAEkIAAAa
DAAAIgwAAGoPAABzDwAAdQ8AAH8PAAD6EAAAAhEAAFARAABdEQAAthMAAL8TAABEFAAA
SxQAAEYWAABOFgAATxYAAFcWAABgFgAAaBYAAGkWAABxFgAA5hcAAOkXAADjGAAA5hgA
AL8ZAADGGQAAsx0AAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwD//xQAAAAKAFMAdABlAHYAZQAg
AEsAZQBuAHQAGQBIAGEAcgBkACAARABpAHMAawA6AE0AaQBuAHUAdABlAHMAIAAzAC0A
MgAwAC0AMAAzAAoAUwB0AGUAdgBlACAASwBlAG4AdAAZAEgAYQByAGQAIABEAGkAcwBr
ADoATQBpAG4AdQB0AGUAcwAgADMALQAyADAALQAwADMACgBTAHQAZQB2AGUAIABLAGUA
bgB0ABkASABhAHIAZAAgAEQAaQBzAGsAOgBNAGkAbgB1AHQAZQBzACAAMwAtADIAMAAt
ADAAMwAKAFMAdABlAHYAZQAgAEsAZQBuAHQAGQBIAGEAcgBkACAARABpAHMAawA6AE0A
aQBuAHUAdABlAHMAIAAzAC0AMgAwAC0AMAAzAAoAUwB0AGUAdgBlACAASwBlAG4AdAAZ
AEgAYQByAGQAIABEAGkAcwBrADoATQBpAG4AdQB0AGUAcwAgADMALQAyADAALQAwADMA
CgBTAHQAZQB2AGUAIABLAGUAbgB0ABkASABhAHIAZAAgAEQAaQBzAGsAOgBNAGkAbgB1
AHQAZQBzACAAMwAtADIAMAAtADAAMwAKAFMAdABlAHYAZQAgAEsAZQBuAHQAGQBIAGEA
cgBkACAARABpAHMAawA6AE0AaQBuAHUAdABlAHMAIAAzAC0AMgAwAC0AMAAzAAoAUwB0
AGUAdgBlACAASwBlAG4AdAAZAEgAYQByAGQAIABEAGkAcwBrADoATQBpAG4AdQB0AGUA
cwAgADMALQAyADAALQAwADMACgBTAHQAZQB2AGUAIABLAGUAbgB0ABkASABhAHIAZAAg
AEQAaQBzAGsAOgBNAGkAbgB1AHQAZQBzACAAMwAtADIAMAAtADAAMwAKAFMAdABlAHYA
ZQAgAEsAZQBuAHQAHABNAGEAYwBpAG4AdABvAHMAaAAgAEgARAA6AE0AaQBuAHUAdABl
AHMAIAAzAC0AMgAwAC0AMAAzAAAAAACtFwAAjxkAALMdAAAAAAAAAQAAAAEAAAD/QAGA
AQE4DwAAOA8AAJwi9RQbAgEAOA8AAAAAAAA4DwAAAAAAACgAUQCrAuoCAhAAAAAAAAAA
sR0AAEAAAAwAQAAABQAAAEcGkAEAAAICBgMFBAUCAwQAAAADAAAAAAAAAAAAAAAAAQAA
AAAAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUGkAECAAIABQAAAAAA
AAAAAAAAEAAAAAAAAAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMGkAEAAAILBgQC
AgICAgQAAAADAAAAAAAAAAAAAAAAAQAAAAAAAABBAHIAaQBhAGwAAAAzBpABAAACAAUA
AAAAAAAAAAAAAwAAAAAAAAAAAAAAAAEAAAAAAAAAVABpAG0AZQBzAAAANwaQAQAAAgAF
AAAAAAAAAAAAAAMAAAAAAAAAAAAAAAABAAAAAAAAAEMAbwB1AHIAaQBlAHIAAAAiAAQA
cQiMGADw0AIAAGgBAAAAAPWic4Y3xHMm9aNrZjsAsAAAAAEDAAAiEQAAAwAIAAAABACD
ECQAAAAAAAAAAAAAAAMAAQAAAAEAAAAAAAAAJAMA8BAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApQbAB7QAtACAAB4w
AAARABkAZAAAABkAAAAKFQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAABSAgAAAAAAAABAAPAQAN8D
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//8SAAAAAAAAABcAUABLAEkAWAAg
AFcARwAgAE0AZQBlAHQAaQBuAGcAIAA3AC8AMQA3AC8AMAAyAAAAAAAAAAoAUwB0AGUA
dgBlACAASwBlAG4AdAAKAFMAdABlAHYAZQAgAEsAZQBuAHQAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAD+/wAAAwoBAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlP
aBCrkQgAKyez2TAAAACAAQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAAuAAAAAQAAADE
AAAABQAAANgAAAAHAAAA5AAAAAgAAAD0AAAACQAAAAgBAAASAAAAFAEAAAoAAAAwAQAA
CwAAADwBAAAMAAAASAEAAA0AAABUAQAADgAAAGABAAAPAAAAaAEAABAAAABwAQAAEwAA
AHgBAAACAAAAECcAAB4AAAAYAAAAUEtJWCBXRyBNZWV0aW5nIDcvMTcvMDIAHgAAAAEA
AAAAS0lYHgAAAAsAAABTdGV2ZSBLZW50AHQeAAAAAQAAAAB0ZXYeAAAABwAAAE5vcm1h
bABlHgAAAAsAAABTdGV2ZSBLZW50AHQeAAAAAwAAADU5AHYeAAAAEwAAAE1pY3Jvc29m
dCBXb3JkIDkuMAA3QAAAAAAgQJYYAAAAQAAAAABel8/WkMIBQAAAAAC+FyoB78IBQAAA
AABSGwRQ8sIBAwAAAAMAAAADAAAAAQMAAAMAAAAiEQAAAwAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAMKAQAAAAAAAAAAAAAA
AAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAAEAEAAAwAAAABAAAAaAAAAA8AAABw
AAAABQAAAIwAAAAGAAAAlAAAABEAAACcAAAAFwAAAKQAAAALAAAArAAAABAAAAC0AAAA
EwAAALwAAAAWAAAAxAAAAA0AAADMAAAADAAAAPAAAAACAAAAECcAAB4AAAARAAAAQkJO
IFRlY2hub2xvZ2llcwBpAG4DAAAAJAAAAAMAAAAIAAAAAwAAAAoVAAADAAAAlAwJAAsA
AAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAYAAAAUEtJWCBXRyBN
ZWV0aW5nIDcvMTcvMDIADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEA
AAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAO
AAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAAP7///8aAAAA
GwAAABwAAAAdAAAAHgAAAB8AAAAgAAAA/v///yIAAAAjAAAAJAAAACUAAAAmAAAAJwAA
ACgAAAD+////KgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAAP7////9////MwAAAP7/
///+/////v//////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAA
AAAAAAAAAIWdIybywgE1AAAAgAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAf////8FAAAA
/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABkAAAAAEAAAAAAA
AFcAbwByAGQARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAaAAIBAQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAB4wAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8A
cgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgECAAAABAAA
AP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhAAAAABAAAAAA
AAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABp
AG8AbgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAACkAAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA////////
////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//////
/////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAEAAAD+////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////
////////AQD+/wIAAQD/////BgkCAAAAAADAAAAAAAAARhgAAABNaWNyb3NvZnQgV29y
ZCBEb2N1bWVudAD+////TkI2VxAAAABXb3JkLkRvY3VtZW50LjgAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAA=
--============_-1163578906==_============--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2NJFUw25553 for ietf-pkix-bks; Sun, 23 Mar 2003 11:15:30 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2NJFSg25546 for <[e-mail]>; Sun, 23 Mar 2003 11:15:28 -0800 (PST)
Subject: Re: The case against directories
To: David Chadwick <[e-mail]>
Cc: Anders Rundgren <[e-mail]>, [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sun, 23 Mar 2003 12:16:52 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 03/23/2003 02:16:34 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

ref:
http://www.garlic.com/~lynn/aadsm13.htm#38 The case against directories

we've had some long term experience in this. the kerberos reference ....
was from one of the audit visits that my wife and I did on project athena
.... and sitting thru an extended detailed description of the "new"
cross-domain kerberos protocol .... and various subsequent discussons.

however, going back even further ... almost 25 years ago ... a couple of us
were sitting around friday night trying to think up ways of getting upper
management interesting in online use. one of the compelling business uses
was an online telephone directory (for some 450,000 or so employees &
increasing). we had some simple objectives .... 1) online lookup elapsed
time faster than reaching for a local site paper directory and looking it
up, 2) take 2 person weeks or less to implement, 3) take less than a half
person day per month to support, 4) in addition to existing informaiton
like name, telephone number, internal mail-stop ... allow it to grow into
things like email address.

so we started contacting various plant sites .... asking for process that
would regularly transmit the machine readable copy that they used for
producing the site's paper directory. It turned out what started to consume
the most time were discussions with the site security officers about
security classification of an online directory .... that was only available
inside the corporation ... and only contained name and telephone number ...
and was an exact duplicate of the paper directory. Paper directories were
classified internal use only .... the security officers wanted to classify
the equivalent information (even if it was only name and telephone number)
when made available online at a significantly higher security level (even
if it was only accesable from inside the corporation).

much longer (including technical) description of the online telephone
directory effort:
http://www.garlic.com/~lynn/2003b.html#45 hyperblock drift, was filesystem
structure (long warning)

note that the internal network at the time was larger than the
internet/arpanet and continued larger up thru approximately 1985.
http://www.garlic.com/~lynn/internet.htm#4 Internet (TM) and USPTO
http://www.garlic.com/~lynn/internet.htm#0 Internet and/or ARPANET
http://www.garlic.com/~lynn/internet.htm#22 internal network's 1000th node
http://www.garlic.com/~lynn/2003d.html#59 unix

totally random trivia was in the mid-80s i was told that the internal
network had over half of all link encrypters in the world.
http://www.garlic.com/~lynn/2002d.html#9 Security Proportional to Risk
(was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk
(was: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002j.html#52 "Slower is more secure"
http://www.garlic.com/~lynn/2003e.html#36 Use of SSL as a VPN

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm

[e-mail] on 3/22/2003 7:26 am wrote:

Lynn

well said. Access controls and privacy issues apply regardless of
technologies.

David



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2NFPRn14387 for ietf-pkix-bks; Sun, 23 Mar 2003 07:25:27 -0800 (PST)
Received: from bruno.gric.com (bruno.gric.com [216.231.202.145]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2NFPOg14379; Sun, 23 Mar 2003 07:25:24 -0800 (PST)
Received: from salford.ac.uk (dialup-166.90.33.241.Dial1.SanFrancisco1.Level3.net [166.90.33.241]) by bruno.gric.com (8.12.7/8.12.7) with ESMTP id h2NFNrAW024078; Sun, 23 Mar 2003 07:23:54 -0800 (PST)
Message-ID: <[e-mail]>
Date: Sat, 22 Mar 2003 14:26:46 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Anders Rundgren <[e-mail]>, [e-mail], [e-mail], [e-mail]
Subject: Re: The case against directories
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------F78DBE564CCAB9A90B0CB855"
Sender: [e-mail]
Precedence: 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.
--------------F78DBE564CCAB9A90B0CB855
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Lynn

well said. Access controls and privacy issues apply regardless of
technologies.

David

[e-mail] wrote:
> 
> >2. Internal information (including employment) is generally not public
> 
> in fact, for earlier public PKI certificate-based information, the eventual
> result (because of difficult privacy issues, both individual and
> institutional, taking some liberty to translate privacy as both a personal
> concept as well as an institutional concept) was the lowest common
> denominator, a certificate that only contained a institutional number (ex:
> various financial certificates) and nothing else, which then were only used
> in context of rely-party-only certificates.
> 
> the cross domain issues have not been technical (they effectively have all
> been a form of privacy, either individual or institutional) .... they were
> not technical some 15 years ago with cross-domain kerberos, there were not
> technifcal some 6-8 years ago with cross-domain PKI certificates, and they
> probably won't be technical this time around with directories. another
> simple example of the reduction of information has been the dig/nslookup
> responses from  the biggest internet "public" directories, the DNS
> root-servers. Over the last five years, nearly all "privacy" information
> has disappeared from public responses (like name, address, telephone
> number, and email  of administrative and technical contacts).
> 
> DNS directories are an example of an online internet information source for
> a couple decades and the issue isn't that the praadigm doesn't work, but
> there are significant privacy issues (personal & institutional).
> 
> And as one of my common references .... certificates are just stale, static
> representation of a database/directory entry that exists somewhere ... and
> the personal & instititional privacy issues aer common, regardless of the
> representational format.
> 
> --
> Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm
> 
> 
>                      "Anders Rundgren"
>                     <anders.rundgren@t     To:      <[e-mail]>
>                              elia.com>     cc:
>                               Sent by:     Subject:      The case against
>                     owner-ietf-pkix@ma        directories
>                             il.imc.org
> 
> 
>                       03/21/2003 01:21
>                                     AM
> 
> 
> 
> I would like to add a few things to what Phillip Hallam-Baker of
> VeriSign wrote about directories as an obstacle to PKI deployment.
> 
> Many  PKI experts are involved in huge public-sector-driven projects,
> that are based on establishing directory interoperability between
> organizations.  At first sight this looks like a great idea but digging
> a bit further, you soon note that this is not a universal solution but
> rather a dead end.
> 
> Directory problem issues
> 1. Technical.  Unifying schemas + firewall issues
> 2. Internal information  (including employment) is generally not public
> 3. The level of openness depends on who is asking
> 4. Directories represent just one way to organize data
> 
> But, there is no reason to despair, as there are work-arounds that
> properly addresses all these issues:
> 
> Using authentication systems like OASIS' SAML, organizations can
> (through their employees), authenticate to each others' intranets and
> through this get access to exactly the information they should have
> and in a format that make sense.  The latter may be a directory tree,
> a PDF-file, a database listing, an HTML form, etc.
> 
> Unlike directory systems, SAML allows secure access to any kind
> of active or passive information source, including purchasing and
> work-flow systems.
> 
> All using the truly universal Internet browser interface.
> 
> For machine-to-machine (=automated) access to external information,
> specialized Web Services seems to be a much more extensible route
> than directories, as the former introduces no restrictions on data.
> 
> Anders Rundgren
> Independent consultant PKI and secure e-business

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------F78DBE564CCAB9A90B0CB855
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------F78DBE564CCAB9A90B0CB855--





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2MGeoF27313 for ietf-pkix-bks; Sat, 22 Mar 2003 08:40:50 -0800 (PST)
Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2MGelg27308 for <[e-mail]>; Sat, 22 Mar 2003 08:40:47 -0800 (PST)
Received: from VON-TP-T30 (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.11.6/8.9.3) with ESMTP id h2MGee4195358; Sat, 22 Mar 2003 10:40:40 -0600
X-Mailer: 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid (via feedmail 10 I); VM 7.07 under 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid
From: "Von Welch" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Sat, 22 Mar 2003 10:41:21 -0600
To: "Jim Schaad" <[e-mail]>
Cc: "IETF-PKIX" <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-proxy-04
In-Reply-To: <000201c2f045$d026f960$[e-mail]>
References: <000201c2f045$d026f960$[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim,

 Thanks - this is good feedback. We will go through your items, most
look very reasonable. We'll issue a new draft as well as responding to
your note directly.

Von

Jim Schaad writes (23:36 March 21, 2003):
 > 
 > I have the following comments, questions and issues with the draft:
 > 
 > 1.  Formatting:  You should be starting the first column of the text in
 > column #1 not column #10.  As it currently is laid out, I have problems
 > reading it.
 > 
 > 2.  Feel free to ignore this comment.  I have a strong preference for
 > statements to be written if A then B not do B if A.  You have several of
 > this variety.  I find this order of writing difficult to read.
 > 
 > 3.  Feel free to ignore this comment.  I have a strong preference for
 > writing protocol statements in a positive manner.  i.e you MUST do this
 > rather than you MUST NOT do that.  From a testing standpoint I claim
 > that I don't know how to test negivate statements, just positive
 > statements.  
 > 
 > 4.  Section 2.3 - I disagree that if stee wants to go offline, he would
 > leave an agent running on his laptop.  Does this agent restart when the
 > laptop goes back on line?
 > 
 > 5.   Section 2.5 - for item 2 on creating identities, would you
 > considere a self-signed certificate to fall into this category?  If so
 > this might be a better example.
 > 
 > 6. Section 2.6 is defined as non-normative, but has a MAY protocol
 > statement in it.  This should be removed.
 > 
 > 7.  Section 3.1 - Certificates are not used to sign anything, keys are.
 > Please remove the statement as it does not have anything to do with the
 > Issuer field.
 > 
 > 8.  Section 3 - Add the following statement:  "Certificates issued by a
 > Proxy Issuer MUST include the ProxyCertInfo extension and the extension
 > MUST be critical."
 > 
 > 9.  Section 3.2 - Please justify this section.  I know of know reason
 > why an IssuerAltName should not be allowed in a PC.
 > 
 > 10.  Section 3.4 - I have a problem with the requirement that a subject
 > be unique.  This means that I cannot issue both a signing PC and an
 > encryption PC to a single proxy agent.  Depending on the algorithm set a
 > single certificiate cannot be used for both operations.
 > 
 > 11. Section 3.4 - Is there a desire to be able to determine what subject
 > of the EE that issued the first proxy certificate without having to do
 > the entire chain processing?  This would seem to be difficult by just
 > appending some cn= components to the subject name.
 > 
 > 12.  Section 3.5 - Ditto of item 7.  I can see needing to potentially
 > define how to do some conversions, are you just trying to avoid that
 > problem?
 > 
 > 13. Section 3.6 - Signing only certificate cannot issue encrypting
 > certificate.
 > 
 > 14.  Section 3.6 - RSA certificate cannot issue DH certificate.
 > 
 > 15.  Section 3.7 - Cannot omit ALL usages in the extKeyUsage extension.
 > The extension requires one be present.
 > 
 > 16.  Section 3.9 - Please remove the version field from the extension.
 > Changes in structure and behavior should be addressed by issuing a new
 > OID for a new extension.
 > 
 > 17.  Section 3.9 - Does a CA have a way to do the equivalent of a
 > pCPathLenConstraint in an EEC?
 > 
 > 18.  Section 3.9.3, bullet item #1 - Why does this statement start "If
 > the PC includes a proxy policy..." This is a required field is it not.
 > It would seem that this should be "The relying policy understands the
 > policy specified and correctly interpets the policy data."
 > 
 > 19.  Section 3.9.3, bullet item #2 - This does not seem to be a correct
 > statement, what if the policy is Independent, it would be indepent of
 > the EEC's authorizations.  In such a case the proxy could have MORE
 > abilities that the EEC would imply.
 > 
 > 20.  Section 3.9.3 - Paragraph starting "Note that since..." When I
 > finally got the last sentence parsed, I think I agreed with it.  I would
 > like to see it written in a clearer manner so I don't have read it
 > multiple times to understand it.  
 > 
 > Suggested text - Te rights granted to the bearer of a PC are the union
 > of the rights granted to the PC identity and the inherited rights.  The
 > inherited rights consist of the intersection of the rights granted to
 > the PI identity intersected with the proxy policy in the PC.
 > 
 > 21.  Section 4 - What about all of the Policy information that was built
 > in the EEC path validation algorithm.  Is this suppose to be passed in
 > or are the extensions not to appear in a PC.
 > 
 > 22.  Section 4 - This is a standard, it is independent of you "plans"
 > either CRLs are covered by the standard or they are not.  If the are not
 > then that needs to be explicit.  If they are ditto.
 > 
 > 23.  Section 4 - policies evalution is messed up big time.  At a minimum
 > you need to put in specialized processing rules for id-ppl-impersonation
 > and possibly for independent as well.  Consider the following:  I ask
 > for a specific policy, I find a PC with with impersonation - according
 > to the rules I must reject the PC chain, but I am sure that is not the
 > desired behavior.
 > 
 > 24.  Section 4 - How does it help to have the proxy_policy_list as an
 > output of the process?  I would think that I need a list of <subject
 > name,  policy> pairs so that I can go find the extra permissions
 > associated with the subject name.
 > 
 > 25.  Section 4 - If ACs are to be permitted for anybody other than the
 > leaf PC, this needs to be folded into the validation algorithm.
 > 
 > 26. Section 5.4.1 - There is a reference to DelegationTrace extension.
 > 
 > 27.  ASN Module Problems:
 > 	id-pe is defined twice.
 > 	id-ppl-impersonation and id-ppl-independent do not match the
 > definitions given in the body of the text with regard to naming of
 > either the OID or the last intenger in the oid string.  The version in
 > the ASN.1 file is the correct method of naming.
 > 	the END statement is missing.
 > 	id-mod definition can be removed as it is unused.
 > 	
 > 
 > 
 > 
 > 
 > 
 > 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2M7awC13267 for ietf-pkix-bks; Fri, 21 Mar 2003 23:36:58 -0800 (PST)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2M7avg13263 for <[e-mail]>; Fri, 21 Mar 2003 23:36:57 -0800 (PST)
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp2.pacifier.net (Postfix) with ESMTP id 41E6E6A5A6 for <[e-mail]>; Fri, 21 Mar 2003 23:36:55 -0800 (PST)
From: "Jim Schaad" <[e-mail]>
To: "IETF-PKIX" <[e-mail]>
Subject: Comments on draft-ietf-pkix-proxy-04
Date: Fri, 21 Mar 2003 23:36:54 -0800
Message-ID: <000201c2f045$d026f960$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have the following comments, questions and issues with the draft:

1.  Formatting:  You should be starting the first column of the text in
column #1 not column #10.  As it currently is laid out, I have problems
reading it.

2.  Feel free to ignore this comment.  I have a strong preference for
statements to be written if A then B not do B if A.  You have several of
this variety.  I find this order of writing difficult to read.

3.  Feel free to ignore this comment.  I have a strong preference for
writing protocol statements in a positive manner.  i.e you MUST do this
rather than you MUST NOT do that.  From a testing standpoint I claim
that I don't know how to test negivate statements, just positive
statements.  

4.  Section 2.3 - I disagree that if stee wants to go offline, he would
leave an agent running on his laptop.  Does this agent restart when the
laptop goes back on line?

5.   Section 2.5 - for item 2 on creating identities, would you
considere a self-signed certificate to fall into this category?  If so
this might be a better example.

6. Section 2.6 is defined as non-normative, but has a MAY protocol
statement in it.  This should be removed.

7.  Section 3.1 - Certificates are not used to sign anything, keys are.
Please remove the statement as it does not have anything to do with the
Issuer field.

8.  Section 3 - Add the following statement:  "Certificates issued by a
Proxy Issuer MUST include the ProxyCertInfo extension and the extension
MUST be critical."

9.  Section 3.2 - Please justify this section.  I know of know reason
why an IssuerAltName should not be allowed in a PC.

10.  Section 3.4 - I have a problem with the requirement that a subject
be unique.  This means that I cannot issue both a signing PC and an
encryption PC to a single proxy agent.  Depending on the algorithm set a
single certificiate cannot be used for both operations.

11. Section 3.4 - Is there a desire to be able to determine what subject
of the EE that issued the first proxy certificate without having to do
the entire chain processing?  This would seem to be difficult by just
appending some cn= components to the subject name.

12.  Section 3.5 - Ditto of item 7.  I can see needing to potentially
define how to do some conversions, are you just trying to avoid that
problem?

13. Section 3.6 - Signing only certificate cannot issue encrypting
certificate.

14.  Section 3.6 - RSA certificate cannot issue DH certificate.

15.  Section 3.7 - Cannot omit ALL usages in the extKeyUsage extension.
The extension requires one be present.

16.  Section 3.9 - Please remove the version field from the extension.
Changes in structure and behavior should be addressed by issuing a new
OID for a new extension.

17.  Section 3.9 - Does a CA have a way to do the equivalent of a
pCPathLenConstraint in an EEC?

18.  Section 3.9.3, bullet item #1 - Why does this statement start "If
the PC includes a proxy policy..." This is a required field is it not.
It would seem that this should be "The relying policy understands the
policy specified and correctly interpets the policy data."

19.  Section 3.9.3, bullet item #2 - This does not seem to be a correct
statement, what if the policy is Independent, it would be indepent of
the EEC's authorizations.  In such a case the proxy could have MORE
abilities that the EEC would imply.

20.  Section 3.9.3 - Paragraph starting "Note that since..." When I
finally got the last sentence parsed, I think I agreed with it.  I would
like to see it written in a clearer manner so I don't have read it
multiple times to understand it.  

Suggested text - Te rights granted to the bearer of a PC are the union
of the rights granted to the PC identity and the inherited rights.  The
inherited rights consist of the intersection of the rights granted to
the PI identity intersected with the proxy policy in the PC.

21.  Section 4 - What about all of the Policy information that was built
in the EEC path validation algorithm.  Is this suppose to be passed in
or are the extensions not to appear in a PC.

22.  Section 4 - This is a standard, it is independent of you "plans"
either CRLs are covered by the standard or they are not.  If the are not
then that needs to be explicit.  If they are ditto.

23.  Section 4 - policies evalution is messed up big time.  At a minimum
you need to put in specialized processing rules for id-ppl-impersonation
and possibly for independent as well.  Consider the following:  I ask
for a specific policy, I find a PC with with impersonation - according
to the rules I must reject the PC chain, but I am sure that is not the
desired behavior.

24.  Section 4 - How does it help to have the proxy_policy_list as an
output of the process?  I would think that I need a list of <subject
name,  policy> pairs so that I can go find the extra permissions
associated with the subject name.

25.  Section 4 - If ACs are to be permitted for anybody other than the
leaf PC, this needs to be folded into the validation algorithm.

26. Section 5.4.1 - There is a reference to DelegationTrace extension.

27.  ASN Module Problems:
	id-pe is defined twice.
	id-ppl-impersonation and id-ppl-independent do not match the
definitions given in the body of the text with regard to naming of
either the OID or the last intenger in the oid string.  The version in
the ASN.1 file is the correct method of naming.
	the END statement is missing.
	id-mod definition can be removed as it is unused.
	








Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2LF33K28275 for ietf-pkix-bks; Fri, 21 Mar 2003 07:03:03 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2LF2xg28264 for <[e-mail]>; Fri, 21 Mar 2003 07:03:00 -0800 (PST)
Subject: Re: The case against directories
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 21 Mar 2003 08:02:46 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 03/21/2003 10:04:06 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>2. Internal information (including employment) is generally not public

in fact, for earlier public PKI certificate-based information, the eventual
result (because of difficult privacy issues, both individual and
institutional, taking some liberty to translate privacy as both a personal
concept as well as an institutional concept) was the lowest common
denominator, a certificate that only contained a institutional number (ex:
various financial certificates) and nothing else, which then were only used
in context of rely-party-only certificates.

the cross domain issues have not been technical (they effectively have all
been a form of privacy, either individual or institutional) .... they were
not technical some 15 years ago with cross-domain kerberos, there were not
technifcal some 6-8 years ago with cross-domain PKI certificates, and they
probably won't be technical this time around with directories. another
simple example of the reduction of information has been the dig/nslookup
responses from  the biggest internet "public" directories, the DNS
root-servers. Over the last five years, nearly all "privacy" information
has disappeared from public responses (like name, address, telephone
number, and email  of administrative and technical contacts).

DNS directories are an example of an online internet information source for
a couple decades and the issue isn't that the praadigm doesn't work, but
there are significant privacy issues (personal & institutional).

And as one of my common references .... certificates are just stale, static
representation of a database/directory entry that exists somewhere ... and
the personal & instititional privacy issues aer common, regardless of the
representational format.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm



                                                                              
                     "Anders Rundgren"                                        
                    <anders.rundgren@t     To:      <[e-mail]>       
                             elia.com>     cc:                                
                              Sent by:     Subject:      The case against     
                    owner-ietf-pkix@ma        directories                     
                            il.imc.org                                        
                                                                              
                                                                              
                      03/21/2003 01:21                                        
                                    AM                                        
                                                                              
                                                                              





I would like to add a few things to what Phillip Hallam-Baker of
VeriSign wrote about directories as an obstacle to PKI deployment.

Many  PKI experts are involved in huge public-sector-driven projects,
that are based on establishing directory interoperability between
organizations.  At first sight this looks like a great idea but digging
a bit further, you soon note that this is not a universal solution but
rather a dead end.

Directory problem issues
1. Technical.  Unifying schemas + firewall issues
2. Internal information  (including employment) is generally not public
3. The level of openness depends on who is asking
4. Directories represent just one way to organize data

But, there is no reason to despair, as there are work-arounds that
properly addresses all these issues:

Using authentication systems like OASIS' SAML, organizations can
(through their employees), authenticate to each others' intranets and
through this get access to exactly the information they should have
and in a format that make sense.  The latter may be a directory tree,
a PDF-file, a database listing, an HTML form, etc.

Unlike directory systems, SAML allows secure access to any kind
of active or passive information source, including purchasing and
work-flow systems.

All using the truly universal Internet browser interface.

For machine-to-machine (=automated) access to external information,
specialized Web Services seems to be a much more extensible route
than directories, as the former introduces no restrictions on data.

Anders Rundgren
Independent consultant PKI and secure e-business





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2L8WFD23460 for ietf-pkix-bks; Fri, 21 Mar 2003 00:32:15 -0800 (PST)
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2L8WEg23456 for <[e-mail]>; Fri, 21 Mar 2003 00:32:14 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailc.telia.com (8.12.8/8.12.8) with SMTP id h2L8W3qa003390 for <[e-mail]>; Fri, 21 Mar 2003 09:32:03 +0100 (CET)
X-Original-Recipient: <[e-mail]>
Message-ID: <00df01c2ef82$d19ed6f0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: The case against directories
Date: Fri, 21 Mar 2003 09:21:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would like to add a few things to what Phillip Hallam-Baker of
VeriSign wrote about directories as an obstacle to PKI deployment.

Many  PKI experts are involved in huge public-sector-driven projects,
that are based on establishing directory interoperability between
organizations.  At first sight this looks like a great idea but digging
a bit further, you soon note that this is not a universal solution but
rather a dead end.

Directory problem issues 
1. Technical.  Unifying schemas + firewall issues
2. Internal information  (including employment) is generally not public
3. The level of openness depends on who is asking
4. Directories represent just one way to organize data

But, there is no reason to despair, as there are work-arounds that
properly addresses all these issues:

Using authentication systems like OASIS' SAML, organizations can
(through their employees), authenticate to each others' intranets and
through this get access to exactly the information they should have
and in a format that make sense.  The latter may be a directory tree,
a PDF-file, a database listing, an HTML form, etc.  

Unlike directory systems, SAML allows secure access to any kind
of active or passive information source, including purchasing and
work-flow systems.

All using the truly universal Internet browser interface.

For machine-to-machine (=automated) access to external information,
specialized Web Services seems to be a much more extensible route
than directories, as the former introduces no restrictions on data.

Anders Rundgren
Independent consultant PKI and secure e-business





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2K8ioP24484 for ietf-pkix-bks; Thu, 20 Mar 2003 00:44:50 -0800 (PST)
Received: from hotmail.com (f83.sea2.hotmail.com [207.68.165.83]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K8ilg24480 for <[e-mail]>; Thu, 20 Mar 2003 00:44:47 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 20 Mar 2003 00:44:43 -0800
Received: from 217.29.140.15 by sea2fd.sea2.hotmail.msn.com with HTTP; Thu, 20 Mar 2003 08:44:39 GMT
X-Originating-IP: [217.29.140.15]
X-Originating-Email: [[e-mail]]
From: "Mohammad Awad" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Which Subject name type is more secure
Date: Thu, 20 Mar 2003 10:44:39 +0200
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 20 Mar 2003 08:44:43.0042 (UTC) FILETIME=[F3BEB820:01C2EEBC]
Sender: [e-mail]
Precedence: 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 wrote:
>>>If one puts only the DNS name in the cert, and then uses the key in the 
>>>cert to authenticate the machine, then a DNS attack will not succeed.
>>
>>And what about if the attacker begins its attack by issuing a certificate 
>>for his own claiming that he is entityA.com? I think the attack can then 
>>succeed.
>
>Here, we assume the attaquer can not break the signature and can not get 
>the victim to trust a CA that is ready to issue the attaquer a fraudulous 
>certificate.
>
>If any of the two is feasible, then whatever added complexity we may 
>imagine, it will NOT be possible to protect the victim with a PKI based 
>solution.
I agree with that. But I've thought that if we ever have got a compromised 
CA that has issued Certs for forged identities, we would be in less 
dangerous state if the attacker had provided in the cert, a forged IP 
address as an identity. That is because, when the attacker ever tries to use 
that forged cert in any break, he would be quickly disclosed, because he 
should keep using the same forged IP ADDRESS in the (src address field of 
each packet) in his traffic. Isn't that hard for any attacker, to use 
another (FORGED IP) rather than his (ORIGINAL ONE) and expect to have 
replies from the entities he communicates, to his ORIGINAL IP ADDRESS 
instead?
>>>However, if one puts in only the IP address, then a DNS attack could 
>>>cause the wrong address to be returned in response to the name-to-address 
>>>mapping, and a valid cert for the "wrong" address would not provide the 
>>>security the user probably envisioned.
>>
>>I think now, that this is the case of the cert being maintained in the DNS 
>>and another machine is retrieving it to authenticate the machine in 
>>question. But in the case of the cert is issued for the IP address of the 
>>entity, I think it should have published its CERT in the IN-ADDR.ARPA DNS 
>>reverse domain, (i.e., indexed by the IP address of the machine), not in 
>>the conventional domain, (indexed by the FQDN). Then when another machine 
>>receives traffic from 217.1.1.1, it should seek its cert record in the 
>>1.1.1.217.IN-ADDR.ARPA (of course if it instructed  that the cert should 
>>be there).
>
>Why would reverse DNS be more secure than forward DNS ?
I did not mean that reverse would be more secure, only more appropriate 
because in the scenario I was talking about a machine (call it 
initiator)(which has got a CERT for IP) is trying to contact another machine 
(call it responder) and the responder needs to verify the initiator's CERT 
(say to establish an SA for IPsec). At the early moments of negotiation, the 
receiver cannot know any identity for the initiator except for that ITS IP 
ADDRESS IS (SAY) 217.1.1.1. So, in order to validate its CERT (which is in 
the DNS), the responder must go to the inverse domain to search for the CERT 
RR indexed by 1.1.1.217.IN-ADDR.ARPA, not in the forward domain which is 
indexed by the FQDN identities that the respoder cannot yet know.
>How would we populate each of the record ?
>Wouldn't certificate be a bit too much data for DNS server records ?
I think these issues are explained in RFC2538.

>What are you trying to achieve here ? I hope at least the record for 
>1.1.1.217.IN-ADDR.ARPA will hold a certificate for 217.1.1.1 and not for 
>another IP address, but what would it proove ?
What it prove: it will facilitate retrieving the Cert of an entity about 
which nothing is ever known except for its IP Address.
>
>Anyway, the logic of trying to secure the IP adress instead of the name is 
>flawed and can not be saved.
>The point is that people start the connexion from a domain name, they never 
>start directly from an IP address.
In many cases, people really do so. But in some other cases, protocol such 
as IPsec may find it helpful to immediately catch the CERT of an entity 
without trying first to know what FQDN does it have.


_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2K16TE25983 for ietf-pkix-bks; Wed, 19 Mar 2003 17:06:29 -0800 (PST)
Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2K16Rg25978 for <[e-mail]>; Wed, 19 Mar 2003 17:06:27 -0800 (PST)
Received: from free.fr (66.104-30-212.9massy1-1-ro-as-i2-1.9tel.net [212.30.104.66]) by ioskeha.hittite.isp.9tel.net (Postfix) with ESMTP id 4686C17B4DE; Thu, 20 Mar 2003 02:07:10 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 20 Mar 2003 02:08:15 +0100
From: Jean-Marc Desperrier <[e-mail]>
Organization: totalement desorganise
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030129
X-Accept-Language: en-us, en, fr, fr-fr, ja
MIME-Version: 1.0
To: Mohammad Awad <[e-mail]>
Cc: [e-mail]
Subject: Re: Which Subject name type is more secure
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>

Mohammad Awad wrote:

>> If one puts only the DNS name in the cert, and then uses the key in 
>> the cert to authenticate the machine, then a DNS attack will not 
>> succeed.
>
> And what about if the attacker begins its attack by issuing a 
> certificate for his own claiming that he is entityA.com? I think the 
> attack can then succeed. 

Here, we assume the attaquer can not break the signature and can not get 
the victim to trust a CA that is ready to issue the attaquer a 
fraudulous certificate.

If any of the two is feasible, then whatever added complexity we may 
imagine, it will NOT be possible to protect the victim with a PKI based 
solution.

>> However, if one puts in only the IP address, then a DNS attack could 
>> cause the wrong address to be returned in response to the 
>> name-to-address mapping, and a valid cert for the "wrong" address 
>> would not provide the security the user probably envisioned.
>
> I think now, that this is the case of the cert being maintained in the 
> DNS and another machine is retrieving it to authenticate the machine 
> in question. But in the case of the cert is issued for the IP address 
> of the entity, I think it should have published its CERT in the 
> IN-ADDR.ARPA DNS reverse domain, (i.e., indexed by the IP address of 
> the machine), not in the conventional domain, (indexed by the FQDN). 
> Then when another machine receives traffic from 217.1.1.1, it should 
> seek its cert record in the 1.1.1.217.IN-ADDR.ARPA (of course if it 
> instructed  that the cert should be there). 

Why would reverse DNS be more secure than forward DNS ?
How would we populate each of the record ?
Wouldn't certificate be a bit too much data for DNS server records ?
What are you trying to achieve here ? I hope at least the record for 
1.1.1.217.IN-ADDR.ARPA will hold a certificate for 217.1.1.1 and not for 
another IP address, but what would it proove ?

Anyway, the logic of trying to secure the IP adress instead of the name 
is flawed and can not be saved.
The point is that people start the connexion from a domain name, they 
never start directly from an IP address.

Let's take for exemple 204.228.229.168 and 218.45.23.125.
Wich one is the address of www.trusbanking.com and which one is 
www.pirate.com ?

There is no meaning in an IP address, you make no difference at sight 
between a dangerous and a trusted ip address.
The current system secure a domain name, and this works reasonnably well.
If you wanted to word with IP address, you would need anyway to link 
204.228.229.168 and www.trusbanking.com, and that link have to be more 
secure than the current system.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2JHnXe01713 for ietf-pkix-bks; Wed, 19 Mar 2003 09:49:33 -0800 (PST)
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2JHnVg01707 for <[e-mail]>; Wed, 19 Mar 2003 09:49:31 -0800 (PST)
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h2JHnQCZ021748 for <[e-mail]>; Wed, 19 Mar 2003 12:49:26 -0500 (EST)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.2/8.12.2) with ESMTP id h2JHnQ6E020629 for <[e-mail]>; Wed, 19 Mar 2003 12:49:26 -0500 (EST)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.2/8.12.2/Submit) id h2JHnPcZ020628 for [e-mail]; Wed, 19 Mar 2003 12:49:25 -0500 (EST)
X-Authentication-Warning: calendar.nist.gov: nobody set sender to [e-mail] using -f
Received: from 130.129.134.63 ( [130.129.134.63]) as user [e-mail] by imp.nist.gov with HTTP; Wed, 19 Mar 2003 12:49:25 -0500
Message-ID: <[e-mail]>
Date: Wed, 19 Mar 2003 12:49:25 -0500
From: [e-mail]
To: [e-mail]
Subject: Updated Agenda for PKIX
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

Here is an updated agenda for tomorrow's meeting.

Thanks,

Tim Polk

--------------------Uopdated Agenda for PKIX at the 56th IETF-----------------

 
PKIX WG (pkix-wg) 

THURSDAY, March 20, 2003 0900-1130 
================================= 

CHAIR: Stephen Kent <[e-mail]>, Tim Polk <[e-mail]> 

AGENDA: 

1. Document Status Review Tim Polk (NIST) 
      The working group has thirty two Internet-Drafts.  A number of 
      documents are with the ADs or in various stages of WG Last Call. 
      Several others are ready for Last Call. (5 min.) 

2. Delegated Path Discovery & Validation (DPD/DPV) 

      The working group has completed the DPD/DPV Requirements document; 
      this specification has become RFC 3379.  The requirements document was 
      developed as baseline for evaluation of competing proposals.  The 
      evaluation is complete and SCVP has been selected as the PKIX DPD/DPV 
      protocol  (25 min. - 5 min. strawpoll, 15 min. SCVP, 5 min. discussion) 

      2.1 DPD/DPV Protocol Selection    Tim Polk 
         
           The WG co-chairs selected SCVP as the PKIX protocol for DPD/DPV 
           based on a strawpoll of the WG, along with evidence of compliance 
           to the requirements stated in 3379. 

      2.2 Simple Certificate Validation Protocol   Trevor Freeman (MicroSoft) 

         http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-11.txt 

           An additional draft of SCVP is expected to achieve full 
           compliance with RFC 3379.  Analysis posted to the list suggests 
           a list of possible open issues based on the compliance matrix. 
           These issues will be addressed, then WG Last Call will commence. 

      2.3 Open Mike Discussion DPD/DPV Protocols 

3. Proxy Certificate Profile - Von Welch (Univ. of Chicago) 

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-04.txt 

      Use of a proxy credential for impersonation is a common technique used in 
      security systems, allowing an entity A to grant to another entity B the 
      right for B to authenticate with others as if it were A.  This document 
      defines a certificate profile for proxy credentials based on RFC 3280. 
      (10 min.) 

4. Specifying Uses for a Public Key - Jim Schaad (Soaring Hawk)

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-00.txt 

      This supplement to RFC 3279 describes conventions for using the
      RSASSA-PSS signature algorithm, the RSAES-OAEP key transport algorithm,
      and additional one-way hash functions for RSA PKCS #1 v1.5 signatures
      in the Internet X.509 Public Key Infrastructure (PKI).  Issues regarding
      the specification of possible key uses have emerged during discussion
      of this document. (10 min.) 

5. Attribute Certificate Policy extension - Christopher Francis (WetStone) 

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-
02.txt 

      This document defines an attribute certificate policy extension, which is 
      an analog to the certificate policies extension for public key 
certificates. 
      This extension can be used to assert the policy governing issuance of the 
      attribute certificate in which it appears. (10 min.) 

6.  Trusted Archive Protocol - Carl Wallace (Cygnacom) 

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-tap-00.txt 

      A Trusted Archive Authority (TAA) is a service that supports long- 
      term non-repudiation by maintaining secure storage of 
      cryptographically refreshed information.  This document defines a set 
      of transactions for interacting with a Trusted Archive Authority 
      (TAA) and establishes a means of representing archived information. 
      (10 min.) 

7.  RFC 3039bis Qualified Certificates Update - Stefan Santesson (Retrospekt) 

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-sonof3039-00.txt 

      An update to RFC 3039, Qualified Certificate Profile, has been submitted. 
      The presentation will describe the proposed modifications and the 
supporting 
      rationale for those changes.  (10 min.) 

8. Maximizing Alignment Between X.500 and LDAP - Skip Slone (Lockheed Martin) 

      http://www.ietf.org/internet-drafts/draft-slone-ldap-x500-align-00.txt 

      This personal draft is intended to provide information of interest to 
      developers of Lightweight Directory Access Protocol (LDAP) specifications 
      and products.  It is intended to provide background information and to 
      facilitate discussion within IETF Working Groups, most notably LDAPbis. 
      This presentation will focus on the alignment of features used when 
      supporting PKI (5 min.) 

9.  RFC 3280 Interoperability Testing Report - Tim Polk (NIST) 

      NIST is currently performing the interoperability testing for RFC 3280. 
      This presentation will update the WG on NIST's progress, projected 
      completion date, and issues identified to date.  (5 min.) 

10. Subscriber Identification Method - Park Jong-Wook (KISA)

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-sim-00.txt
	(note: -01 draft will be posted immediately following the meeting)

      This specification defines a technique to resolve situations where one
      entity holds multiple certificates with different subject names. (5 min.)


11.  European Open Standards for Electronic Signatures: the EESSI 
                                             - Riccardo Genghini (SG&A) 

      The European Elctronic Signature Standardization Initiative (EESSI) is an 
      industry initiative in Support of the European Directive on Electronic 
      Signatures.  EESSI is entering the maintenance phase for their 
specifications, 
      and would like to factor feedback from the technical experts in PKIX into 
      their evolution. (20 min.) 

12. Multi Domian PKI Test Suite -- the result of JNSA Challenge PKI 2002 
                                                          Ryu Inada (JNSA) 

      The Japan Network Security Association conducted JNSA Challenge PKI 2002. 
      One of the results was a Multi-Domain PKI Test Suite.  This presentation 
      will include a brief demonstration of the test suite. (10 min.)

13. LDAP: Schemas, String Values, and more - David Chadwick (Univ of Salford) 
                                 Kurt Zeilenga, co-chair of LDAPbis (OpenLDAP) 

      Experts from the LDAPbis and PKIX WGs have jointly developed a strategy
      for resolution of remaining LDAPv3-PKIX issues.  This presentation will
      provide an overview of the strategy to the WG.  Additional discussion
      will be held on the list.  (10 min.)




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IKQQr04256 for ietf-pkix-bks; Tue, 18 Mar 2003 12:26:26 -0800 (PST)
Received: from hotmail.com (f36.sea2.hotmail.com [207.68.165.36]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IKQOg04252 for <[e-mail]>; Tue, 18 Mar 2003 12:26:24 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 18 Mar 2003 12:26:21 -0800
Received: from 217.29.140.15 by sea2fd.sea2.hotmail.msn.com with HTTP; Tue, 18 Mar 2003 20:26:16 GMT
X-Originating-IP: [217.29.140.15]
From: "Mohammad Awad" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Which Subject name type is more secure
Date: Tue, 18 Mar 2003 22:26:16 +0200
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 18 Mar 2003 20:26:21.0689 (UTC) FILETIME=[A3AAF690:01C2ED8C]
Sender: [e-mail]
Precedence: 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 really appreciate Stephen's comments.
Stephen wrote:

>From: Stephen Kent <[e-mail]>
>To: "Mohammad Awad" <[e-mail]>
>CC: [e-mail]
>Subject: Re: Which Subject name type is more secure
>Date: Tue, 18 Mar 2003 11:50:22 -0500
>
>
>At 9:44 AM +0200 3/16/03, Mohammad Awad wrote:
>>Hi All,
>>I've a question regarding the usage of the X.509 certificate. What is 
>>considered more secure against the identity stealing threat, to have the 
>>alternate subject name of the certificate registering the IP address of 
>>the entity, or the FQDN name? I.e., which of those two (IP, FQDN) result 
>>in more dangerous security breach for when an attacker could steal them.
>>My understanding is that whenever the attacker intend to steal a victim's 
>>IP address, it never can exploit this incident by any gain beyond DoS, 
>>because conceptually the attacker could never receive the packets targeted 
>>to the stolen IP address. On the other hand, by spoofing the DNS system, 
>>the attacker is able to impersonate the victim's FQDN in both sending and 
>>receiving packets, so can perform a real security breach.
>>Could any body kindly provide me with corrections for my understanding.
>>Thank you all.
>>Moham. Awad.
>
>I'm afraid this is not a well-formed question, as it does not state all of 
>the context in which the certs are used.
>
I was concerned in my question about a certain case of identity faking:
Assume (entityA.com at 217.1.1.1) is a machine that have a cert, 
(attacker.com at 100.2.2.2) is an attacker that is trying to impersonating 
the identity of entityA (once by stealing its FQDN and another time  by 
spoofing its ipAddress).
Stealing the FQDN, the attacker can perform it by:
1- ATTACKING the DNS server, i.e., changing the A RR from (entityA is at 
217.1.1.) to be (entityA.com is at 100.2.2.2) and,
2- issuing a cert for his own, publishing it in the CA and also (OPTIONAL) 
in the DNS CERT record
Spoofing the ipAddress, the attacker can perform it by just sending traffic 
having the srcAddress=217.1.1.1 (I think he could never guarantee that reply 
packets should reach him, else the genuine 217.1.1.1, would receive them. is 
this a correct understanding for spoofing ip Addresses?)
I hope this could, to a certain extent, clarify what case I wanted to ask 
about.
>Putting an address in a cert is useful if the CA is authoritative for 
>address space assignments, but not necessarily a great idea otherwise. The 
>same might be said about putting in a DNS name. We usually employ DNS names 
>as the means of identifying machines, so if a cert as both the DNS name and 
>address, it provide protection against DNS attacks, but it faces the 
>problem that an address change necessitates will result in revocation and 
>reissuance of the cert.
I can understand that.
>If one puts only the DNS name in the cert, and then uses the key in the 
>cert to authenticate the machine, then a DNS attack will not succeed.
And what about if the attacker begins its attack by issuing a certificate 
for his own claiming that he is entityA.com? I think the attack can then 
succeed.
>However, if one puts in only the IP address, then a DNS attack could cause 
>the wrong address to be returned in response to the name-to-address 
>mapping, and a valid cert for the "wrong" address would not provide the 
>security the user probably envisioned.
I think now, that this is the case of the cert being maintained in the DNS 
and another machine is retrieving it to authenticate the machine in 
question. But in the case of the cert is issued for the IP address of the 
entity, I think it should have published its CERT in the IN-ADDR.ARPA DNS 
reverse domain, (i.e., indexed by the IP address of the machine), not in the 
conventional domain, (indexed by the FQDN). Then when another machine 
receives traffic from 217.1.1.1, it should seek its cert record in the 
1.1.1.217.IN-ADDR.ARPA (of course if it instructed  that the cert should be 
there).
>
>I hope this example shows how hard it is to respond to the question you 
>posed.
Yes I see. And hope this version of the question will be rather more clear
>
>Steve


_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2IGpN720851 for ietf-pkix-bks; Tue, 18 Mar 2003 08:51:23 -0800 (PST)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2IGpGg20840 for <[e-mail]>; Tue, 18 Mar 2003 08:51:22 -0800 (PST)
Received: from [130.129.136.90] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2IGp066000429; Tue, 18 Mar 2003 11:51:10 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05111a04ba9bbc963cb8@[128.33.238.253]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 18 Mar 2003 11:50:22 -0500
To: "Mohammad Awad" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Which Subject name type is more secure
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 9:44 AM +0200 3/16/03, Mohammad Awad wrote:
>Hi All,
>I've a question regarding the usage of the X.509 certificate. What 
>is considered more secure against the identity stealing threat, to 
>have the alternate subject name of the certificate registering the 
>IP address of the entity, or the FQDN name? I.e., which of those two 
>(IP, FQDN) result in more dangerous security breach for when an 
>attacker could steal them.
>My understanding is that whenever the attacker intend to steal a 
>victim's IP address, it never can exploit this incident by any gain 
>beyond DoS, because conceptually the attacker could never receive 
>the packets targeted to the stolen IP address. On the other hand, by 
>spoofing the DNS system, the attacker is able to impersonate the 
>victim's FQDN in both sending and receiving packets, so can perform 
>a real security breach.
>Could any body kindly provide me with corrections for my understanding.
>Thank you all.
>Moham. Awad.

I'm afraid this is not a well-formed question, as it does not state 
all of the context in which the certs are used.

Putting an address in a cert is useful if the CA is authoritative for 
address space assignments, but not necessarily a great idea 
otherwise. The same might be said about putting in a DNS name. We 
usually employ DNS names as the means of identifying machines, so if 
a cert as both the DNS name and address, it provide protection 
against DNS attacks, but it faces the problem that an address change 
necessitates will result in revocation and reissuance of the cert. If 
one puts only the DNS name in the cert, and then uses the key in the 
cert to authenticate the machine, then a DNS attack will not succeed. 
However, if one puts in only the IP address, then a DNS attack could 
cause the wrong address to be returned in response to the 
name-to-address mapping, and a valid cert for the "wrong" address 
would not provide the security the user probably envisioned.

I hope this example shows how hard it is to respond to the question you posed.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ICGe601910 for ietf-pkix-bks; Tue, 18 Mar 2003 04:16:40 -0800 (PST)
Received: from smtp23.kolumbus.fi (smtp23.kolumbus.fi [193.229.0.81]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ICGbg01902; Tue, 18 Mar 2003 04:16:38 -0800 (PST)
Received: from dom1-cn2-hki.dom1.epnet (dom1-cn2-hki.dom1.epnet [172.21.176.74]) by smtp23.kolumbus.fi (8.12.8/8.12.4) with ESMTP id h2ICGU8D013502; Tue, 18 Mar 2003 14:16:30 +0200 (EET)
Received: from dom1-mb1-hki.dom1.epnet ([172.21.176.65]) by dom1-cn2-hki.dom1.epnet with Microsoft SMTPSVC(5.0.2195.5329); Tue, 18 Mar 2003 14:16:28 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Recommendation on subject matching rules needed..
Date: Tue, 18 Mar 2003 14:16:28 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Recommendation on subject matching rules needed..
Thread-Index: AcLsnzuZOwj2dhVaT1aAMDWXfBe6nAApbtCw
From: "Vainikainen Saku EINT" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 18 Mar 2003 12:16:28.0462 (UTC) FILETIME=[33F074E0:01C2ED48]
X-MailScanner: Found to be clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2ICGdh01905
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >Sounds good, but I suppose we still need to select the keys somehow 
> >(using the certs) through the CryptoAPI CSP and RSA CrypTokI 
> interface, 
> >so that the applications are satisfied.
> 
> It looks like you've been painted into a corner by the 
> selection of software you have to use.  The solution using 
> other software is fairly simple, but if you're stuck with 
> using CryptoAPI and have various other constraints I don't 
> really know what you could do, sorry.  I guess saying "Don't 
> do that then" isn't much help :-).

Yep. Although I don't know of any other non-proprietary
crypto-interfaces that have "widespread" application support so I don't
really see another way around the problem other than put pressure on the
application vendors.

And putting this pressure would be greatly helped by you guys at IETF
PKIX & SMIME if you would draft up a paper about the subject. It could
be part of SMIME specs but I would like to see it a part of PKIX specs,
since the same issue is present when building certification paths during
certificate verification process, as well as when making the call wether
to trust the presented CA certificate or not..

Saku.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HNCqD09339 for ietf-pkix-bks; Mon, 17 Mar 2003 15:12:52 -0800 (PST)
Received: from groove.net (groove.net [63.209.254.203] (may be forged)) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HNCpg09329 for <[e-mail]>; Mon, 17 Mar 2003 15:12:51 -0800 (PST)
Received: from notes.internalgroove.net (notes.internalgroove.net [10.11.8.20]) by groove.net (8.9.3/8.9.3) with SMTP id XAA06468; Mon, 17 Mar 2003 23:12:42 GMT
Sensitivity: 
Subject: 
To: [e-mail]
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
Message-ID: <[e-mail]>
From: [e-mail]
Date: Mon, 17 Mar 2003 18:12:43 -0500
X-MIMETrack: Serialize by Router on Rich/Groove(Release 5.0.9a |January 7, 2002) at 03/17/2003 06:12:43 PM
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2HNCpg09332
Sender: [e-mail]
Precedence: 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 the clarification (re single-user vs. multi-user
file-encryption/protection).  The multi-user case has been thoroughly
discussed in this thread, and I have nothing to add to that.  However, I'm
wondering if there isn't some lingering open-endedness left over, regarding
the single-user case?

I've tried to think of reasons one might prefer PKC techniques (over
non-cert/bare-key techniques, presumably secret-key only) for the
single-user file-encryption problem, and I couldn't think of one.  That
probably shouldn't be too surprising.  PKC/X509 is explicitly designed to
be an *authentication* framework, and authentication (properly so-called)
involves two distinct parties (a claimant and a checker/validator).  But in
the case of single-user file-encryption, there is only a single party
involved (the file is assumed to be entirely under the control of the
single "self" entity), hence no true authentication is happening.

So, given all the PKC gotcha's discussed in this thread, I couldn't come up
with any rationale whatsoever to prefer PKC over bare-key techniques for
single-user file-encryption.  If anyone can think of such an argument, I'd
really be interested in hearing about it, publicly or privately.

- Walt Tuvell, Groove Networks




----- Original Message -----
From: "Vainikainen Saku EINT" <[e-mail]>
To: <[e-mail]>
Sent: Friday, March 14, 2003 7:06 PM
Subject: Recommendation on subject matching rules needed..

>
>
> > My question is: Why is a *cert* being used for *personal*
> > file protection (i.e., "from/to self", as opposed to
> > protection of the file when it is communicated from one
> > entity to another)?  It would seem that certs are the wrong
> > tool for this job.  *Bare* keys (keypairs or secret keys,
> > perhaps derived from a passphrase) seem to be the right tool.
> >
> > ...
> >
> > All-in-all, it seems that a better solution would be to store
> > a bare secret key on the smartcard and use that to protect
> > his files, doesn't it?
>
> Yes - this sounds reasonable when the same person is always encrypting
> and decrypting the file, but the disk/folder/file encryption systems
> need multi-user capabilities, ie. more than one person is required to
> access the encrypted file.
>
> If you use secret keys to encrypt the data for let's say 20 persons,
> your data bloats 20-fold, or of course you could generate a session key
> for bulk encryption of the data and just use personal secret keys to
> encrypt that key for each user. You still have to somehow identify the
> "legal" users of the encrypted disk/folder/file, instead of
> trial-and-error decryption. What better way to do this than
> certificates.. ?
>
> This applies to hybrid encryption also: bare keypairs are not enough
> since trial-and-error decryption is resource consuming, thus not wise.
>
> Of course one could insert some checksums or whatever constant data to
> the first encrypted block to make the trial-and-error decryption faster,
> but this would also introduce a good way for a brute force key quesser
> to figure out the secret key.. No good.
>
> And passphrases still need to be broadcast/transmitted to and remembered
> by all users, and it is not wise to use the same passphrase for all
> encrypted data, so they are no good.
>
> Saku.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HL17a01392 for ietf-pkix-bks; Mon, 17 Mar 2003 13:01:07 -0800 (PST)
Received: from vmmr8.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HL15g01383 for <[e-mail]>; Mon, 17 Mar 2003 13:01:05 -0800 (PST)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr8.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AIM96742; Mon, 17 Mar 2003 16:01:05 -0500 (EST)
Received: from laptop-cpq.retrospekt.com ([66.114.232.109]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ACC94369; Mon, 17 Mar 2003 16:01:03 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 17 Mar 2003 22:00:56 +0100
To: Denis Pinkas <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: QC Declaration
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'm not sure what trouble you have but let me help you find them. They are 
right there in the text:

Questions:
a) Is there any case/context where fact 3 actually is not a problem, but 
rather a feature?
b) could any such context be clearly defined and included in RFC 3039bis or 
any local standard?

/Stefan

At 16:38 2003-03-17 +0100, Denis Pinkas wrote:

>Stefan,
>
>>Sharon and all,
>
>>I've heard many answers but the questions that needs them has not yet ben 
>>formulated.
>
>So what is the question for which you already got negative answers ?
>
>:-)
>
>Denis
>
>>Lets get back to this issue and do that.
>>Facts:
>>1) Current definition of the qcStatements ext says that if the extension 
>>is critical then all statements are critical.
>>2) It is compliant with X.509 to state that if an extension is critical, 
>>it is OK to recognize at least 1 of the contained elements. It is however 
>>unlikely that this is a good solution for the qcStatements extension, due 
>>to legacy and the different nature of different statements.
>>3) If one would set this extension as critical, it is likely that many 
>>applications would reject the certificate. This could be true also over 
>>time in the future since many local statement could be defined that would 
>>not be supported by clients in general.
>>Questions:
>>a) Is there any case/context where fact 3 actually is not a problem, but 
>>rather a feature?
>>b) could any such context be clearly defined and included in RFC 3039bis 
>>or any local standard?
>>
>>Answers:
>>Question a)
>>Yes there has been situations raised where fact 3 actually could be a 
>>feature.
>>Many has complained about the problem to isolate a particular certificate 
>>for use in only electronic signature applications where the content is 
>>clearly presented and accepted by the signer prior to signing. The key 
>>usage or extended key usage extensions are not ready to provide this 
>>functionality. At least not today.
>>So, given that we would have a certificate that we WANT applications in 
>>general to reject it. A certificate that we only want those applications 
>>that are trained and designed to accept it,  to actually accept it. Then 
>>this could in fact be a great feature.
>>It could be the mechanism that would force all low grade applications to 
>>reject its use, and thus increase its evidence value when it is used.
>>
>>b) It is true that the case described in answer a) does not apply to all 
>>certificates. But given that there are cases where it is of great value 
>>to isolate certificates use to informed applications. Then it might as 
>>well be worth the effort to try to formulate one or some clear contexts 
>>where setting the extension critical ought to be mandatory OR at least 
>>recommended.
>>
>>Opinions:
>>My opinion is that it is our responsibility to look seriously into this 
>>issue with open minds before we reach a definitive conclusion to answer 
>>b). Personally I do believe we have a chance to contribute in a good way 
>>to supporting good use and acceptance of electronic signatures and 
>>believe that such context could and should be formulated.
>>
>>/Stefan
>>
>>
>>At 15:19 2003-03-12 -0500, Sharon Boeyen wrote:
>>
>>>It would have been compliant IF the semantics of the extension stated 
>>>that. However, the semantics of the extension dictate the opposite where 
>>>ALL statements are critical.
>>>
>>>     -----Original Message-----
>>>     From: Stefan Santesson [mailto:[e-mail]]
>>>     Sent: Tuesday, March 11, 2003 4:49 PM
>>>     To: Sharon Boeyen; [e-mail]
>>>     Subject: RE: QC Declaration
>>>
>>>     Sharon,
>>>
>>>     The first step for me is to get the mechanics right.
>>>
>>>     Are you saying that it would have been compliant with X.509 to
>>>     declare that a critical QCStatement (disregarding the current
>>>     declaration in RFC 3039) is valid if I can process at least one of
>>>     the present statements (similar to SubjectAltName).
>>>
>>>     Not that I claim that it would be a good idea.
>>>
>>>     /Stefan
>>>
>>>
>>>     At 16:30 2003-03-11 -0500, Sharon Boeyen wrote:
>>>
>>>>         I don't want to get off on a non-relevant tangent regarding
>>>>         criticality, but think I do need to clarify a little bit on
>>>>         the subject Alt Name extension. If you check 8.3.2.3 (509)
>>>>         you'll find that the semantics of that extension are such
>>>>         that, if set to critical, "at least one of the name forms
>>>>         that is present shall be recognized and processed ...". So
>>>>         if, in your example, the ONLY name present in subjectAltName
>>>>         extension is the unknown otherName OID, then you are correct
>>>>         and the certificate shall be considered invalid. If however,
>>>>         that unknown otherName OID was present AND and rfc822Name was
>>>>         present - the RP might understand the rfc822Name and check it
>>>>         against the intended recipient of an encrypted email for
>>>>         example, and under those circumstances the certificate would
>>>>         be valid, even though the extension was critical and there
>>>>         was another nameform in there that was not understood.
>>>>
>>>>         I suspect that its probably a bit too soon to profile the
>>>>         kind of contexts I think you're describing in 3039. I'd
>>>>         prefer to see a bit more practical use of QCs first so that
>>>>         we have a better handle on what constitutes a "context". For
>>>>         example, perhaps one context is with the ETSI qcstatement 1
>>>>         plus a specific national qc statement and if both are present
>>>>         in a certificate that some 'authority' (I don't mean a CA
>>>>         here) deems that when that combination is present the
>>>>         extension shall be set to critical. I'm not necessarily
>>>>         opposing the idea, just a little uncomfortable with the
>>>>         proposed timing without significant real world deployment to
>>>>         guide us with to the appropriate 'contexts'.
>>>>
>>>>         Cheers,
>>>>         Sharon -----Original Message----- From: Stefan Santesson
>>>>         [mailto:[e-mail]] Sent: Tuesday, March 11, 2003
>>>>         4:06 PM To: Sharon Boeyen; Sharon Boeyen; [e-mail]
>>>>         Subject: RE: QC Declaration
>>>>
>>>>         Sharon, Thanks for the clarification.
>>>>         "Elements of the syntax" really clarifies things.
>>>>         So it is OK to accept an certificate with a critical policy
>>>>         extension containing an policy OID that I don't recognize,
>>>>         because it doesn't define any further syntax of the
>>>>         extension. The same goes with Extended key usage OIDs.
>>>>         However. It would not be OK with a critical subjectAltName
>>>>         containing an unknown other name OID, since this OID would
>>>>         define further syntax. By the same reason I would need to
>>>>         understand all present QCStatements OIDs, because they do the
>>>>         same (define further syntax).
>>>>         Let me clarify that I never proposed that the QCStatement
>>>>         must be critical in all certificates. I'm just recognizing
>>>>         that it might be a valuable practice within certain contexts
>>>>         and the fact that some implementers actually ask for it. The
>>>>         question is whether any of those contexts can be identified
>>>>         within RFC 3039, or if they are better placed in local
>>>>         sub-profiles (Such as ETSI TS 101862), or if they don't exist
>>>>         in a way that can be standardized in a meaningful way.
>>>>
>>>>         /Stefan
>>>>
>>>>         At 11:37 2003-03-11 -0500, Sharon Boeyen wrote:
>>>>
>>>>>             Hi Stefan,
>>>>>               Remember first that RFC 3280 is a "profile" of X.509
>>>>>             and it does not replace the requirements of 509, but
>>>>>             rather profiles them to a subset.
>>>>>               X.509 in clause 7 allows unknown elements in
>>>>>             non-critical extensions only to be ignored. However,
>>>>>             that is more with respect to the elements in the syntax
>>>>>             itself (for example in the IDP extension no RP is
>>>>>             allowed to ignore the "onlySomeReasons" element if it is
>>>>>             present in the extension because the extension can only
>>>>>             be critical. The behaviour of RPs will differ however
>>>>>             depending on their specific capability with respect to
>>>>>             that element (some will use the CRL for the specified
>>>>>             reasons and others will seek a different CRL that covers
>>>>>             all reasons), however, no RP is permitted to simply
>>>>>             ignore the flag. Note also that in that same clause, for
>>>>>             extensions that can be marked critical or non-critical,
>>>>>             a system that understands the extension is required to
>>>>>             process it regardless of the value of the criticality
>>>>>             flag. It is ONLY systems that do not understand an
>>>>>             extension that can ignore it completely if it is marked
>>>>>             non-critical.
>>>>>               For the QC Statements extension, RFC 3039 says "This
>>>>>             extension may be critical or non-critical.  If the
>>>>>             extension is critical, this means that all statements
>>>>>             included in the extension are regarded as critical. "
>>>>>               Because of the semantics defined for the extension in
>>>>>             RFC 3039, marking it critical would result in the
>>>>>             problems I raised.
>>>>>
>>>>>             -----Original Message----- From: Stefan Santesson
>>>>>             [mailto:[e-mail]] Sent: Tuesday, March 11,
>>>>>             2003 11:23 AM To: Sharon Boeyen; [e-mail]
>>>>>             Subject: RE: QC Declaration
>>>>>
>>>>>             Hi Sharon, My interpretation of criticality does not
>>>>>             really match yours. The only guidance on the meaning of
>>>>>             criticality in RFC 3280 (section 4.2) that I can find is:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>  "A certificate using system MUST reject the
>>>>>
>>>>>
>>>>>certificate
>>>>>
>>>>>
>>>>>
>>>>>if it encounters a critical extension it does not recognize"
>>>>>
>>>>>             My interpretation is that it is OK to accept a
>>>>>             certificate if you recognize the extension as such. You
>>>>>             don't need to understand ALL information that the
>>>>>             extension contains. It seam vital to agree on this issue
>>>>>             before we can make any conclusion on QCStatament
>>>>>             criticality. /Stefan
>>>>>             At 10:56 2003-03-11 -0500, Sharon Boeyen wrote:
>>>>>
>>>>>>                 Hi Stefan, While I believe that in the longer term
>>>>>>                 certificate policies will be the optimum way to
>>>>>>                 convey the necessary information, I acknowledge
>>>>>>                 that QC Statements is the more popular scheme at
>>>>>>                 present. Therefore I wouldn't have any problem
>>>>>>                 should this extension be mandated in RFC 3039.
>>>>>>                 However, forcing its criticality is going too far I
>>>>>>                 believe. There is an important difference between
>>>>>>                 critical and non-critical extensions that we need
>>>>>>                 to keep in mind from the relying party's
>>>>>>                 perspective. If there is a non-critical extension
>>>>>>                 that the RP understands, but that extension
>>>>>>                 includes some elements that it does not, then the
>>>>>>                 RP is free to process the parts it does understand
>>>>>>                 and ignore others. If an extension is critical
>>>>>>                 however, the RP is required to understand ALL
>>>>>>                 elements within the extension. Where I think this
>>>>>>                 can become a problem is the content of the QC
>>>>>>                 Statements extension. Note that RFC 3039 and the
>>>>>>                 ETSI profile define DIFFERENT statements for
>>>>>>                 inclusion in the extension. Also additional
>>>>>>                 profiles may add their own local statements and
>>>>>>                 even narrower statements can get added in specific
>>>>>>                 deployment environments. While the cert issuer may
>>>>>>                 want to include many of these statements to enable
>>>>>>                 the cert to be used in various environments, the RP
>>>>>>                 should only be required to understand and process
>>>>>>                 the statements that are appropriate to its own
>>>>>>                 operating environment as dictated by its local
>>>>>>                 security policy (which could be different than that
>>>>>>                 under which the CA operated). Therefore I think
>>>>>>                 requiring it to be critical is risky. Also
>>>>>>                 requiring that it always be critical would have
>>>>>>                 interop/backward compatibility issues. Cheers, Sharon
>>>>>>
>>>>>>
>>>>>>                 -----Original Message----- From: Stefan Santesson
>>>>>>                 [mailto:[e-mail]] Sent: Tuesday, March
>>>>>>                 11, 2003 8:27 AM To: [e-mail] Subject: QC
>>>>>>                 Declaration
>>>>>>
>>>>>>                 The EU directive introduced a requirement on each
>>>>>>                 CA, issuing QC (Qualified Certificates), to clearly
>>>>>>                 indicate in these certificate that they are issued
>>>>>>                 as QC. ETSI implemented RFC 3039 in relation to the
>>>>>>                 European electronic signature directive through
>>>>>>                 their Technical Standard (TS 101862) TS 101862
>>>>>>                 specified 2 alternative ways to declare a
>>>>>>                 certificate as QC. 1) By inclusion of a
>>>>>>                 QCStatements extension 2) By including a
>>>>>>                 certificate policy identifying this property Even
>>>>>>                 though solution number 1) is far easier to handle
>>>>>>                 by applications, since they don't need to recognize
>>>>>>                 specific QC Policies, ETSI didn't make solution 1)
>>>>>>                 mandatory or even consider making it critical, due
>>>>>>                 to lack of confidence that clients would widely
>>>>>>                 deploy this solution. ETSI needed to define a
>>>>>>                 solution that could work even if no one choose to
>>>>>>                 implement the new extensions provided by RFC 3039.
>>>>>>                 However, It is not feasible to keep clients updated
>>>>>>                 over time with different QC policies and even those
>>>>>>                 policies that are regarded standardized may be
>>>>>>                 updated with change of OID as a result. It would be
>>>>>>                 devastating if we can't update a QCP because that
>>>>>>                 would force an OID update and that would render
>>>>>>                 certificates useless because clients learned to
>>>>>>                 recognize only the old OID. This would be to build
>>>>>>                 in a new root certificate problem into the
>>>>>>                 platforms. My observations is that times have
>>>>>>                 changed. I have seen clear indications that market
>>>>>>                 players want, and even require for interoperability
>>>>>>                 reasons, that use QCStatements solution is made
>>>>>>                 mandatory and maybe even critical for QC. Since
>>>>>>                 both RFC 3039, and TS 101862 are up for revision,
>>>>>>                 it is time to revisit this issue. I have some
>>>>>>                 questions and proposals: - Is there any experiences
>>>>>>                 of this issue outside of Europe. I.e. are there
>>>>>>                 other legal systems that make use of the same
>>>>>>                 declaration logic as the EU directive, where the
>>>>>>                 RFC 3039 profile is used fully or partly as a
>>>>>>                 solution to this issue? - I would suggest that the
>>>>>>                 QCStatement mechanism is ought to be a mandatory
>>>>>>                 tool to communicate a Qualified Status. The
>>>>>>                 question is:     1) whether this will have enough
>>>>>>                 implementation support to succeed?     2) whether
>>>>>>                 is best specified in RFC 3039 or in local profiles
>>>>>>                 (such as TS 101862)?     3) If there could be a
>>>>>>                 clear context defined where criticality could be
>>>>>>                 allowed or even required? I would really like
>>>>>>                 feedback from practical experiences from this
>>>>>>                 issue, as well as constructive proposals. /Stefan
>>>>>>
>>>>>>
>>>>>>                 /Stefan
>>>>>>
>>>>>>                 _____________________________ Stefan 
>>>>>> Santesson,                 Retrospekt AB http://www.retrospekt.com
>>>>>>             <http://www.retrospekt.com/> [phone]
>>>>>
>>>>>             _____________________________ Stefan 
>>>>> Santesson,             Retrospekt AB http://www.retrospekt.com
>>>>>         <http://www.retrospekt.com/> [phone]
>>>
>>>_____________________________
>>>Stefan Santesson,  Retrospekt AB
>>>http://www.retrospekt.com <http://www.retrospekt.com/>
>>>[phone]
>>
>>_____________________________
>>Stefan Santesson,  Retrospekt AB
>>http://www.retrospekt.com <http://www.retrospekt.com/>
>>[phone]
>>_____________________________
>>Stefan Santesson,  Retrospekt AB
>>http://www.retrospekt.com <http://www.retrospekt.com/>
>>[phone]
>

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone] 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HFqsk14001 for ietf-pkix-bks; Mon, 17 Mar 2003 07:52:54 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HFqqg13994 for <[e-mail]>; Mon, 17 Mar 2003 07:52:52 -0800 (PST)
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA23324; Mon, 17 Mar 2003 16:55:33 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id PAA25463; Mon, 17 Mar 2003 15:49:12 +0100
Message-ID: <[e-mail]>
Date: Mon, 17 Mar 2003 16:52:52 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: pkix <[e-mail]>
Subject: RFC 3039bis is not needed
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The title of my previous e-mail was wrong:

It is not : "RFC 3039 is not needed", but
             "RFC 3039bis is not needed"

Hereafter is a copy of the text included in the previous message:

****************************************************************

Stefan,

Up to now, no argument brought to the list justifies that we should
change and thus revise RFC 3039.

We have enough other work to do and changes to that document are not needed.
For all standards, we need both stability and backward compatibility.

Denis



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HFfie13681 for ietf-pkix-bks; Mon, 17 Mar 2003 07:41:44 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HFffg13677 for <[e-mail]>; Mon, 17 Mar 2003 07:41:41 -0800 (PST)
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA05480; Mon, 17 Mar 2003 16:44:22 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id PAA25408; Mon, 17 Mar 2003 15:38:01 +0100
Message-ID: <[e-mail]>
Date: Mon, 17 Mar 2003 16:41:41 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: pkix <[e-mail]>
Subject: RFC 3039 is not needed
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

Up to now, no argument brought to the list justifies that we should
change and thus revise RFC 3039.

We have enough other work to do and changes to that document are not needed.
For all standards, we need both stability and backward compatibility.

Denis



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HFcl313532 for ietf-pkix-bks; Mon, 17 Mar 2003 07:38:47 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HFcgg13528 for <[e-mail]>; Mon, 17 Mar 2003 07:38:42 -0800 (PST)
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA18694; Mon, 17 Mar 2003 16:41:21 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id PAA25390; Mon, 17 Mar 2003 15:34:59 +0100
Message-ID: <[e-mail]>
Date: Mon, 17 Mar 2003 16:38:39 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: [e-mail]
Subject: Re: QC Declaration
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

> Sharon and all,

> I've heard many answers but the questions that needs them has not yet 
> ben formulated.

So what is the question for which you already got negative answers ?

:-)

Denis

> Lets get back to this issue and do that.
> 
> Facts:
> 
> 1) Current definition of the qcStatements ext says that if the extension 
> is critical then all statements are critical.
> 
> 2) It is compliant with X.509 to state that if an extension is critical, 
> it is OK to recognize at least 1 of the contained elements. It is 
> however unlikely that this is a good solution for the qcStatements 
> extension, due to legacy and the different nature of different statements.
> 
> 3) If one would set this extension as critical, it is likely that many 
> applications would reject the certificate. This could be true also over 
> time in the future since many local statement could be defined that 
> would not be supported by clients in general.
> 
> Questions:
> 
> a) Is there any case/context where fact 3 actually is not a problem, but 
> rather a feature?
> 
> b) could any such context be clearly defined and included in RFC 3039bis 
> or any local standard?
> 
> 
> Answers:
> 
> Question a)
> Yes there has been situations raised where fact 3 actually could be a 
> feature.
> 
> Many has complained about the problem to isolate a particular 
> certificate for use in only electronic signature applications where the 
> content is clearly presented and accepted by the signer prior to 
> signing. The key usage or extended key usage extensions are not ready to 
> provide this functionality. At least not today.
> 
> So, given that we would have a certificate that we WANT applications in 
> general to reject it. A certificate that we only want those applications 
> that are trained and designed to accept it,  to actually accept it. Then 
> this could in fact be a great feature.
> 
> It could be the mechanism that would force all low grade applications to 
> reject its use, and thus increase its evidence value when it is used.
> 
> 
> b) It is true that the case described in answer a) does not apply to all 
> certificates. But given that there are cases where it is of great value 
> to isolate certificates use to informed applications. Then it might as 
> well be worth the effort to try to formulate one or some clear contexts 
> where setting the extension critical ought to be mandatory OR at least 
> recommended.
> 
> 
> Opinions:
> 
> My opinion is that it is our responsibility to look seriously into this 
> issue with open minds before we reach a definitive conclusion to answer 
> b). Personally I do believe we have a chance to contribute in a good way 
> to supporting good use and acceptance of electronic signatures and 
> believe that such context could and should be formulated.
> 
> 
> /Stefan
> 
> 
> 
> 
> 
> At 15:19 2003-03-12 -0500, Sharon Boeyen wrote:
> 
>> It would have been compliant IF the semantics of the extension stated 
>> that. However, the semantics of the extension dictate the opposite 
>> where ALL statements are critical.
>>
>>     -----Original Message-----
>>     From: Stefan Santesson [mailto:[e-mail]]
>>     Sent: Tuesday, March 11, 2003 4:49 PM
>>     To: Sharon Boeyen; [e-mail]
>>     Subject: RE: QC Declaration
>>
>>     Sharon,
>>
>>     The first step for me is to get the mechanics right.
>>
>>     Are you saying that it would have been compliant with X.509 to
>>     declare that a critical QCStatement (disregarding the current
>>     declaration in RFC 3039) is valid if I can process at least one of
>>     the present statements (similar to SubjectAltName).
>>
>>     Not that I claim that it would be a good idea.
>>
>>     /Stefan
>>
>>
>>     At 16:30 2003-03-11 -0500, Sharon Boeyen wrote:
>>
>>>         I don't want to get off on a non-relevant tangent regarding
>>>         criticality, but think I do need to clarify a little bit on
>>>         the subject Alt Name extension. If you check 8.3.2.3 (509)
>>>         you'll find that the semantics of that extension are such
>>>         that, if set to critical, "at least one of the name forms
>>>         that is present shall be recognized and processed ...". So
>>>         if, in your example, the ONLY name present in subjectAltName
>>>         extension is the unknown otherName OID, then you are correct
>>>         and the certificate shall be considered invalid. If however,
>>>         that unknown otherName OID was present AND and rfc822Name was
>>>         present - the RP might understand the rfc822Name and check it
>>>         against the intended recipient of an encrypted email for
>>>         example, and under those circumstances the certificate would
>>>         be valid, even though the extension was critical and there
>>>         was another nameform in there that was not understood.
>>>          
>>>         I suspect that its probably a bit too soon to profile the
>>>         kind of contexts I think you're describing in 3039. I'd
>>>         prefer to see a bit more practical use of QCs first so that
>>>         we have a better handle on what constitutes a "context". For
>>>         example, perhaps one context is with the ETSI qcstatement 1
>>>         plus a specific national qc statement and if both are present
>>>         in a certificate that some 'authority' (I don't mean a CA
>>>         here) deems that when that combination is present the
>>>         extension shall be set to critical. I'm not necessarily
>>>         opposing the idea, just a little uncomfortable with the
>>>         proposed timing without significant real world deployment to
>>>         guide us with to the appropriate 'contexts'.
>>>          
>>>         Cheers,
>>>         Sharon -----Original Message----- From: Stefan Santesson
>>>         [mailto:[e-mail]] Sent: Tuesday, March 11, 2003
>>>         4:06 PM To: Sharon Boeyen; Sharon Boeyen; [e-mail]
>>>         Subject: RE: QC Declaration
>>>
>>>         Sharon, Thanks for the clarification.
>>>         "Elements of the syntax" really clarifies things.
>>>         So it is OK to accept an certificate with a critical policy
>>>         extension containing an policy OID that I don't recognize,
>>>         because it doesn't define any further syntax of the
>>>         extension. The same goes with Extended key usage OIDs.
>>>         However. It would not be OK with a critical subjectAltName
>>>         containing an unknown other name OID, since this OID would
>>>         define further syntax. By the same reason I would need to
>>>         understand all present QCStatements OIDs, because they do the
>>>         same (define further syntax).
>>>         Let me clarify that I never proposed that the QCStatement
>>>         must be critical in all certificates. I'm just recognizing
>>>         that it might be a valuable practice within certain contexts
>>>         and the fact that some implementers actually ask for it. The
>>>         question is whether any of those contexts can be identified
>>>         within RFC 3039, or if they are better placed in local
>>>         sub-profiles (Such as ETSI TS 101862), or if they don't exist
>>>         in a way that can be standardized in a meaningful way.
>>>
>>>         /Stefan
>>>
>>>         At 11:37 2003-03-11 -0500, Sharon Boeyen wrote:
>>>
>>>>             Hi Stefan,
>>>>               Remember first that RFC 3280 is a "profile" of X.509
>>>>             and it does not replace the requirements of 509, but
>>>>             rather profiles them to a subset.
>>>>               X.509 in clause 7 allows unknown elements in
>>>>             non-critical extensions only to be ignored. However,
>>>>             that is more with respect to the elements in the syntax
>>>>             itself (for example in the IDP extension no RP is
>>>>             allowed to ignore the "onlySomeReasons" element if it is
>>>>             present in the extension because the extension can only
>>>>             be critical. The behaviour of RPs will differ however
>>>>             depending on their specific capability with respect to
>>>>             that element (some will use the CRL for the specified
>>>>             reasons and others will seek a different CRL that covers
>>>>             all reasons), however, no RP is permitted to simply
>>>>             ignore the flag. Note also that in that same clause, for
>>>>             extensions that can be marked critical or non-critical,
>>>>             a system that understands the extension is required to
>>>>             process it regardless of the value of the criticality
>>>>             flag. It is ONLY systems that do not understand an
>>>>             extension that can ignore it completely if it is marked
>>>>             non-critical.
>>>>               For the QC Statements extension, RFC 3039 says "This
>>>>             extension may be critical or non-critical.  If the
>>>>             extension is critical, this means that all statements
>>>>             included in the extension are regarded as critical. "
>>>>               Because of the semantics defined for the extension in
>>>>             RFC 3039, marking it critical would result in the
>>>>             problems I raised.
>>>>
>>>>             -----Original Message----- From: Stefan Santesson
>>>>             [mailto:[e-mail]] Sent: Tuesday, March 11,
>>>>             2003 11:23 AM To: Sharon Boeyen; [e-mail]
>>>>             Subject: RE: QC Declaration
>>>>
>>>>             Hi Sharon, My interpretation of criticality does not
>>>>             really match yours. The only guidance on the meaning of
>>>>             criticality in RFC 3280 (section 4.2) that I can find is:
>>>>
>>>>
>>>>
>>>>
>>>>  "A certificate using system MUST reject the
>>>>
>>>>
>>>>certificate
>>>>
>>>>
>>>>
>>>>if it encounters a critical extension it does not recognize"
>>>>
>>>>             My interpretation is that it is OK to accept a
>>>>             certificate if you recognize the extension as such. You
>>>>             don't need to understand ALL information that the
>>>>             extension contains. It seam vital to agree on this issue
>>>>             before we can make any conclusion on QCStatament
>>>>             criticality. /Stefan
>>>>             At 10:56 2003-03-11 -0500, Sharon Boeyen wrote:
>>>>
>>>>>                 Hi Stefan, While I believe that in the longer term
>>>>>                 certificate policies will be the optimum way to
>>>>>                 convey the necessary information, I acknowledge
>>>>>                 that QC Statements is the more popular scheme at
>>>>>                 present. Therefore I wouldn't have any problem
>>>>>                 should this extension be mandated in RFC 3039.
>>>>>                 However, forcing its criticality is going too far I
>>>>>                 believe. There is an important difference between
>>>>>                 critical and non-critical extensions that we need
>>>>>                 to keep in mind from the relying party's
>>>>>                 perspective. If there is a non-critical extension
>>>>>                 that the RP understands, but that extension
>>>>>                 includes some elements that it does not, then the
>>>>>                 RP is free to process the parts it does understand
>>>>>                 and ignore others. If an extension is critical
>>>>>                 however, the RP is required to understand ALL
>>>>>                 elements within the extension. Where I think this
>>>>>                 can become a problem is the content of the QC
>>>>>                 Statements extension. Note that RFC 3039 and the
>>>>>                 ETSI profile define DIFFERENT statements for
>>>>>                 inclusion in the extension. Also additional
>>>>>                 profiles may add their own local statements and
>>>>>                 even narrower statements can get added in specific
>>>>>                 deployment environments. While the cert issuer may
>>>>>                 want to include many of these statements to enable
>>>>>                 the cert to be used in various environments, the RP
>>>>>                 should only be required to understand and process
>>>>>                 the statements that are appropriate to its own
>>>>>                 operating environment as dictated by its local
>>>>>                 security policy (which could be different than that
>>>>>                 under which the CA operated). Therefore I think
>>>>>                 requiring it to be critical is risky. Also
>>>>>                 requiring that it always be critical would have
>>>>>                 interop/backward compatibility issues. Cheers, Sharon
>>>>>
>>>>>
>>>>>                 -----Original Message----- From: Stefan Santesson
>>>>>                 [mailto:[e-mail]] Sent: Tuesday, March
>>>>>                 11, 2003 8:27 AM To: [e-mail] Subject: QC
>>>>>                 Declaration
>>>>>
>>>>>                 The EU directive introduced a requirement on each
>>>>>                 CA, issuing QC (Qualified Certificates), to clearly
>>>>>                 indicate in these certificate that they are issued
>>>>>                 as QC. ETSI implemented RFC 3039 in relation to the
>>>>>                 European electronic signature directive through
>>>>>                 their Technical Standard (TS 101862) TS 101862
>>>>>                 specified 2 alternative ways to declare a
>>>>>                 certificate as QC. 1) By inclusion of a
>>>>>                 QCStatements extension 2) By including a
>>>>>                 certificate policy identifying this property Even
>>>>>                 though solution number 1) is far easier to handle
>>>>>                 by applications, since they don't need to recognize
>>>>>                 specific QC Policies, ETSI didn't make solution 1)
>>>>>                 mandatory or even consider making it critical, due
>>>>>                 to lack of confidence that clients would widely
>>>>>                 deploy this solution. ETSI needed to define a
>>>>>                 solution that could work even if no one choose to
>>>>>                 implement the new extensions provided by RFC 3039.
>>>>>                 However, It is not feasible to keep clients updated
>>>>>                 over time with different QC policies and even those
>>>>>                 policies that are regarded standardized may be
>>>>>                 updated with change of OID as a result. It would be
>>>>>                 devastating if we can't update a QCP because that
>>>>>                 would force an OID update and that would render
>>>>>                 certificates useless because clients learned to
>>>>>                 recognize only the old OID. This would be to build
>>>>>                 in a new root certificate problem into the
>>>>>                 platforms. My observations is that times have
>>>>>                 changed. I have seen clear indications that market
>>>>>                 players want, and even require for interoperability
>>>>>                 reasons, that use QCStatements solution is made
>>>>>                 mandatory and maybe even critical for QC. Since
>>>>>                 both RFC 3039, and TS 101862 are up for revision,
>>>>>                 it is time to revisit this issue. I have some
>>>>>                 questions and proposals: - Is there any experiences
>>>>>                 of this issue outside of Europe. I.e. are there
>>>>>                 other legal systems that make use of the same
>>>>>                 declaration logic as the EU directive, where the
>>>>>                 RFC 3039 profile is used fully or partly as a
>>>>>                 solution to this issue? - I would suggest that the
>>>>>                 QCStatement mechanism is ought to be a mandatory
>>>>>                 tool to communicate a Qualified Status. The
>>>>>                 question is:     1) whether this will have enough
>>>>>                 implementation support to succeed?     2) whether
>>>>>                 is best specified in RFC 3039 or in local profiles
>>>>>                 (such as TS 101862)?     3) If there could be a
>>>>>                 clear context defined where criticality could be
>>>>>                 allowed or even required? I would really like
>>>>>                 feedback from practical experiences from this
>>>>>                 issue, as well as constructive proposals. /Stefan
>>>>>
>>>>>
>>>>>                 /Stefan
>>>>>
>>>>>                 _____________________________ Stefan Santesson, 
>>>>>                 Retrospekt AB http://www.retrospekt.com
>>>>>             <http://www.retrospekt.com/> [phone] 
>>>>
>>>>             _____________________________ Stefan Santesson, 
>>>>             Retrospekt AB http://www.retrospekt.com
>>>>         <http://www.retrospekt.com/> [phone] 
>>>
>>
>> _____________________________
>> Stefan Santesson,  Retrospekt AB
>> http://www.retrospekt.com <http://www.retrospekt.com/>
>> [phone] 
> 
> 
> _____________________________
> Stefan Santesson,  Retrospekt AB
> http://www.retrospekt.com <http://www.retrospekt.com/>
> [phone]
> 
> _____________________________
> Stefan Santesson,  Retrospekt AB
> http://www.retrospekt.com <http://www.retrospekt.com/>
> [phone]
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HF6jR12306 for ietf-pkix-bks; Mon, 17 Mar 2003 07:06:45 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HF6dg12297 for <[e-mail]>; Mon, 17 Mar 2003 07:06:41 -0800 (PST)
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA20588; Mon, 17 Mar 2003 16:08:52 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id PAA25143; Mon, 17 Mar 2003 15:02:29 +0100
Message-ID: <[e-mail]>
Date: Mon, 17 Mar 2003 16:06:08 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: pkix <[e-mail]>, Tim Polk <[e-mail]>
CC: Stephen Kent <[e-mail]>, Russ Housley <[e-mail]>, Steve Bellovin <[e-mail]>, Jeff Schiller <[e-mail]>
Subject: Key usage bits 0 and 1
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2HF6ig12303
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

To Tim Polk and the WG,

Sorry, this is a long e-mail.

On February 27, 2003, I sent the following message to the co-chairs:

****************************************************************************

Dear co-chairs,

In the light of a Defect Report (n° 299) addressed by ISO SC 6 in London,
I have noticed that a MAJOR change has been done between RFC 2459 and
RFC 3280 about the interpretation of the DS and the NR bits.

As far as I remember, I do not remember that this point has ever been
discussed or mentioned on the mailing list.

I will thus appreciate that you confirm this or point me about some e-mail 
exchanges where this point has been presented, explained and debated. 
Otherwise, to a summary of the changes that explains that point.

Thanks,

Denis

****************************************************************************

On the same day I received a response from Tim Polk:

****************************************************************************

Denis,

[Tim] I am sure it was discussed on the list.  I do not know when; it was 
some time ago.  I believe that change occurred early in son-of-2459.

[Denis] No. I still have most versions. The same text (identical to RFC 
2459) was present from version new-part1-00.doc till version 
new-part1-12.doc, this means between 29 October 1999 and 25 January 2002, 
i.e. during 15 months.

Then the change occured when the document was split into two parts and 
became new-part1-asn1-00.doc on 25 April 2002.

So if you want to look for discussions it may only be between January 2002 
and April 2002. I looked that time frame and there is not a single message 
on that topic.

I remember that we got the message: "no change" except a clean split between 
algorithms and the rest of the document.

So awaiting your own searches ... (...)

[Tim] (...) I cannot do any research on it today.  I will try to identify 
the version of the I-D where the change occurred and the discussion next 
week.  With a little luck, I will send you the reference(s) Tuesday or 
Wednesday.

If you need faster action, the messages should appear in the email archive. 
  That is a lot of mail to look through, though.

****************************************************************************

Then on March 12, 2003 I sent the following e-mail:

****************************************************************************

Dear co-chairs,

On Februray 27, I sent the following message to you:

==========================================================================
In the light of a Defect Report (n° 299) addressed by ISO SC 6 in London,
I have noticed that a MAJOR change has been done between RFC 2459 and
RFC 3280 about the interpretation of the DS and the NR bits.

As far as I remember, I do not remember that this point has ever been 
discussed or mentioned on the mailing list.

I will thus appreciate that you confirm this or point me about some e-mail 
exchanges where this point has been presented, explained and debated. 
Otherwise, to a summary of the changes that explains that point.
==========================================================================

On March 5, I send a remainder to both of you.

On March 11, I sent a second remainder to both of you.

I have received no response at all, since then.

This matter is very important for me, and thus I am awaiting a response 
BEFORE the PKIX meeting. This matter is also related to the proposed 
revision of RFC 3039, for which I am not convinced that a revision is needed.

This time I am copying Russ, as a co-editor of RFC 3280.
He might be able to provide a response.

I am also copying the two Security Area Directors.

Regards,

Denis

****************************************************************************

On May 15, 2002 I sent the following message to the list:

****************************************************************************

After taking a few days off, I have analyzed the storm of the e-mail
exchanges on that topic.

The core of the problem is that some people, by claiming requesting some
"clarifications" on these two bits, would like to change their semantics.

:-(

The roadmap provides a good summary of what happened in the past:

    (...) many discussions were needed to arrive at
    a common agreement on the meaning of the digitalSignature (DS bit)
    and nonRepudiation (NR bit) bits and when they should be set. The
    group quickly realized that key usage extension mixes services and
    mechanisms. The DS bit indicates a mechanism - a public key used to
    verify a digital signature. The NR bit indicates a service - a public
    key used to verify a digital signature and to provide a non-
    repudiation service. When trying to indicate when each bit should be
    indicated arguments were based on:

    The lifetime of the object being singed. Some felt that the DS bit
    should be set when the certificate is used to sign ephemeral objects
    (e.g., bind tokens) while the NR bit should be set for things that
    are survive longer (e.g., documents). Of course, the problem with
    this distinction to determine how long is the time period for
    ephemeral?

    A conscious act taken by the signer. Many felt that the NR bit should
    be set only when the subject has expressly acknowledged that they
    want to use the private key to sign an object. Signing a document say
    where there is a conscious decision by the subject would be
    appropriate for the key usage extension to contain NR, but when the
    key is used for authentication purposes, which can occur
    automatically and more frequently, the DS bit is more appropriate.

    The discussion also concluded that since some authentication schemes
    occur automatically, that the DS bit and NR bit should never be set
    together in the same certificate. Some agreed to the differentiation
    of the bits based on the time, but did not agree that the two could
    not be in the same key usage extension.

    The procedures followed by the CA. Some felt that NR bit was kind of
    'quality mark' indicating to the verifier that the verifier could be
    assured that the CA is implementing appropriate procedures for
    checking the subject's identity, performing certificate archival,
    etc. Other felt that it was not entirely the CAs job and that some
    other entity must be involved.

    In the end the WG agreed to a few things:

    - Provision of the service of non-repudiation requires more than a
      single bit set in a PKC. It requires an entire infrastructure of
      components to preserve for some period of time the keys, PKCs,
      revocation status, signed material, etc., as well as a trusted
      source of time. However, the nonRepudiation key usage bit is
      provided as an indicator that such keys could be used as a
      component of a system providing a non-repudiation service.

    - The certificate policy is the appropriate place to indicate the
      permitted combinations of key usages. That is, a policy may
      indicate that the DS and NR bits can not be set in the same
      certificate while another may say that the DS and NR bits can be
      set in the same certificate.

    [2459bis] includes new text indicating the above agreements.

In addition to these explanations I would like to quickly reply to Sharon to
say her that I disagree (as others) when she says that the only meaning of
the NR bit is to say that the CA has no knowledge of the value of the
private key. This would rule out CAs generating key pairs and would not be
backward compatible with the current meaning.

Now let us attempt to CLARIFY the meaning.

David Kemp offered good explanations on these two bits:

DS bit: the key is used to sign data, nonces or challenges that can be
verified in real-time (entity authentication and data origin authentication
services).

NR bit: the key is used to sign data that can be verified at a later time
(non–repudiation service).

I would offer these additional explanations:

When the DS bit (bit 0) is set, this means that the private key MAY have
been used in an environment that is not fully controlled by the private key
holder. In practice, this means that private keys related to certificates
that have the DS bit set, will be used for entity authentication (e.g.
signing challenges or nonces) or for data origin authentication (signing
data that has not necessarily been reviewed).

Since the environment is not fully controlled by the private key holder, the
private key holder COULD deny that his key was used to sign a transaction,
because he could claim that he was believing that his private key was used
in an authentication process.

Some authorities (like CRL Issuers) can sign by using a key related to a
certificate that only has the DS bit set because they always chose what they
sign and will never use that same key in an authentication exchange.

When the NR bit (bit 1) is set, this means that the private key holder will
only use its private key in an environment that he can control and which
allows him to be confident of the data that is being effectively signed.

The signer cannot claim that he was believing that his private key was
simply used in an authentication process that he could not control.

Denis

****************************************************************************
Now, I did a search in my archives and I have a file named: 
<draft-ietf-pkix-new-part1-12.txt> from January 2002.
It was recorded on January 25, 2002. It has the following text in it:

       The digitalSignature bit is asserted when the subject public key
       is used with a digital signature mechanism to support security
       services other than non-repudiation (bit 1), certificate signing
       (bit 5), or CRL signing (bit 6).  Digital signature mechanisms are
       often used for entity authentication and data origin
       authentication with integrity.

I have found an e-mail from the RFC editor dated from May 10, 2002:

That e-mail says:

A new Request for Comments is now available in online RFC libraries.

         RFC 3280

         Title:	    Internet X.509 Public Key Infrastructure
                     Certificate and Certificate Revocation List (CRL)
                     Profile
         Author(s):  R. Housley, W. Polk, W. Ford, D. Solo
         Status:	    Standards Track
	Date:       April 2002
         Mailbox:    [e-mail], [e-mail],
                     [e-mail], [e-mail]
         Pages:      129
         Characters: 295556
         Updates/Obsoletes/SeeAlso:    None

         I-D Tag:    draft-ietf-pkix-new-part1-12.txt

However, the file named draft-ietf-pkix-new-part1-12.txt
is faily different from draft-ietf-pkix-new-part1-12.txt
since the text above has been changed in the following way:

       The digitalSignature bit is asserted when the subject public key
       is used with a digital signature mechanism to support security
       services other than certificate signing (bit 5), or CRL signing
       (bit 6).  Digital signature mechanisms are often used for entity
       authentication and data origin authentication with integrity.


This is quite strange that two texts with the same name have different 
contents. Maybe the rfc-editor couild explain ?

****************************************************************************

I wanted to inform the list that I am still awaiting a response from Tim, as 
co-editor of RFC 3280 and as co-chair of the PKIX WG (the responses may be 
different).

For the time being, RFC 3280 is NOT backward compatible with RFC 2459 and is 
not compatible either with X.509.

I would like that point to be mentioned at the next PKIX WG meeting.

Regards,

Denis





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HDW2Z02135 for ietf-pkix-bks; Mon, 17 Mar 2003 05:32:02 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz ([130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HDW0g02126; Mon, 17 Mar 2003 05:32:00 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.8/8.12.8) with ESMTP id h2HDPQVV026520; Tue, 18 Mar 2003 01:25:26 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h2HDPQi17223; Tue, 18 Mar 2003 01:25:26 +1200
Date: Tue, 18 Mar 2003 01:25:26 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Recommendation on subject matching rules needed..
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Vainikainen Saku EINT" <[e-mail]> writes:

>Sounds good, but I suppose we still need to select the keys somehow
>(using the certs) through the CryptoAPI CSP and RSA CrypTokI interface,
>so that the applications are satisfied.

It looks like you've been painted into a corner by the selection of software
you have to use.  The solution using other software is fairly simple, but
if you're stuck with using CryptoAPI and have various other constraints I
don't really know what you could do, sorry.  I guess saying "Don't do that
then" isn't much help :-).

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HCJbf25462 for ietf-pkix-bks; Mon, 17 Mar 2003 04:19:37 -0800 (PST)
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HCJag25455 for <[e-mail]>; Mon, 17 Mar 2003 04:19:36 -0800 (PST)
Received: from chokhani (68.washington-14rh15rt.dc.dial-access.att.net[12.91.130.68]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <20030317121913112005iffpe>; Mon, 17 Mar 2003 12:19:13 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Will IDP syntax and semantics be changed in the future?
Date: Mon, 17 Mar 2003 07:19:36 -0500
Message-ID: <002f01c2ec7f$7a067340$d600a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
In-Reply-To: <000f01c2ead0$106ea8e0$4f85900a@wcwang>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2HCJag25456
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sharon:

I do not know if I have the answer to your question about how to do the
transition.  But, I note that following factors that should be considered in
making that determination.

1.  If a generator produces an IDP in accordance with the current syntax and
semantics, both processors (compliant with the current or compliant with the
proposed syntax and semantics) will process is correctly, except in one
case.  If the any subset (a set is also its own subset) of the three tags
([1], [2], [5]) is present and all values are set to false, neither the
current nor the proposed semantics clearly state if this is permitted and/or
what it covers.  That should be clarified in both the current and proposed
standard.  BTW, current X.509 Annex B and RFC 3280 Section 6.3.3 b (2) imply
that this CRL (meaning with any subset of the three tags present and set to
false) will cover all types of certificates issued by the CA.

2.  If a generator produces an IDP in accordance with the proposed syntax
and semantics, the proposal should state if the subset of all five ([1],
[2], [5], [6], [7]) tags are present and all set to false, and no tag is
present set to true, what the CRL covers or whether it is a valid CRL.

3. We all know that a processor compliant with current syntax and semantics
will have problems with the CRL generated using the proposed syntax and
semantics.  It might choke on tags [6] and/or [7].  It will reject a CRL
that is relevant since it may not like multiple of the tags set to true.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Wen-Cheng Wang
Sent: Saturday, March 15, 2003 3:51 AM
To: [e-mail]
Cc: [e-mail]; Sharon Boeyen
Subject: Re: Will IDP syntax and semantics be changed in the future?



Hi, David,

You wrote:
>
> I haven't had a chance to think about all of the possible consequences 
> of additional fields in the issuingDistributionPoint extension, but I 
> will try to address the comments below in light of the current PKIX 
> standards.
>
Actucally, the change of extending PMI-related fields to the IDP extension
is fine to me. I believe that the PMI-related field,
onlyContainsAttributeCerts, has not been widely used yet. Therefore, if you
want to extend it, please hurry up. It is better to be done before the PMI
is widely deployed. What I worry is that the remove of the adverb "only"
from some fields of the IDP extension. Especailly I am worrying about the
change of onlyContainsUserCerts and onlyContainsCACerts fields, which are
now widely use to distinguish CARL and EPRL. IMO, the remove of the adverb
"only" will introduce some conflicts with the original definition of the IDP
extension. See my comments below.


> These may be a problem, but if I understand correctly, it will not be 
> an issue if certificate issuers limit themselves to the features of 
> the PKIX profiles.
>
> First, PKIX does not include the SOAIdentifier extension.  If no 
> certificates are issued with the SOAIdentifier extension, it would 
> make no sense to have a CRL that only covered certificates that 
> include this extension.
>
> The PKIX attribute certificate profile, RFC 3281, discourages the use 
> of delegation.  If I understand correctly, conformance to this profile 
> would mean that there would be no AA certificates, only user attribute 
> certificates.  If this is the case, then the change from 
> onlyContainsAttributeCerts to containsUserAttributeCerts should not be 
> a problem since all attribute certificates are user attribute 
> certificates.
>
Extending PMI-related fields is fine for me. However, if the adverb "only"
is to be remove from onlyContainsAttributeCerts, the consequence of changing
the semantics should be also carefully evaluated.

I know that you do not agree that the remove of the adverb "only" will
change the semantics. However, please see my comments below.

>
> >In RFC 3280, the semantics of these flags is as follows:
> >1. The onlyContainUserCerts flag indicates "whether the CRL scope ONLY
> >    covers EE certificates".
> >2. The onlyContainsCACerts flag indicates "whether the CRL scope ONLY
> >    covers CA certificates".
> >However, in the new definition, the semantics of these flags is as
follows:
> >1. The containUserCerts flag indicates "whether the CRL scope covers EE
> >    certificates".
> >2. The containsCACerts flag indicates "whether the CRL scope covers CA
> >    certificates".
> >
> I believe you are misquoting TC3 to X.509. The text states:
>
>         If containsUserPublicKeyCerts is true, the CRL contains 
> revocations for end-entity public-key
>         certificates. If containsCACerts is true, the CRL contains 
> revocations for CA certificates.
>
I did not quote the text from TC3 to X.509, I just tried to state my
interpretation of it. Doesn't my interpretation agree with you? I said "In
the new definition, the containUserCerts flag indicates "whether the CRL
scope covers EE certificates", and the containsCACerts flag indicates
"whether the CRL scope covers CA certificates". Please note that I did not
say "ONLY" in my interpretation.

> The text above does not say what it means if these flags are false.  
> That is covered elsewhere and the text clearly states that if all of 
> the flags are false then all types of certificates are covered.
......
> As I stated above, this is not what TC3 states.  If all of the 
> contains... are false, then all types of certificates are covered just 
> as before.

I do not understand your logic. What kind of logic you are following?
Shouldn't it be the Boolean logic? Since I am a follower of the Boolean
logic, my interpretation is as follows.

Since

"If containsUserPublicKeyCerts is true, the CRL contains revocations for EE
public-key certificates." (That is what you said.)

Doesn't it imply that

"If containsUserPublicKeyCerts is fasle, the CRL DOES NOT contains
revocations for EE public-key certificates."

And since

"If containsCACerts is true, the CRL contains revocations for CA
certificates." (That is also what you said.)

Doesn't it imply that

"If containsCACerts is false, the CRL DOES NOT contains revocations for CA
certificates."

Now you are telling us that

"If containsUserPublicKeyCerts is fasle(the default), the CRL contains
revocations for EE public-key certificates."

and

"If containsCACerts is false(the default), the CRL contains revocations for
CA certificates."

Are you telling us that the Boolean logic does not apply to the X.509
standard?

In the original definition, the Boolean logic still works.

Since

"If onlyContainsUserCerts is true, the CRL ONLY contains revocations for EE
public-key certificates."

it implies that

"If onlyContainsUserPublicKeyCerts is false, the CRL does not ONLY contains
revocations for EE public-key certificates."

And since

"If onlyContainsCACerts is true, the CRL ONLY contains revocations for CA
certificates."

it implies that

"If onlyContainsCACerts is false, the CRL does not ONLY contains revocations
for CA certificates."

Therefore, if onlyContainsUserCerts and onlyContainsCACerts are both false,
the CRL does not ONLY contains revocations for end-entity public-key
certificates and does not ONLY contains revocations for CA certificates.

The interpretation of this is "if onlyContainsUserCerts and
onlyContainsCACerts are both false (the default), the CRL MAY contains
revocations for both EE and CA certificates". IMO, the interpretation is not
perfect, but it is acceptable.

Now you removed the adverb "only" from the definition, the story is
different.


>
> >However, I believe that the author of the prepublished X.509 TC 3 
> >also noticed the problem so that for maintaining back compatibility 
> >with RFC 3280 and the original X.509 standard, the prepublished X.509 
> >TC 3 specially specifies "if all these flags are absent, it indicates 
> >that the CRL scope covers both EE certificates and CA certificates".
> >
> Exactly, so there is no conflict.
>
> >Unfortunately, that is conflict with X.680 and X.690 standards. The 
> >ASN.1
rule is
> >"if the field has DEFAULT value and the field is absent, the DEFAULT 
> >value is applied to the field".
> >
> There is no conflict with X.680/X.690.  It has always been the case 
> for the IDP extension that if the value of one of the flags if FALSE 
> (the
> default) then it does not appear in the encoding.  TC3 does not
> contradict this.  TC3 states that if all of the values are FALSE, then
> it means that the CRL covers all types of certificates.  You are
> confusing the encoding of the values (if FALSE then absent as mandated
> by DER in X.690) with the semantics (meaning) of a particular value.
>
> TC3 states what it MEANS when all of the flags are set to false, X.690 
> states how to ENCODE these values.  The two are not related.
>
If we follow the Boolean logic, I believe that the X.509 encoding rule to
the default value really matters.

> >With the new definition of IDP extension, to indicate that the CRL 
> >scope covers both EE certificates and CA certificates, both flags 
> >need to be set to TRUE. However, the the original definition, the 
> >"onlyContainsUserCerts" flag and the "onlyContainsCACerts" flag 
> >cannot be both set to TRUE at the same time since they are exclusive 
> >to each other.
> >
> TC3 is very clear that one does not need to set both flags to TRUE.  
> If all flags are false then all types of certificates are covered. 
> While the TC3 does allow for more than one flag to be set, one should 
> continue for set all flags to false to indicate that all types of 
> certificates are covered.
>
Again, if we follow the Boolean logic, I believe that

"With the new definition of IDP extension, to indicate that the CRL scope
covers both EE certificates and CA certificates, both flags need to be set
to TRUE."

-----
Wen-Cheng Wang
Project Researcher
Telecommunication Laboratories
Chunghwa Telecom Co., Ltd




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2HBRj520469 for ietf-pkix-bks; Mon, 17 Mar 2003 03:27:45 -0800 (PST)
Received: from hotmail.com (f44.sea2.hotmail.com [207.68.165.44]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2HBRgg20463 for <[e-mail]>; Mon, 17 Mar 2003 03:27:42 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 17 Mar 2003 03:16:28 -0800
Received: from 217.29.140.15 by sea2fd.sea2.hotmail.msn.com with HTTP; Mon, 17 Mar 2003 11:16:28 GMT
X-Originating-IP: [217.29.140.15]
From: "Mohammad Awad" <[e-mail]>
To: [e-mail]
Subject: Re: Which Subject name type is more secure
Date: Mon, 17 Mar 2003 13:16:28 +0200
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 17 Mar 2003 11:16:28.0669 (UTC) FILETIME=[A7E1E2D0:01C2EC76]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Andres,
Thank you for this clarification.
Regarding the FQDN IDENTITY stealing and exploiting it in a real attack, 
have somebody heard about real incident reports?
Thanks in advance.






>From: "Anders Rundgren" <[e-mail]>
>To: "Mohammad Awad" <[e-mail]>
>Subject: Re: Which Subject name type is more secure
>Date: Mon, 17 Mar 2003 08:40:49 +0100
>
>Mohammad,
>If I were to do something like this I could think of using
>IP address for securing the _machine_.  I.e. you know that this
>message was sent from this machine.  To use IP addresses
>for humans is of course possible but
>at least I have never heard about such a system.  What is
>the intended application of IP-based identities for humans?
>e-mail is the cheapest possible way to create reasonable
>good links to a subject that also are fairly mobile and
>even globally unique.
>
>Anders
>
>----- Original Message -----
>From: "Mohammad Awad" <[e-mail]>
>To: <[e-mail]>
>Sent: Monday, March 17, 2003 08:13
>Subject: Re: Which Subject name type is more secure
>
>
>Andres,
>I think you made it clear now:
>1- that it's not so easy to gain both of the two advantages at a time. 
>I.e.,
>not always the selected identity which is portable, can provide a GOOD LINK
>to the machine at which the human works at.
>2- we can sort IDENTITY types in this order: (the first the more portable
>but the worse linking to the machine):
>   the (BIOMETRIC METHODS)  then  (FQDN)  then  (IP ADDRESS)
>But at sometimes when we can guarantee that our machine would be really
>fixed at a certain IP ADDRESS and that it is hosting a public service, may
>it be more suitable then to choose the (less portable but better linking)
>identity which is IP ADDRESS? or that is not a practical issue for another
>reason?
>Thanks in advance.
>Mohammad Awad.
>
>
>
>
>
>
>
>
> >From: "Anders Rundgren" <[e-mail]>
> >To: "Mohammad Awad" <[e-mail]>
> >Subject: Re: Which Subject name type is more secure
> >Date: Mon, 17 Mar 2003 06:23:08 +0100
> >
> >Mohammad,
> >I think I understand the scenario now.
> >It is during the registration process at a CA.
> >My only comment to this is that due to man-in-the-middle
> >attacks an attacker may be able to change user data
> >so that the CA issues an incorrect certficate if the subject
> >identity is given by the user.  But I don't think this is
> >typical as a CA should have an out-of-band way to
> >connect to the subject as well.  For high-value stuff
> >you may have to show up using a valid drivers license
> >etc.  For e-mail certificates you must have a proper
> >mail address.  I think that you could theoretically
> >fake e-mail by attacks in the CA end.
> >
> >To certify IP addresess is not very useful even if it gives
> >a good link to the user.  You probably want to use your
> >id on different places where you will have another IP.
> >
> >The only way ahead is better methods for binding the
> >subject to an identity and here you have national registries,
> >birth certificates, biometrics etc.  This is a weak link as
> >you have also found out.
> >
> >Anders
> >
> >----- Original Message -----
> >From: "Mohammad Awad" <[e-mail]>
> >To: <[e-mail]>
> >Sent: Sunday, March 16, 2003 22:34
> >Subject: Re: Which Subject name type is more secure
> >
> >
> >Andres,
> >Well, I think this is clear and no one can break the private key of the
> >entity. But the scenario I was talking about is an attacker succeeded to
> >spoof both the DNS and the certificate authority, no matter how, and
> >enrolled a certificate pretending that it is the entity having the 
>IDENTITY
> >abc.ABC.com of course with a private key generated for his own. Then in
> >this
> >scenario, I was asking do anybody agree with me that having the 
>certificate
> >registered with this IDENTITY which is an FQDN, could enable the attacker
> >to
> >perform a real security breach because it's harder to others to disclose
> >his
> >crime. On the other hand if the attacker also has spoofed the certificate
> >authority and enrolled a certificate but in this turn, having the subject
> >name being a forged IP address which the attacker intends to use in
> >attacking victims, I think it'll be harder for him to perform successful
> >breaches since any replies to that forged address that he will 
>impersonate,
> >would not really reach the attacker, but the genune machine.
> >So I was wondering whether it's more restrict for security to use IP
> >address
> >digital certificates rather than FQDN ones. Do anybody agree for that?
> >Thanks
> >Mohammad
> >
> >
> >
> >
> >
> >
> > >From: "Anders Rundgren" <[e-mail]>
> > >To: "Mohammad Awad" <[e-mail]>
> > >Subject: Re: Which Subject name type is more secure
> > >Date: Sun, 16 Mar 2003 12:10:41 +0100
> > >
> > >Mohammad,
> > >
> > >This is how I look on this:
> > >
> > >The security in PKI is assured by the use of the private key
> > >and nothing else.  Only the real subject have the proper private key.
> > >
> > >That is, using HTTPS/SSL client-authentication is consered as
> > >unbreakable.  Not even a man-in-the middle has a chance
> > >to impersonate a user.
> > >
> > >regards
> > >Anders
> > >
> > >----- Original Message -----
> > >From: "Mohammad Awad" <[e-mail]>
> > >To: <[e-mail]>
> > >Sent: Sunday, March 16, 2003 08:44
> > >Subject: Which Subject name type is more secure
> > >
> > >
> > >
> > >Hi All,
> > >I've a question regarding the usage of the X.509 certificate. What is
> > >considered more secure against the identity stealing threat, to have 
>the
> > >alternate subject name of the certificate registering the IP address of
> >the
> > >entity, or the FQDN name? I.e., which of those two (IP, FQDN) result in
> > >more
> > >dangerous security breach for when an attacker could steal them.
> > >My understanding is that whenever the attacker intend to steal a 
>victim's
> > >IP
> > >address, it never can exploit this incident by any gain beyond DoS,
> >because
> > >conceptually the attacker could never receive the packets targeted to 
>the
> > >stolen IP address. On the other hand, by spoofing the DNS system, the
> > >attacker is able to impersonate the victim's FQDN in both sending and
> > >receiving packets, so can perform a real security breach.
> > >Could any body kindly provide me with corrections for my understanding.
> > >Thank you all.
> > >Moham. Awad.
> > >
> > >
> > >
> > >
> > >
> > >_________________________________________________________________
> > >Help STOP SPAM with the new MSN 8 and get 2 months FREE*
> > >http://join.msn.com/?page=features/junkmail
> > >
> > >
> >
> >
> >_________________________________________________________________
> >The new MSN 8: advanced junk mail protection and 2 months FREE*
> >http://join.msn.com/?page=features/junkmail
> >
> >
>
>
>_________________________________________________________________
>The new MSN 8: smart spam protection and 2 months FREE*
>http://join.msn.com/?page=features/junkmail
>
>


_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2H4l7R11064 for ietf-pkix-bks; Sun, 16 Mar 2003 20:47:07 -0800 (PST)
Received: from mailgw2a.lmco.com (mailgw2a.lmco.com [192.91.147.7]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2H4l5g11060 for <[e-mail]>; Sun, 16 Mar 2003 20:47:05 -0800 (PST)
Received: from emss03g01.ems.lmco.com (emss03g01.ems.lmco.com [141.240.4.144]) by mailgw2a.lmco.com (8.11.6/8.11.6) with ESMTP id h2H4l8S11131 for <[e-mail]>; Sun, 16 Mar 2003 23:47:08 -0500 (EST)
Received: from CONVERSION-DAEMON.lmco.com by lmco.com (PMDF V6.1-1 #40646) id <[e-mail]> for [e-mail]; Sun, 16 Mar 2003 23:47:08 -0500 (EST)
Received: from EMSS03I00.us.lmco.com ([141.240.31.211]) by lmco.com (PMDF V6.1-1 #40646) with ESMTP id <[e-mail]> for [e-mail]; Sun, 16 Mar 2003 23:47:06 -0500 (EST)
Received: by EMSS03I00.us.lmco.com with Internet Mail Service (5.5.2653.19)	id <G7TN8S9F>; Sun, 16 Mar 2003 23:47:06 -0500
Content-return: allowed
Date: Sun, 16 Mar 2003 23:47:04 -0500
From: "Slone, Skip" <[e-mail]>
Subject: I-D draft-slone-ldap-x500-align-00.txt
To: "PKIX Mailing List ([e-mail])" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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>

FYI... Although most of this I-D pertains to the LDAP WGs, there are a
couple items that may be of interest to people in PKIX.  In particular, I
draw attention to sections 3.5 (;binary), 3.16 (string matching), and 3.19
(enhanced matching).

I will be at IETF 56, so if anyone wishes to talk to me one-on-one about
this, just let me know.

http://www.ietf.org/internet-drafts/draft-slone-ldap-x500-align-00.txt

This document is intended to provide information of interest to 
developers of Lightweight Directory Access Protocol (LDAP) 
specifications and products. It is intended to provide background 
information and to facilitate discussion within IETF Working Groups, 
most notably LDAPbis. This Internet-Draft highlights decisions made 
by group attending the ITU-T and ISO/IEC JTC1 Collaborative Meeting 
on the Directory in London in February 2003 for inclusion in an 
upcoming Proposed Draft Amendment (PDAM) to the ITU-T X.500 / IS 
9594 Specification. It also identifies issues that the X.500 group 
would like to bring to the attention of the LDAPbis Working Group at 
the upcoming IETF meeting in March. 

Regards,

-- Skip Slone


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2G7irY21838 for ietf-pkix-bks; Sat, 15 Mar 2003 23:44:53 -0800 (PST)
Received: from hotmail.com (f29.sea2.hotmail.com [207.68.165.29]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2G7iqg21831 for <[e-mail]>; Sat, 15 Mar 2003 23:44:52 -0800 (PST)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 15 Mar 2003 23:44:47 -0800
Received: from 217.29.140.15 by sea2fd.sea2.hotmail.msn.com with HTTP; Sun, 16 Mar 2003 07:44:46 GMT
X-Originating-IP: [217.29.140.15]
From: "Mohammad Awad" <[e-mail]>
To: [e-mail]
Subject: Which Subject name type is more secure
Date: Sun, 16 Mar 2003 09:44:46 +0200
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 16 Mar 2003 07:44:47.0183 (UTC) FILETIME=[EACB2DF0:01C2EB8F]
Sender: [e-mail]
Precedence: 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 All,
I've a question regarding the usage of the X.509 certificate. What is 
considered more secure against the identity stealing threat, to have the 
alternate subject name of the certificate registering the IP address of the 
entity, or the FQDN name? I.e., which of those two (IP, FQDN) result in more 
dangerous security breach for when an attacker could steal them.
My understanding is that whenever the attacker intend to steal a victim's IP 
address, it never can exploit this incident by any gain beyond DoS, because 
conceptually the attacker could never receive the packets targeted to the 
stolen IP address. On the other hand, by spoofing the DNS system, the 
attacker is able to impersonate the victim's FQDN in both sending and 
receiving packets, so can perform a real security breach.
Could any body kindly provide me with corrections for my understanding.
Thank you all.
Moham. Awad.





_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2FFCFO12788 for ietf-pkix-bks; Sat, 15 Mar 2003 07:12:15 -0800 (PST)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2FFCCg12783 for <[e-mail]>; Sat, 15 Mar 2003 07:12:12 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maild.telia.com (8.12.8/8.12.8) with SMTP id h2FFC86u004978; Sat, 15 Mar 2003 16:12:08 +0100 (CET)
Message-ID: <007001c2eb03$bcc28890$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Al Arsenault" <[e-mail]>
Cc: <[e-mail]>, "Santosh Chokhani" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <006601c2e85f$69053000$0500a8c0@arport> <[e-mail]> <008501c2e92e$d5de5380$0500a8c0@arport> <[e-mail]> <005301c2ea0f$6c402f70$0500a8c0@arport> <03cb01c2ea77$92d69760$6501a8c0@SJOSEPH>
Subject: Re: Certificate Policies - Standardization of
Date: Sat, 15 Mar 2003 16:01:19 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al,
My intention was to put this thread to rest a while but since you are
new in this discussion I make an exception :-)

The problem is that since DoD (as you say) believe they have
"unique" requirements, they are in the same league as the EU, 
the banks, the health-care sector etc etc.

Therefore there will never be a standard but a lot of profiles.
In my opinion this makes policy extensions less suitable as a
universal method for automatic decisions on trust, selection etc.

I.e. DoD may claim they are following a "standard" but from
a pragmatic point of view their system may be classified as
"proprietary", as well as likely to work badly when the DoD
is to communicate digitally with the outside world.

In addition to various organizations' claim of having "unique"
requirements, the number #1 problem is to identify a subject
in a cost-efficient and trustworthy way and then assign an 
electronic identity to it.  Since countries like the USA don't
have a working "registry", biometric methods are still in
their infancy, and there exist no generally accepted way to
name people, I don't think even a minimal technical foundation
is in place to support globally standardized policies.

I have had some contacts with US e-government reps. who still
don't seem to have a clue on how to name citizens.  This
contrasts a bit to the Swedish system which was established
some 40 years ago and PKI-fied since at least 7-8 years back.

In the mean-time (next 5-10 years) most organizations will probably
rely on the de-facto standard (CA <==> Policy), which unfortunately
makes an already unlikely future policy-based standard, even harder
to deploy.

OTOH: Shouldn't RPs be the prime target for PKI improvements
rather than CAs?  But for RPs the de-facto standard is simpler to get
a grip on than introducing yet another dimension.

To further complicate things, many of us also have "vested interests"
in certain designs and associated customers.  F.Y.I.  I can tell you,
that I am actively working on a PKI-scheme where the CA is a core
PKI-object holding policy, logotype, name-space declarations, and
a liability statement.  The point with this is to convert PKI into
self-describing objects, aligning  better to the solutions and standards
used in other IT-segments.  This scheme is explicitly designed to allow
run-time interpretation as well as supporting administrators during
CA trust decision processes.  To make this reasonable possible to
ever rollout (my main concern regarding any system, standard etc),
the proposed scheme is upwardly compatible with the de-facto standard,
effectively only converting some data from being "implicit" ("known")
to become "explicit".

Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2FDHQY04402 for ietf-pkix-bks; Sat, 15 Mar 2003 05:17:26 -0800 (PST)
Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2FDHOg04398 for <[e-mail]>; Sat, 15 Mar 2003 05:17:24 -0800 (PST)
Received: from free.fr (79.130.62.62.9velizy1-0-ro-as-i1-1.9tel.net [62.62.130.79]) by ioskeha.hittite.isp.9tel.net (Postfix) with ESMTP id 3CAE217B4E1 for <[e-mail]>; Sat, 15 Mar 2003 14:18:02 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 15 Mar 2003 14:19:11 +0100
From: Jean-Marc Desperrier <[e-mail]>
Organization: totalement desorganise
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030129
X-Accept-Language: en-us, en, fr, fr-fr, ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: draft-ietf-pkix-rfc2510bis-07.txt : IAK(Initial Authentication Key)
References: <008501c2e926$6a1ab740$aa0310ac@foreverkhopri>
In-Reply-To: <008501c2e926$6a1ab740$aa0310ac@foreverkhopri>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jong-Wook, Park wrote:

>[...] It is RECOMMENDED that the shared
>   secret be at least 12 characters long.
>
>But it doesn't tell how 12 characters long comes out.
>
I don't know the exact values on which the decision was based, but it 
comes from the conjunction of two elements.
- How long a symetric key should be to be considered secure?
- What is the entropy of the characters of the shared secret ?

The strongest challenge publicly resolved until now was to break a 64 
bits long RC5 key.
So to be secure a key must be longer than this.

The entropy of the character of the shared secret is a mesure of how 
much randomness each character brings.

The text uses the word character, not byte for the length of the shared 
secret.
I think this means it is expected that the shared secret being 
transported out of band will very often not be constituted of binary 
data, but of characters that can be spelled out or typed on a keyboard, 
just like a password and easily exchanged in a physical or voice contact 
between two people.

This means the randomness will be reduced a lot compared to a possible 
maximum of 8 bits per byte.

I don't know here how exactly the value for entropy was determined.

But a convenient rule of thumb is at most 6 bit of randomnes per character.
This comes from the fact Base64 encoding is able to encode 6 bit of data 
par character.
So if you generate a random value, encode it in base 64, you can easily 
use it as a password and each character will bring 6 bits of randomness.
Base 64 uses all aphabetic characters, upper and lower case, the digit 
character and a few more to get to 64 characters.
They are relatively easy to type or spell out.

You could use a few more characters than that, that can be typed and 
spelled out, but not very much, so it would not make a big difference.
And for each character to really bring 6 bit of randomness, therer must 
be no correlation between characters, no character that appears more 
often than another.
This means that even the best choosen shared secret will not bring much 
more than 6 bit of randomness per byte, and usually a lot less, because 
if the shared secret is created like a password, it's difficult to mix 
upper case/lower case/digit perfectly, and you could also be tempted to 
use dictionnary words, or words you can pronounce with reduces the 
randomness too.

With 6 bit par character, 12 characters make a 72 bit long key, which is 
not a very big security margin from 64 bits.
So as I said I don't know exactly how the value was determined but with 
rules of thumb, it's not very difficult to estimate it is indeed a 
minimum for a real security against brute force attacks.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2F8pd510201 for ietf-pkix-bks; Sat, 15 Mar 2003 00:51:39 -0800 (PST)
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2F8pbg10193 for <[e-mail]>; Sat, 15 Mar 2003 00:51:37 -0800 (PST)
Received: from ms.chttl.com.tw (ms5 [10.144.2.115]) by fw.chttl.com.tw (8.12.8/8.11.6) with ESMTP id h2F8pBMM013367; Sat, 15 Mar 2003 16:51:11 +0800 (CST)
Received: (from root@localhost) by ms.chttl.com.tw (8.11.6/8.11.6) id h2F8oin32360; Sat, 15 Mar 2003 16:50:44 +0800
Received: from wcwang ([10.144.133.79]) by ms.chttl.com.tw (8.11.6/8.11.6) with SMTP id h2F8oie32322; Sat, 15 Mar 2003 16:50:44 +0800
Message-ID: <000f01c2ead0$106ea8e0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>, "Sharon Boeyen" <[e-mail]>
References: <008501c2e977$8e8535f0$4f85900a@wcwang> <[e-mail]>
Subject: Re: Will IDP syntax and semantics be changed in the future?
Date: Sat, 15 Mar 2003 16:51:25 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi, David,

You wrote:
>
> I haven't had a chance to think about all of the possible consequences
> of additional fields in the issuingDistributionPoint extension, but I
> will try to address the comments below in light of the current PKIX
> standards.
>
Actucally, the change of extending PMI-related fields to the IDP
extension is fine to me. I believe that the PMI-related field,
onlyContainsAttributeCerts, has not been widely
used yet. Therefore, if you want to extend it, please hurry up. It is better
to be done before the PMI is widely deployed. What I worry is that the
remove of the adverb "only" from some fields of the IDP extension.
Especailly I am worrying about the change of onlyContainsUserCerts and
onlyContainsCACerts fields, which are now widely use to distinguish CARL
and EPRL. IMO, the remove of the adverb "only" will introduce some conflicts
with the original definition of the IDP extension. See my comments below.


> These may be a problem, but if I understand correctly, it will not be an
> issue if certificate issuers limit themselves to the features of the
> PKIX profiles.
>
> First, PKIX does not include the SOAIdentifier extension.  If no
> certificates are issued with the SOAIdentifier extension, it would make
> no sense to have a CRL that only covered certificates that include this
> extension.
>
> The PKIX attribute certificate profile, RFC 3281, discourages the use of
> delegation.  If I understand correctly, conformance to this profile
> would mean that there would be no AA certificates, only user attribute
> certificates.  If this is the case, then the change from
> onlyContainsAttributeCerts to containsUserAttributeCerts should not be a
> problem since all attribute certificates are user attribute certificates.
>
Extending PMI-related fields is fine for me. However, if the adverb "only"
is to
be remove from onlyContainsAttributeCerts, the consequence of changing the
semantics should be also carefully evaluated.

I know that you do not agree that the remove of the adverb "only" will
change
the semantics. However, please see my comments below.

>
> >In RFC 3280, the semantics of these flags is as follows:
> >1. The onlyContainUserCerts flag indicates "whether the CRL scope ONLY
> >    covers EE certificates".
> >2. The onlyContainsCACerts flag indicates "whether the CRL scope ONLY
> >    covers CA certificates".
> >However, in the new definition, the semantics of these flags is as
follows:
> >1. The containUserCerts flag indicates "whether the CRL scope covers EE
> >    certificates".
> >2. The containsCACerts flag indicates "whether the CRL scope covers CA
> >    certificates".
> >
> I believe you are misquoting TC3 to X.509. The text states:
>
>         If containsUserPublicKeyCerts is true, the CRL contains
> revocations for end-entity public-key
>         certificates. If containsCACerts is true, the CRL contains
> revocations for CA certificates.
>
I did not quote the text from TC3 to X.509, I just tried to state my
interpretation of it.
Doesn't my interpretation agree with you? I said "In the new definition, the
containUserCerts flag indicates "whether the CRL scope covers EE
certificates",
and the containsCACerts flag indicates "whether the CRL scope covers CA
certificates".
Please note that I did not say "ONLY" in my interpretation.

> The text above does not say what it means if these flags are false.
>  That is covered elsewhere and the text clearly states that if all of
> the flags are false then all types of certificates are covered.
......
> As I stated above, this is not what TC3 states.  If all of the
> contains... are false, then all types of certificates are covered just
> as before.

I do not understand your logic. What kind of logic you are following?
Shouldn't it be
the Boolean logic? Since I am a follower of the Boolean logic, my
interpretation is as
follows.

Since

"If containsUserPublicKeyCerts is true, the CRL contains revocations for EE
public-key
certificates." (That is what you said.)

Doesn't it imply that

"If containsUserPublicKeyCerts is fasle, the CRL DOES NOT contains
revocations for EE
public-key certificates."

And since

"If containsCACerts is true, the CRL contains revocations for CA
certificates."
(That is also what you said.)

Doesn't it imply that

"If containsCACerts is false, the CRL DOES NOT contains revocations for CA
certificates."

Now you are telling us that

"If containsUserPublicKeyCerts is fasle(the default), the CRL contains
revocations for EE
public-key certificates."

and

"If containsCACerts is false(the default), the CRL contains revocations for
CA certificates."

Are you telling us that the Boolean logic does not apply to the X.509
standard?

In the original definition, the Boolean logic still works.

Since

"If onlyContainsUserCerts is true, the CRL ONLY contains revocations for EE
public-key
certificates."

it implies that

"If onlyContainsUserPublicKeyCerts is false, the CRL does not ONLY contains
revocations
for EE public-key certificates."

And since

"If onlyContainsCACerts is true, the CRL ONLY contains revocations for CA
certificates."

it implies that

"If onlyContainsCACerts is false, the CRL does not ONLY contains revocations
for CA
certificates."

Therefore, if onlyContainsUserCerts and onlyContainsCACerts are both false,
the CRL does
not ONLY contains revocations for end-entity public-key certificates and
does not ONLY
contains revocations for CA certificates.

The interpretation of this is "if onlyContainsUserCerts and
onlyContainsCACerts are both false
(the default), the CRL MAY contains revocations for both EE and CA
certificates". IMO, the
interpretation is not perfect, but it is acceptable.

Now you removed the adverb "only" from the definition, the story is
different.


>
> >However, I believe that the author of the prepublished X.509 TC 3
> >also noticed the problem so that for maintaining back compatibility with
> >RFC 3280 and the original X.509 standard, the prepublished X.509 TC 3
> >specially specifies "if all these flags are absent, it indicates that the
> >CRL scope covers both EE certificates and CA certificates".
> >
> Exactly, so there is no conflict.
>
> >Unfortunately, that is conflict with X.680 and X.690 standards. The ASN.1
rule is
> >"if the field has DEFAULT value and the field is absent, the DEFAULT
> >value is applied to the field".
> >
> There is no conflict with X.680/X.690.  It has always been the case for
> the IDP extension that if the value of one of the flags if FALSE (the
> default) then it does not appear in the encoding.  TC3 does not
> contradict this.  TC3 states that if all of the values are FALSE, then
> it means that the CRL covers all types of certificates.  You are
> confusing the encoding of the values (if FALSE then absent as mandated
> by DER in X.690) with the semantics (meaning) of a particular value.
>
> TC3 states what it MEANS when all of the flags are set to false, X.690
> states how to ENCODE these values.  The two are not related.
>
If we follow the Boolean logic, I believe that the X.509 encoding rule to
the
default value really matters.

> >With the new definition of IDP extension, to indicate that the CRL
> >scope covers both EE certificates and CA certificates, both flags
> >need to be set to TRUE. However, the the original definition, the
> >"onlyContainsUserCerts" flag and the "onlyContainsCACerts" flag cannot be
> >both set to TRUE at the same time since they are exclusive to each other.
> >
> TC3 is very clear that one does not need to set both flags to TRUE.  If
> all flags are false then all types of certificates are covered. While
> the TC3 does allow for more than one flag to be set, one should continue
> for set all flags to false to indicate that all types of certificates
> are covered.
>
Again, if we follow the Boolean logic, I believe that

"With the new definition of IDP extension, to indicate that the CRL scope
covers
both EE certificates and CA certificates, both flags need to be set to
TRUE."

-----
Wen-Cheng Wang
Project Researcher
Telecommunication Laboratories
Chunghwa Telecom Co., Ltd




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2F06Rh14553 for ietf-pkix-bks; Fri, 14 Mar 2003 16:06:27 -0800 (PST)
Received: from smtp22.kolumbus.fi (smtp22.kolumbus.fi [193.229.0.82]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2F06Pg14549 for <[e-mail]>; Fri, 14 Mar 2003 16:06:25 -0800 (PST)
Received: from dom1-cn2-hki.dom1.epnet (dom1-cn2-hki.dom1.epnet [172.21.176.74]) by smtp22.kolumbus.fi (8.12.8/8.12.4) with ESMTP id h2F06LI3018492 for <[e-mail]>; Sat, 15 Mar 2003 02:06:21 +0200 (EET)
Received: from dom1-mb1-hki.dom1.epnet ([172.21.176.65]) by dom1-cn2-hki.dom1.epnet with Microsoft SMTPSVC(5.0.2195.5329); Sat, 15 Mar 2003 02:06:19 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Recommendation on subject matching rules needed..
Date: Sat, 15 Mar 2003 02:06:18 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Recommendation on subject matching rules needed..
Thread-Index: AcLqWUyhNqBQ3w5USkaZIfDXHRt3IAAKZUrgAADmmbA=
From: "Vainikainen Saku EINT" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 15 Mar 2003 00:06:19.0194 (UTC) FILETIME=[B45769A0:01C2EA86]
X-MailScanner: Found to be clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2F06Qg14550
Sender: [e-mail]
Precedence: 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 question is: Why is a *cert* being used for *personal*
> file protection (i.e., "from/to self", as opposed to 
> protection of the file when it is communicated from one 
> entity to another)?  It would seem that certs are the wrong 
> tool for this job.  *Bare* keys (keypairs or secret keys, 
> perhaps derived from a passphrase) seem to be the right tool.
>
> ...
>
> All-in-all, it seems that a better solution would be to store
> a bare secret key on the smartcard and use that to protect 
> his files, doesn't it?

Yes - this sounds reasonable when the same person is always encrypting
and decrypting the file, but the disk/folder/file encryption systems
need multi-user capabilities, ie. more than one person is required to
access the encrypted file.

If you use secret keys to encrypt the data for let's say 20 persons,
your data bloats 20-fold, or of course you could generate a session key
for bulk encryption of the data and just use personal secret keys to
encrypt that key for each user. You still have to somehow identify the
"legal" users of the encrypted disk/folder/file, instead of
trial-and-error decryption. What better way to do this than
certificates.. ?

This applies to hybrid encryption also: bare keypairs are not enough
since trial-and-error decryption is resource consuming, thus not wise.

Of course one could insert some checksums or whatever constant data to
the first encrypted block to make the trial-and-error decryption faster,
but this would also introduce a good way for a brute force key quesser
to figure out the secret key.. No good.

And passphrases still need to be broadcast/transmitted to and remembered
by all users, and it is not wise to use the same passphrase for all
encrypted data, so they are no good.

Saku.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ENlYJ13755 for ietf-pkix-bks; Fri, 14 Mar 2003 15:47:34 -0800 (PST)
Received: from vmmr9.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ENlWg13750 for <[e-mail]>; Fri, 14 Mar 2003 15:47:32 -0800 (PST)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr9.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id PCJ64117; Fri, 14 Mar 2003 18:47:32 -0500 (EST)
Received: from laptop-cpq.retrospekt.com (1Cust67.tnt4.stk3.swe.da.uu.net [213.116.231.67]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ACA16188 (AUTH [e-mail]); Fri, 14 Mar 2003 18:47:26 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Sat, 15 Mar 2003 00:46:20 +0100
To: Sharon Boeyen <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: RE: QC Declaration
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_83288081==.ALT"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Sharon and all,

I've heard many answers but the questions that needs them has not yet ben 
formulated.

Lets get back to this issue and do that.

Facts:

1) Current definition of the qcStatements ext says that if the extension is 
critical then all statements are critical.

2) It is compliant with X.509 to state that if an extension is critical, it 
is OK to recognize at least 1 of the contained elements. It is however 
unlikely that this is a good solution for the qcStatements extension, due 
to legacy and the different nature of different statements.

3) If one would set this extension as critical, it is likely that many 
applications would reject the certificate. This could be true also over 
time in the future since many local statement could be defined that would 
not be supported by clients in general.

Questions:

a) Is there any case/context where fact 3 actually is not a problem, but 
rather a feature?

b) could any such context be clearly defined and included in RFC 3039bis or 
any local standard?


Answers:

Question a)
Yes there has been situations raised where fact 3 actually could be a feature.

Many has complained about the problem to isolate a particular certificate 
for use in only electronic signature applications where the content is 
clearly presented and accepted by the signer prior to signing. The key 
usage or extended key usage extensions are not ready to provide this 
functionality. At least not today.

So, given that we would have a certificate that we WANT applications in 
general to reject it. A certificate that we only want those applications 
that are trained and designed to accept it,  to actually accept it. Then 
this could in fact be a great feature.

It could be the mechanism that would force all low grade applications to 
reject its use, and thus increase its evidence value when it is used.


b) It is true that the case described in answer a) does not apply to all 
certificates. But given that there are cases where it is of great value to 
isolate certificates use to informed applications. Then it might as well be 
worth the effort to try to formulate one or some clear contexts where 
setting the extension critical ought to be mandatory OR at least recommended.


Opinions:

My opinion is that it is our responsibility to look seriously into this 
issue with open minds before we reach a definitive conclusion to answer b). 
Personally I do believe we have a chance to contribute in a good way to 
supporting good use and acceptance of electronic signatures and believe 
that such context could and should be formulated.


/Stefan





At 15:19 2003-03-12 -0500, Sharon Boeyen wrote:
>It would have been compliant IF the semantics of the extension stated 
>that. However, the semantics of the extension dictate the opposite where 
>ALL statements are critical.
>-----Original Message-----
>From: Stefan Santesson [mailto:[e-mail]]
>Sent: Tuesday, March 11, 2003 4:49 PM
>To: Sharon Boeyen; [e-mail]
>Subject: RE: QC Declaration
>
>Sharon,
>
>The first step for me is to get the mechanics right.
>
>Are you saying that it would have been compliant with X.509 to declare 
>that a critical QCStatement (disregarding the current declaration in RFC 
>3039) is valid if I can process at least one of the present statements 
>(similar to SubjectAltName).
>
>Not that I claim that it would be a good idea.
>
>/Stefan
>
>
>At 16:30 2003-03-11 -0500, Sharon Boeyen wrote:
>>I don't want to get off on a non-relevant tangent regarding criticality, 
>>but think I do need to clarify a little bit on the subject Alt Name 
>>extension. If you check 8.3.2.3 (509) you'll find that the semantics of 
>>that extension are such that, if set to critical, "at least one of the 
>>name forms that is present shall be recognized and processed ...". So if, 
>>in your example, the ONLY name present in subjectAltName extension is the 
>>unknown otherName OID, then you are correct and the certificate shall be 
>>considered invalid. If however, that unknown otherName OID was present 
>>AND and rfc822Name was present - the RP might understand the rfc822Name 
>>and check it against the intended recipient of an encrypted email for 
>>example, and under those circumstances the certificate would be valid, 
>>even though the extension was critical and there was another nameform in 
>>there that was not understood.
>>
>>I suspect that its probably a bit too soon to profile the kind of 
>>contexts I think you're describing in 3039. I'd prefer to see a bit more 
>>practical use of QCs first so that we have a better handle on what 
>>constitutes a "context". For example, perhaps one context is with the 
>>ETSI qcstatement 1 plus a specific national qc statement and if both are 
>>present in a certificate that some 'authority' (I don't mean a CA here) 
>>deems that when that combination is present the extension shall be set to 
>>critical. I'm not necessarily opposing the idea, just a little 
>>uncomfortable with the proposed timing without significant real world 
>>deployment to guide us with to the appropriate 'contexts'.
>>
>>Cheers,
>>Sharon
>>-----Original Message-----
>>From: Stefan Santesson [mailto:[e-mail]]
>>Sent: Tuesday, March 11, 2003 4:06 PM
>>To: Sharon Boeyen; Sharon Boeyen; [e-mail]
>>Subject: RE: QC Declaration
>>
>>Sharon,
>>Thanks for the clarification.
>>"Elements of the syntax" really clarifies things.
>>So it is OK to accept an certificate with a critical policy extension 
>>containing an policy OID that I don't recognize, because it doesn't 
>>define any further syntax of the extension.
>>The same goes with Extended key usage OIDs.
>>However. It would not be OK with a critical subjectAltName containing an 
>>unknown other name OID, since this OID would define further syntax.
>>By the same reason I would need to understand all present QCStatements 
>>OIDs, because they do the same (define further syntax).
>>Let me clarify that I never proposed that the QCStatement must be 
>>critical in all certificates.
>>I'm just recognizing that it might be a valuable practice within certain 
>>contexts and the fact that some implementers actually ask for it.
>>The question is whether any of those contexts can be identified within 
>>RFC 3039, or if they are better placed in local sub-profiles (Such as 
>>ETSI TS 101862), or if they don't exist in a way that can be standardized 
>>in a meaningful way.
>>
>>/Stefan
>>
>>At 11:37 2003-03-11 -0500, Sharon Boeyen wrote:
>>>Hi Stefan,
>>>
>>>Remember first that RFC 3280 is a "profile" of X.509 and it does not 
>>>replace the requirements of 509, but rather profiles them to a subset.
>>>
>>>X.509 in clause 7 allows unknown elements in non-critical extensions 
>>>only to be ignored. However, that is more with respect to the elements 
>>>in the syntax
>>>itself (for example in the IDP extension no RP is allowed to ignore the 
>>>"onlySomeReasons" element if it is present in the extension because the 
>>>extension
>>>can only be critical. The behaviour of RPs will differ however depending 
>>>on their specific capability with respect to that element (some will use 
>>>the CRL for
>>>the specified reasons and others will seek a different CRL that covers 
>>>all reasons), however, no RP is permitted to simply ignore the flag. 
>>>Note also that in that
>>>same clause, for extensions that can be marked critical or non-critical, 
>>>a system that understands the extension is required to process it 
>>>regardless of the
>>>value of the criticality flag. It is ONLY systems that do not understand 
>>>an extension that can ignore it completely if it is marked non-critical.
>>>
>>>For the QC Statements extension, RFC 3039 says "This extension may be 
>>>critical or non-critical.  If the extension is critical, this means that 
>>>all statements
>>>included in the extension are regarded as critical. "
>>>
>>>Because of the semantics defined for the extension in RFC 3039, marking 
>>>it critical would result in the problems I raised.
>>>
>>>-----Original Message-----
>>>From: Stefan Santesson [mailto:[e-mail]]
>>>Sent: Tuesday, March 11, 2003 11:23 AM
>>>To: Sharon Boeyen; [e-mail]
>>>Subject: RE: QC Declaration
>>>
>>>Hi Sharon,
>>>My interpretation of criticality does not really match yours.
>>>The only guidance on the meaning of criticality in RFC 3280 (section 
>>>4.2) that I can find is:
>>>
>>>
>>>
>>>
>>>   "A certificate using system MUST reject the
>>>
>>>
>>>certificate
>>>
>>>
>>>
>>>if it encounters a critical extension it does not recognize"
>>>
>>>My interpretation is that it is OK to accept a certificate if you 
>>>recognize the extension as such. You don't need to understand ALL 
>>>information that the extension contains.
>>>It seam vital to agree on this issue before we can make any conclusion 
>>>on QCStatament criticality.
>>>/Stefan
>>>At 10:56 2003-03-11 -0500, Sharon Boeyen wrote:
>>>>Hi Stefan,
>>>>While I believe that in the longer term certificate policies will be the
>>>>optimum
>>>>way to convey the necessary information, I acknowledge that QC 
>>>>Statements is
>>>>the
>>>>more popular scheme at present. Therefore I wouldn't have any problem 
>>>>should
>>>>this
>>>>extension be mandated in RFC 3039.
>>>>However, forcing its criticality is going too far I believe. There is an
>>>>important
>>>>difference between critical and non-critical extensions that we need to 
>>>>keep
>>>>in
>>>>mind from the relying party's perspective. If there is a non-critical
>>>>extension that
>>>>the RP understands, but that extension includes some elements that it does
>>>>not, then
>>>>the RP is free to process the parts it does understand and ignore 
>>>>others. If
>>>>an extension
>>>>is critical however, the RP is required to understand ALL elements within
>>>>the extension.
>>>>Where I think this can become a problem is the content of the QC 
>>>>Statements
>>>>extension. Note
>>>>that RFC 3039 and the ETSI profile define DIFFERENT statements for 
>>>>inclusion
>>>>in the extension.
>>>>Also additional profiles may add their own local statements and even
>>>>narrower statements can
>>>>get added in specific deployment environments. While the cert issuer may
>>>>want to include many
>>>>of these statements to enable the cert to be used in various environments,
>>>>the RP should only
>>>>be required to understand and process the statements that are 
>>>>appropriate to
>>>>its own
>>>>operating environment as dictated by its local security policy (which 
>>>>could
>>>>be different than
>>>>that under which the CA operated). Therefore I think requiring it to be
>>>>critical is risky.
>>>>Also requiring that it always be critical would have interop/backward
>>>>compatibility issues.
>>>>Cheers,
>>>>Sharon
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: Stefan Santesson [mailto:[e-mail]]
>>>>Sent: Tuesday, March 11, 2003 8:27 AM
>>>>To: [e-mail]
>>>>Subject: QC Declaration
>>>>
>>>>The EU directive introduced a requirement on each CA, issuing QC 
>>>>(Qualified
>>>>Certificates), to clearly indicate in these certificate that they are
>>>>issued as QC.
>>>>ETSI implemented RFC 3039 in relation to the European electronic signature
>>>>directive through their Technical Standard (TS 101862)
>>>>TS 101862 specified 2 alternative ways to declare a certificate as QC.
>>>>1) By inclusion of a QCStatements extension
>>>>2) By including a certificate policy identifying this property
>>>>Even though solution number 1) is far easier to handle by applications,
>>>>since they don't need to recognize specific QC Policies, ETSI didn't make
>>>>solution 1) mandatory or even consider making it critical, due to lack of
>>>>confidence that clients would widely deploy this solution. ETSI needed to
>>>>define a solution that could work even if no one choose to implement the
>>>>new extensions provided by RFC 3039.
>>>>However, It is not feasible to keep clients updated over time with
>>>>different QC policies and even those policies that are regarded
>>>>standardized may be updated with change of OID as a result. It would be
>>>>devastating if we can't update a QCP because that would force an OID 
>>>>update
>>>>and that would render certificates useless because clients learned to
>>>>recognize only the old OID. This would be to build in a new root
>>>>certificate problem into the platforms.
>>>>My observations is that times have changed. I have seen clear indications
>>>>that market players want, and even require for interoperability reasons,
>>>>that use QCStatements solution is made mandatory and maybe even critical
>>>>for QC.
>>>>Since both RFC 3039, and TS 101862 are up for revision, it is time to
>>>>revisit this issue.
>>>>I have some questions and proposals:
>>>>- Is there any experiences of this issue outside of Europe. I.e. are there
>>>>other legal systems that make use of the same declaration logic as the EU
>>>>directive, where the RFC 3039 profile is used fully or partly as a 
>>>>solution
>>>>to this issue?
>>>>- I would suggest that the QCStatement mechanism is ought to be a 
>>>>mandatory
>>>>tool to communicate a Qualified Status. The question is:
>>>>     1) whether this will have enough implementation support to succeed?
>>>>     2) whether is best specified in RFC 3039 or in local profiles 
>>>> (such as
>>>>TS 101862)?
>>>>     3) If there could be a clear context defined where criticality 
>>>> could be
>>>>allowed or even required?
>>>>I would really like feedback from practical experiences from this 
>>>>issue, as
>>>>well as constructive proposals.
>>>>/Stefan
>>>>
>>>>
>>>>/Stefan
>>>>
>>>>_____________________________
>>>>Stefan Santesson,  Retrospekt AB
>>>>http://www.retrospekt.com
>>>>[phone]
>>>_____________________________
>>>Stefan Santesson,  Retrospekt AB
>>>http://www.retrospekt.com
>>>[phone]
>>
>>_____________________________
>>Stefan Santesson,  Retrospekt AB
>>http://www.retrospekt.com
>>[phone]
>
>_____________________________
>Stefan Santesson,  Retrospekt AB
>http://www.retrospekt.com
>[phone]

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone] 
--=====================_83288081==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Sharon and all,<br><br>
I've heard many answers but the questions that needs them has not yet ben
formulated.<br><br>
Lets get back to this issue and do that.<br><br>
<b><u>Facts:<br><br>
</u></b>1) Current definition of the qcStatements ext says that if the
extension is critical then all statements are critical.<br><br>
2) It is compliant with X.509 to state that if an extension is critical,
it is OK to recognize at least 1 of the contained elements. It is however
unlikely that this is a good solution for the qcStatements extension, due
to legacy and the different nature of different statements.<br><br>
3) If one would set this extension as critical, it is likely that many
applications would reject the certificate. This could be true also over
time in the future since many local statement could be defined that would
not be supported by clients in general.<br><br>
<b><u>Questions:<br><br>
</u></b>a) Is there any case/context where fact 3 actually is not a
problem, but rather a feature?<br><br>
b) could any such context be clearly defined and included in RFC 3039bis
or any local standard?<br><br>
<br>
<b><u>Answers:<br><br>
</u></b>Question a)<br>
Yes there has been situations raised where fact 3 actually could be a
feature.<br><br>
Many has complained about the problem to isolate a particular certificate
for use in only electronic signature applications where the content is
clearly presented and accepted by the signer prior to signing. The key
usage or extended key usage extensions are not ready to provide this
functionality. At least not today.<br><br>
So, given that we would have a certificate that we WANT applications in
general to reject it. A certificate that we only want those applications
that are trained and designed to accept it,&nbsp; to actually accept it.
Then this could in fact be a great feature.<br><br>
It could be the mechanism that would force all low grade applications to
reject its use, and thus increase its evidence value when it is
used.<br><br>
<br>
b) It is true that the case described in answer a) does not apply to all
certificates. But given that there are cases where it is of great value
to isolate certificates use to informed applications. Then it might as
well be worth the effort to try to formulate one or some clear contexts
where setting the extension critical ought to be mandatory OR at least
recommended.<br><br>
<br>
<b><u>Opinions:<br><br>
</u></b>My opinion is that it is our responsibility to look seriously
into this issue with open minds before we reach a definitive conclusion
to answer b). Personally I do believe we have a chance to contribute in a
good way to supporting good use and acceptance of electronic signatures
and believe that such context could and should be formulated.<br><br>
<br>
/Stefan<br><br>
<br><br>
<br><br>
At 15:19 2003-03-12 -0500, Sharon Boeyen wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#0000FF">It
would have been compliant IF the semantics of the extension stated that.
However, the semantics of the extension dictate the opposite where ALL
statements are critical</font><font face="arial">.<br>
</font>
<dl>
<dd><font face="tahoma" size=2>-----Original Message-----<br>

<dd>From:</b> Stefan Santesson
[<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>]<br>

<dd>Sent:</b> Tuesday, March 11, 2003 4:49 PM<br>

<dd>To:</b> Sharon Boeyen; [e-mail]<br>

<dd>Subject:</b> RE: QC Declaration<br><br>
</font>
<dd>Sharon,<br><br>

<dd>The first step for me is to get the mechanics right.<br><br>

<dd>Are you saying that it would have been compliant with X.509 to
declare that a critical QCStatement (disregarding the current declaration
in RFC 3039) is valid if I can process at least one of the present
statements (similar to SubjectAltName).<br>
<br>

<dd>Not that I claim that it would be a good idea.<br><br>

<dd>/Stefan<br><br>
<br>

<dd>At 16:30 2003-03-11 -0500, Sharon Boeyen wrote:<br>
<blockquote type=cite class=cite cite>
<dd><font face="arial" size=2 color="#0000FF">I don't want to get off on
a non-relevant tangent regarding criticality, but think I do need to
clarify a little bit on the subject Alt Name extension. If you check
8.3.2.3 (509) you'll find that the semantics of that extension are such
that, if set to critical, &quot;at least one of the name forms that is
present shall be recognized and processed ...&quot;. So if, in your
example, the ONLY name present in subjectAltName extension is the unknown
otherName OID, then you are correct and the certificate shall be
considered invalid. If however, that unknown otherName OID was present
AND and rfc822Name was present - the RP might understand the rfc822Name
and check it against the intended recipient of an encrypted email for
example, and under those circumstances the certificate would be valid,
even though the extension was critical and there was another nameform in
there that was not understood.</font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2 color="#0000FF">I suspect that its probably
a bit too soon to profile the kind of contexts I think you're describing
in 3039. I'd prefer to see a bit more practical use of QCs first so that
we have a better handle on what constitutes a &quot;context&quot;. For
example, perhaps one context is with the ETSI qcstatement 1 plus a
specific national qc statement and if both are present in a certificate
that some 'authority' (I don't mean a CA here) deems that when that
combination is present the extension shall be set to critical. I'm not
necessarily opposing the idea, just a little uncomfortable with the
proposed timing without significant real world deployment to guide us
with to the appropriate 'contexts'.</font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2 color="#0000FF">Cheers,</font><br>

<dd><font face="arial" size=2 color="#0000FF">Sharon</font>
<dd><font face="tahoma" size=2>-----Original Message-----
<dd>From: Stefan Santesson
[<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>]
<dd>Sent: Tuesday, March 11, 2003 4:06 PM
<dd>To: Sharon Boeyen; Sharon Boeyen; [e-mail]
<dd>Subject: RE: QC Declaration<br><br>
</font>
<dd>Sharon,
<dd>Thanks for the clarification.<br>

<dd>&quot;Elements of the syntax&quot; really clarifies things.<br>

<dd>So it is OK to accept an certificate with a critical policy extension
containing an policy OID that I don't recognize, because it doesn't
define any further syntax of the extension.
<dd>The same goes with Extended key usage OIDs.<br>

<dd>However. It would not be OK with a critical subjectAltName containing
an unknown other name OID, since this OID would define further syntax.
<dd>By the same reason I would need to understand all present
QCStatements OIDs, because they do the same (define further 
syntax).<br>

<dd>Let me clarify that I never proposed that the QCStatement must be
critical in all certificates.
<dd>I'm just recognizing that it might be a valuable practice within
certain contexts and the fact that some implementers actually ask for
it.
<dd>The question is whether any of those contexts can be identified
within RFC 3039, or if they are better placed in local sub-profiles (Such
as ETSI TS 101862), or if they don't exist in a way that can be
standardized in a meaningful way.<br>
<br>

<dd>/Stefan<br>
<br>

<dd>At 11:37 2003-03-11 -0500, Sharon Boeyen
wrote:<blockquote type=cite class=cite cite>
<dd><font face="arial" size=2 color="#0000FF">Hi Stefan,</font><br>

<dd>&nbsp; 
<dd><font face="arial" size=2 color="#0000FF">Remember first that RFC
3280 is a &quot;profile&quot; of X.509 and it does not replace the
requirements of 509, but rather profiles them to a subset. </font><br>

<dd>&nbsp; 
<dd><font face="arial" size=2 color="#0000FF">X.509 in clause 7 allows
unknown elements in non-critical extensions only to be ignored. However,
that is more with respect to the elements in the syntax </font>
<dd><font face="arial" size=2 color="#0000FF">itself (for example in the
IDP extension no RP is allowed to ignore the &quot;onlySomeReasons&quot;
element if it is present in the extension because the extension </font>
<dd><font face="arial" size=2 color="#0000FF">can only be critical. The
behaviour of RPs will differ however depending on their specific
capability with respect to that element (some will use the CRL for
</font>
<dd><font face="arial" size=2 color="#0000FF">the specified reasons and
others will seek a different CRL that covers all reasons), however, no RP
is permitted to simply ignore the flag. Note also that in that</font>
<dd><font face="arial" size=2 color="#0000FF">same clause, for extensions
that can be marked critical or non-critical, a system that understands
the extension is required to process it regardless of the </font>
<dd><font face="arial" size=2 color="#0000FF">value of the criticality
flag. It is ONLY systems that do not understand an extension that can
ignore it completely if it is marked non-critical. </font><br>

<dd>&nbsp; 
<dd><font face="arial" size=2 color="#0000FF">For the QC Statements
extension, RFC 3039 says &quot;This extension may be critical or
non-critical.&nbsp; If the extension is critical, this means that all
statements </font>
<dd><font face="arial" size=2 color="#0000FF">included in the extension
are regarded as
critical.</font><font face="Times New Roman, Times" size=2 color="#0000FF">
</font><font face="arial" size=2 color="#0000FF">&quot; </font><br>

<dd>&nbsp; 
<dd><font face="arial" size=2 color="#0000FF">Because of the semantics
defined for the extension in RFC 3039, marking it critical would result
in the problems I raised.
</font><font face="Times New Roman, Times" size=2 color="#0000FF"><br><br>
</font>
<dd><font face="tahoma" size=2>-----Original Message----- 
<dd>From: Stefan Santesson
[<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>] 
<dd>Sent: Tuesday, March 11, 2003 11:23 AM 
<dd>To: Sharon Boeyen; [e-mail] 
<dd>Subject: RE: QC Declaration<br><br>
</font>
<dd>Hi Sharon,
<dd>My interpretation of criticality does not really match yours.
<dd>The only guidance on the meaning of criticality in RFC 3280 (section
4.2) that I can find is:<br>
<br>
<br>
<br><br>

<dd><pre>&nbsp; &quot;A certificate using system MUST reject the


<dd>certificate



<dd>if it encounters a critical extension it does not recognize&quot;

</pre><font face="Courier New, Courier"></font>
<dd>My interpretation is that it is OK to accept a certificate if you
recognize the extension as such. You don't need to understand ALL
information that the extension contains.
<dd>It seam vital to agree on this issue before we can make any
conclusion on QCStatament criticality.
<dd>/Stefan<br>

<dd>At 10:56 2003-03-11 -0500, Sharon Boeyen wrote:
<blockquote type=cite class=cite cite>
<dd>Hi Stefan,
<dd>While I believe that in the longer term certificate policies will be
the 
<dd>optimum 
<dd>way to convey the necessary information, I acknowledge that QC
Statements is 
<dd>the 
<dd>more popular scheme at present. Therefore I wouldn't have any problem
should 
<dd>this 
<dd>extension be mandated in RFC 3039. 
<dd>However, forcing its criticality is going too far I believe. There is
an 
<dd>important 
<dd>difference between critical and non-critical extensions that we need
to keep 
<dd>in 
<dd>mind from the relying party's perspective. If there is a non-critical 
<dd>extension that 
<dd>the RP understands, but that extension includes some elements that it
does 
<dd>not, then 
<dd>the RP is free to process the parts it does understand and ignore
others. If 
<dd>an extension 
<dd>is critical however, the RP is required to understand ALL elements
within 
<dd>the extension.
<dd>Where I think this can become a problem is the content of the QC
Statements 
<dd>extension. Note 
<dd>that RFC 3039 and the ETSI profile define DIFFERENT statements for
inclusion 
<dd>in the extension. 
<dd>Also additional profiles may add their own local statements and even 
<dd>narrower statements can 
<dd>get added in specific deployment environments. While the cert issuer
may 
<dd>want to include many 
<dd>of these statements to enable the cert to be used in various
environments, 
<dd>the RP should only 
<dd>be required to understand and process the statements that are
appropriate to 
<dd>its own 
<dd>operating environment as dictated by its local security policy (which
could 
<dd>be different than 
<dd>that under which the CA operated). Therefore I think requiring it to
be 
<dd>critical is risky. 
<dd>Also requiring that it always be critical would have interop/backward 
<dd>compatibility issues.
<dd>Cheers, 
<dd>Sharon<br>
<br>
<br>

<dd>-----Original Message----- 
<dd>From: Stefan Santesson
[<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>] 
<dd>Sent: Tuesday, March 11, 2003 8:27 AM 
<dd>To: [e-mail] 
<dd>Subject: QC Declaration<br>
<br>

<dd>The EU directive introduced a requirement on each CA, issuing QC
(Qualified 
<dd>Certificates), to clearly indicate in these certificate that they are 
<dd>issued as QC.
<dd>ETSI implemented RFC 3039 in relation to the European electronic
signature 
<dd>directive through their Technical Standard (TS 101862)
<dd>TS 101862 specified 2 alternative ways to declare a certificate as
QC.
<dd>1) By inclusion of a QCStatements extension 
<dd>2) By including a certificate policy identifying this property
<dd>Even though solution number 1) is far easier to handle by
applications, 
<dd>since they don't need to recognize specific QC Policies, ETSI didn't
make 
<dd>solution 1) mandatory or even consider making it critical, due to
lack of 
<dd>confidence that clients would widely deploy this solution. ETSI
needed to 
<dd>define a solution that could work even if no one choose to implement
the 
<dd>new extensions provided by RFC 3039.
<dd>However, It is not feasible to keep clients updated over time with 
<dd>different QC policies and even those policies that are regarded 
<dd>standardized may be updated with change of OID as a result. It would
be 
<dd>devastating if we can't update a QCP because that would force an OID
update 
<dd>and that would render certificates useless because clients learned to 
<dd>recognize only the old OID. This would be to build in a new root 
<dd>certificate problem into the platforms.
<dd>My observations is that times have changed. I have seen clear
indications 
<dd>that market players want, and even require for interoperability
reasons, 
<dd>that use QCStatements solution is made mandatory and maybe even
critical 
<dd>for QC.
<dd>Since both RFC 3039, and TS 101862 are up for revision, it is time to 
<dd>revisit this issue.
<dd>I have some questions and proposals:
<dd>- Is there any experiences of this issue outside of Europe. I.e. are
there 
<dd>other legal systems that make use of the same declaration logic as
the EU 
<dd>directive, where the RFC 3039 profile is used fully or partly as a
solution 
<dd>to this issue?
<dd>- I would suggest that the QCStatement mechanism is ought to be a
mandatory 
<dd>tool to communicate a Qualified Status. The question is: 
<dd>&nbsp;&nbsp;&nbsp; 1) whether this will have enough implementation
support to succeed? 
<dd>&nbsp;&nbsp;&nbsp; 2) whether is best specified in RFC 3039 or in
local profiles (such as 
<dd>TS 101862)? 
<dd>&nbsp;&nbsp;&nbsp; 3) If there could be a clear context defined where
criticality could be 
<dd>allowed or even required?
<dd>I would really like feedback from practical experiences from this
issue, as 
<dd>well as constructive proposals.
<dd>/Stefan<br>
<br>
<br>

<dd>/Stefan<br>
<br>

<dd>_____________________________ 
<dd>Stefan Santesson,&nbsp; Retrospekt AB 
<dd><a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a> 
<dd>[phone] </blockquote>
<dd>_____________________________ 
<dd>Stefan Santesson,&nbsp; Retrospekt AB 
<dd><a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a> 
<dd>[phone] </blockquote>
</dl><br>
_____________________________<br>
Stefan Santesson,&nbsp; Retrospekt AB<br>
<a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a><br>
[phone] </blockquote><br>
_____________________________<br>
Stefan Santesson,&nbsp; Retrospekt AB<br>
<a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a><br>
[phone] <br>
</blockquote>
<x-sigsep><p></x-sigsep>
_____________________________<br>
Stefan Santesson,&nbsp; Retrospekt AB<br>
<a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a><br>
[phone]</body>
</html>

--=====================_83288081==.ALT--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EMJME08790 for ietf-pkix-bks; Fri, 14 Mar 2003 14:19:22 -0800 (PST)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EMJGg08770 for <[e-mail]>; Fri, 14 Mar 2003 14:19:16 -0800 (PST)
Received: from SJOSEPH (pcp239416pcs.elictc01.md.comcast.net [68.55.244.2]) by mtaout05.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with SMTP id <[e-mail]> for [e-mail]; Fri, 14 Mar 2003 17:19:13 -0500 (EST)
Date: Fri, 14 Mar 2003 17:17:59 -0500
From: Al Arsenault <[e-mail]>
Subject: Re: Certificate Policies
To: Anders Rundgren <[e-mail]>, Richard Levitte - VMS Whacker <[e-mail]>
Cc: [e-mail], Santosh Chokhani <[e-mail]>, [e-mail], [e-mail]
Message-id: <03cb01c2ea77$92d69760$6501a8c0@SJOSEPH>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <006601c2e85f$69053000$0500a8c0@arport> <[e-mail]> <008501c2e92e$d5de5380$0500a8c0@arport> <[e-mail]> <005301c2ea0f$6c402f70$0500a8c0@arport>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders Rundgren wrote:

<snip>
>
> I occasionally look on this in a slightly "philosophical" way:
> If one large user like DoD, deploys "something" but the rest of
> the market does not, using my thinking, it was a failure for this
> "something" (and long-term also for the DoD).
>

No.  It could mean that the DoD has different requirements than most other
people.  It could mean that the people in charge there have different
architectural views of the world, or different personal preferences.

Stripping out all the political correctness, the primary job of the "Defense
Department" of any nation is to, when the circumstances require it, kill
people and break things.  Yes, do so while preventing your own people from
being killed and your own things from being broken, but...  Not a whole lot
of other organizations have that as a mission.  So it stands to reason that
such an organization *just might* have slightly different requirements from,
say, a bank or a credit card processor or a phone company.

So the fact that a "Defense Department" deploys PKI differently from, say,
Visa International, does not necessarily mean that either organization is
wrong.

That's my biggest problem with "let the market decide".  If we say that a
technology which achieves significant market dominance, say, 75% market
share is by definition "right" and thus deserves to be the only technology
used and to have a 100% market share, we (a) kill a lot of good technologies
unnecessarily; (b) mean that certain customers with unique requirements get
blown away; and (c) possibly reward undeserving technologies, anyway,
because the "market" doesn't always choose the best solution - which might
explain tons of buffer overflows, viruses, worms, etc. (Mostly, "what
Richard Levitte said".)

                    Al Arsenault
                    Chief Security Architect
                    Diversinet Corp.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EM9Bp07849 for ietf-pkix-bks; Fri, 14 Mar 2003 14:09:11 -0800 (PST)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EM9Ag07845 for <[e-mail]>; Fri, 14 Mar 2003 14:09:10 -0800 (PST)
Received: from SJOSEPH (pcp239416pcs.elictc01.md.comcast.net [68.55.244.2]) by mtaout07.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with SMTP id <[e-mail]> for [e-mail]; Fri, 14 Mar 2003 17:08:45 -0500 (EST)
Date: Fri, 14 Mar 2003 17:07:31 -0500
From: Al Arsenault <[e-mail]>
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)
To: Margus Freudenthal <[e-mail]>
Cc: [e-mail]
Message-id: <03c301c2ea76$1c10aa90$6501a8c0@SJOSEPH>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <007f01c2e75f$4b93ec10$2d00a8c0@Chokhani> <[e-mail]> <00b401c2e7ff$183fb420$0500a8c0@arport> <[e-mail]> <006601c2e85f$69053000$0500a8c0@arport> <[e-mail]> <[e-mail]> <007b01c2e96e$81e4b900$6501a8c0@SJOSEPH> <[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>

Margus Freudenthal wrote:

> Al Arsenault wrote:
> >
> > >From a technical standpoint, typically nothing prevents this.  It's not
> > commonly done because:
> >
> >     a.  There's more of a management problem; e.g., if the key is ever
> > compromised for whatever reason, you have to track down ALL of the
> > certificates it was bound to and revoke them;  and
> >
> Each certificate that is issued to you brings along some kind of
> liability (documents signed using that certificate are considered to be
> signed by you). Therefore you'd be crazy not to keep track of all your
> certificates/liabilities.
>

This is certainly true in theory, but people being people, I wouldn't count
on everybody having a perfect system for tracking all of the certificates,
if there were a lot of them.  Especially if something needs to be done in a
hurry; e.g., "the private key is compromised because Mike found out he was
being laid off, used an attack against the machine to discover it, and has
posted it on the Web.  Revoke all the certs now, and don't miss any."

Yes, a good organization has policies and procedures to both defend against
and recover from such situations, but anybody who thinks they're always
going to work hasn't experienced much of the world.

        Al Arsenault





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EKn4n03665 for ietf-pkix-bks; Fri, 14 Mar 2003 12:49:04 -0800 (PST)
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EKmxg03659 for <[e-mail]>; Fri, 14 Mar 2003 12:48:59 -0800 (PST)
Received: from nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h2EKmbCZ014408; Fri, 14 Mar 2003 15:48:38 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 14 Mar 2003 15:50:17 -0500
From: "David A. Cooper" <[e-mail]>
Reply-To: [e-mail]
Organization: NIST
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Wen-Cheng Wang <[e-mail]>
CC: [e-mail]
Subject: Re: Will IDP syntax and semantics be changed in the future?
References: <008501c2e977$8e8535f0$4f85900a@wcwang>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I haven't had a chance to think about all of the possible consequences 
of additional fields in the issuingDistributionPoint extension, but I 
will try to address the comments below in light of the current PKIX 
standards.

See comments below.

Wen-Cheng Wang wrote:

>Hi,
>
>Recently, I download the pre-published Technical Corrigendum 3 of X.509
>4th edition (the prepublished X.509 TC3) from ITU-T website. The content
>of the prepublished X.509 TC3 is mainly for correcting defect related to
>CRL processing/validation. I do not know how soon the prepublished X.509
>TC3 will come in force. However, I believe that, once it become in force, it
>will introduce some conflicts between RFC 3280 and X.509 standards.
>The syntax and semantics of Issuing Distribution Point
>extension are different between RFC 3280 and the prepublished X.509
>TC3 .
>
>In RFC 3280, the definition of the IssuingDistributionPoint is as follows:
>    IssuingDistributionPoint ::= SEQUENCE {
>         distributionPoint    [0] DistributionPointName OPTIONAL,
>         onlyContainsUserCerts    [1] BOOLEAN DEFAULT FALSE,
>         onlyContainsCACerts    [2] BOOLEAN DEFAULT FALSE,
>         onlySomeReasons    [3] ReasonFlags OPTIONAL,
>         indirectCRL    [4] BOOLEAN DEFAULT FALSE,
>         onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
>(Note there is a typo in RFC 3280, the beginning "i" of
>"issuingDistributionPoint" should be capitalized.)
>
>In the prepublished X.509 TC 3 , the new definition is as follows:
>    IssuingDistPointSyntax ::= SEQUENCE {
>        distributionPoint   [0] DistributionPointName OPTIONAL,
>        containsUserPublicKeyCerts [1] BOOLEAN DEFAULT FALSE,
>        containsCACerts   [2] BOOLEAN DEFAULT FALSE,
>        onlySomeReasons   [3] ReasonFlags OPTIONAL,
>        indirectCRL    [4] BOOLEAN DEFAULT FALSE,
>        containsUserAttributeCerts [5] BOOLEAN DEFAULT FALSE,
>        containsAACerts   [6] BOOLEAN DEFAULT FALSE,
>        containsSOAPublicKeyCerts [7] BOOLEAN DEFAULT FALSE }
>(Note that the data type name is different, but it represents the same
>thing.)
>The most obvious change made by the prepublished X.509 TC 3 is that it
>expands the onlyContainsAttributeCerts flag to two flags, namely
>"containsUserAttributeCerts" and "containsAACerts", and it add another flag
>
>named "containsSOAPublicKeyCerts" specifically for indicating whether the
>set of certificates covered by the CRL contains the public-key certificates
>of SOAs. Since these are PMI-related flags, the change of them are less
>related to RFC 3280.
>
These may be a problem, but if I understand correctly, it will not be an 
issue if certificate issuers limit themselves to the features of the 
PKIX profiles.

First, PKIX does not include the SOAIdentifier extension.  If no 
certificates are issued with the SOAIdentifier extension, it would make 
no sense to have a CRL that only covered certificates that include this 
extension.

The PKIX attribute certificate profile, RFC 3281, discourages the use of 
delegation.  If I understand correctly, conformance to this profile 
would mean that there would be no AA certificates, only user attribute 
certificates.  If this is the case, then the change from 
onlyContainsAttributeCerts to containsUserAttributeCerts should not be a 
problem since all attribute certificates are user attribute certificates.

>What we should note is that the remove of the adverb "only" from the
>"onlyContainsUserCerts" flag and the "onlyContainsCACerts" flag. IMHO, the
>remove of the adverb "only" from these flags not only changes the syntax but
>also only changes the semantics. In RFC 3280, since the exist of the adverb
>"only", these flags are exclusive to each other. That is, the
>"onlyContainsUserCerts" flag and the "onlyContainsCACerts" flag cannot be
>both set to TRUE at the same time. However, in the new definition, these
>flags are not exclusive to each other anymore. That is, the
>"containsUserPublicKeyCerts" flag and the "containsCACerts" flag can be both
>set to TRUE at the same time. It seems that the semantics of these flags is
>changed.
>
While one can now set more than one flag to TRUE, it should not be a 
significant problem.   If you are checking the status of an end entity 
public key certificate and the 
onlyContainsUserCerts/containsUserPublicKeyCerts flag is TRUE or if all 
of the contains... flags are FALSE, then the certificate is covered. 
 This is the same general rule as before.

>In RFC 3280, the semantics of these flags is as follows:
>1. The onlyContainUserCerts flag indicates "whether the CRL scope ONLY
>    covers EE certificates".
>2. The onlyContainsCACerts flag indicates "whether the CRL scope ONLY
>    covers CA certificates".
>However, in the new definition, the semantics of these flags is as follows:
>1. The containUserCerts flag indicates "whether the CRL scope covers EE
>    certificates".
>2. The containsCACerts flag indicates "whether the CRL scope covers CA
>    certificates".
>
I believe you are misquoting TC3 to X.509. The text states:

        If containsUserPublicKeyCerts is true, the CRL contains 
revocations for end-entity public-key
        certificates. If containsCACerts is true, the CRL contains 
revocations for CA certificates.

The text above does not say what it means if these flags are false. 
 That is covered elsewhere and the text clearly states that if all of 
the flags are false then all types of certificates are covered.

>Fortunately, the default value of these flags are both FALSE, so that the
>effect of letting one flag set to TRUE and the other flag set to FALSE or be
>absent seems to be backward compatible to RFC 3280 and the original X.509
>standards because:
>1. a CRL with containUserCerts flag set to true and with containsCACerts
>    absent means that its scope covers EE certificates but does not cover CA
>    certificates; (That is, its scope only covers EE certificates.)
>2. a CRL with containCACerts flag set to true and with containsUserCerts
>    absent means that its scope covers CA certificates but does not cover EE
>    certificates. (That is, its scope only covers CA certificates.)
>
>The problem is that if containUserCerts flag and containsCACerts flag are
>both absent, the accoding to the new semantics that will means the the scope
>of the CRL does not cover both EE certificates and CA certificates since the
>default value of these two flags are both FALSE. That is conflict with RFC
>3280 and the original X.509 standard.
>
As I stated above, this is not what TC3 states.  If all of the 
contains... are false, then all types of certificates are covered just 
as before.

>However, I believe that the author of the prepublished X.509 TC 3
>also noticed the problem so that for maintaining back compatibility with
>RFC 3280 and the original X.509 standard, the prepublished X.509 TC 3
>specially specifies "if all these flags are absent, it indicates that the
>CRL scope covers both EE certificates and CA certificates".
>
Exactly, so there is no conflict.

>Unfortunately, that is conflict with X.680 and X.690 standards. The ASN.1 rule is
>"if the field has DEFAULT value and the field is absent, the DEFAULT
>value is applied to the field".
>
There is no conflict with X.680/X.690.  It has always been the case for 
the IDP extension that if the value of one of the flags if FALSE (the 
default) then it does not appear in the encoding.  TC3 does not 
contradict this.  TC3 states that if all of the values are FALSE, then 
it means that the CRL covers all types of certificates.  You are 
confusing the encoding of the values (if FALSE then absent as mandated 
by DER in X.690) with the semantics (meaning) of a particular value.

TC3 states what it MEANS when all of the flags are set to false, X.690 
states how to ENCODE these values.  The two are not related.

>With the new definition of IDP extension, to indicate that the CRL
>scope covers both EE certificates and CA certificates, both flags
>need to be set to TRUE. However, the the original definition, the
>"onlyContainsUserCerts" flag and the "onlyContainsCACerts" flag cannot be
>both set to TRUE at the same time since they are exclusive to each other.
>
TC3 is very clear that one does not need to set both flags to TRUE.  If 
all flags are false then all types of certificates are covered. While 
the TC3 does allow for more than one flag to be set, one should continue 
for set all flags to false to indicate that all types of certificates 
are covered.

>  
>





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EGGFq17944 for ietf-pkix-bks; Fri, 14 Mar 2003 08:16:15 -0800 (PST)
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EGGDg17940 for <[e-mail]>; Fri, 14 Mar 2003 08:16:13 -0800 (PST)
Received: from SOTTMXS01.entrust.com (sottmxs01.entrust.com [10.4.61.7]) by sottmxssm.entrust.com (Switch-2.2.5/Switch-2.2.4) with ESMTP id V2EG0DHW10881; Fri, 14 Mar 2003 11:13:17 -0500
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <GXR539TR>; Fri, 14 Mar 2003 09:38:38 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Wen-Cheng Wang'" <[e-mail]>, [e-mail]
Subject: RE: Will IDP syntax and semantics be changed in the future?
Date: Fri, 14 Mar 2003 09:38:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

There are a number of Defect Reports that have approved TCs that I believe 
need to be taken into consideration if RFC 3280 evolves from its current
state and 
I was planning to put together a summary of the differences for
consideration (however 
I haven't been able to get it together yet). I have been thinking about this
one 
in particular however very recently and am concerned that when we progressed
the 
TC in the 509 group we may not have worked through migration scenarios as
thoroughly 
as perhaps we might have. While it is true that the syntax (bits on the
wire) are the 
same, the semantics have definitely changed and I'm struggling to come up
with a 
reasonable migration strategy to suggest to profile groups such as PKIX. I'm
wondering 
if we shouldn't have actually changed the OID when the semantic changes were
made to 
the extension and am just beginning to investigate whether a) that is the
course of 
action that should be taken to enable profiles to include this revision and
b) what 
the process would be to achieve that if it is determined that it is needed. 

Other thoughts?

Sharon

-----Original Message-----
From: Wen-Cheng Wang [mailto:[e-mail]]
Sent: Thursday, March 13, 2003 10:45 AM
To: [e-mail]
Subject: Will IDP syntax and semantics be changed in the future?



Hi,

Recently, I download the pre-published Technical Corrigendum 3 of X.509
4th edition (the prepublished X.509 TC3) from ITU-T website. The content
of the prepublished X.509 TC3 is mainly for correcting defect related to
CRL processing/validation. I do not know how soon the prepublished X.509
TC3 will come in force. However, I believe that, once it become in force, it
will introduce some conflicts between RFC 3280 and X.509 standards.
The syntax and semantics of Issuing Distribution Point
extension are different between RFC 3280 and the prepublished X.509
TC3 .

In RFC 3280, the definition of the IssuingDistributionPoint is as follows:
    IssuingDistributionPoint ::= SEQUENCE {
         distributionPoint    [0] DistributionPointName OPTIONAL,
         onlyContainsUserCerts    [1] BOOLEAN DEFAULT FALSE,
         onlyContainsCACerts    [2] BOOLEAN DEFAULT FALSE,
         onlySomeReasons    [3] ReasonFlags OPTIONAL,
         indirectCRL    [4] BOOLEAN DEFAULT FALSE,
         onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
(Note there is a typo in RFC 3280, the beginning "i" of
"issuingDistributionPoint" should be capitalized.)

In the prepublished X.509 TC 3 , the new definition is as follows:
    IssuingDistPointSyntax ::= SEQUENCE {
        distributionPoint   [0] DistributionPointName OPTIONAL,
        containsUserPublicKeyCerts [1] BOOLEAN DEFAULT FALSE,
        containsCACerts   [2] BOOLEAN DEFAULT FALSE,
        onlySomeReasons   [3] ReasonFlags OPTIONAL,
        indirectCRL    [4] BOOLEAN DEFAULT FALSE,
        containsUserAttributeCerts [5] BOOLEAN DEFAULT FALSE,
        containsAACerts   [6] BOOLEAN DEFAULT FALSE,
        containsSOAPublicKeyCerts [7] BOOLEAN DEFAULT FALSE }
(Note that the data type name is different, but it represents the same
thing.)
The most obvious change made by the prepublished X.509 TC 3 is that it
expands the onlyContainsAttributeCerts flag to two flags, namely
"containsUserAttributeCerts" and "containsAACerts", and it add another flag

named "containsSOAPublicKeyCerts" specifically for indicating whether the
set of certificates covered by the CRL contains the public-key certificates
of SOAs. Since these are PMI-related flags, the change of them are less
related to RFC 3280.
What we should note is that the remove of the adverb "only" from the
"onlyContainsUserCerts" flag and the "onlyContainsCACerts" flag. IMHO, the
remove of the adverb "only" from these flags not only changes the syntax but
also only changes the semantics. In RFC 3280, since the exist of the adverb
"only", these flags are exclusive to each other. That is, the
"onlyContainsUserCerts" flag and the "onlyContainsCACerts" flag cannot be
both set to TRUE at the same time. However, in the new definition, these
flags are not exclusive to each other anymore. That is, the
"containsUserPublicKeyCerts" flag and the "containsCACerts" flag can be both
set to TRUE at the same time. It seems that the semantics of these flags is
changed.

In RFC 3280, the semantics of these flags is as follows:
1. The onlyContainUserCerts flag indicates "whether the CRL scope ONLY
    covers EE certificates".
2. The onlyContainsCACerts flag indicates "whether the CRL scope ONLY
    covers CA certificates".
However, in the new definition, the semantics of these flags is as follows:
1. The containUserCerts flag indicates "whether the CRL scope covers EE
    certificates".
2. The containsCACerts flag indicates "whether the CRL scope covers CA
    certificates".
Fortunately, the default value of these flags are both FALSE, so that the
effect of letting one flag set to TRUE and the other flag set to FALSE or be
absent seems to be backward compatible to RFC 3280 and the original X.509
standards because:
1. a CRL with containUserCerts flag set to true and with containsCACerts
    absent means that its scope covers EE certificates but does not cover CA
    certificates; (That is, its scope only covers EE certificates.)
2. a CRL with containCACerts flag set to true and with containsUserCerts
    absent means that its scope covers CA certificates but does not cover EE
    certificates. (That is, its scope only covers CA certificates.)

The problem is that if containUserCerts flag and containsCACerts flag are
both absent, the accoding to the new semantics that will means the the scope
of the CRL does not cover both EE certificates and CA certificates since the
default value of these two flags are both FALSE. That is conflict with RFC
3280 and the original X.509 standard.

However, I believe that the author of the prepublished X.509 TC 3
also noticed the problem so that for maintaining back compatibility with
RFC 3280 and the original X.509 standard, the prepublished X.509 TC 3
specially specifies "if all these flags are absent, it indicates that the
CRL
scope covers both EE certificates and CA certificates". Unfortunately,
that is conflict with X.680 and X.690 standards. The ASN.1 rule is
"if the field has DEFAULT value and the field is absent, the DEFAULT
value is applied to the field".

With the new definition of IDP extension, to indicate that the CRL
scope covers both EE certificates and CA certificates, both flags
need to be set to TRUE. However, the the original definition, the
"onlyContainsUserCerts" flag and the "onlyContainsCACerts" flag cannot be
both set to TRUE at the same time since they are exclusive to each other.

Any comment?

-----
Wen-Cheng Wang
Project Researcher
Telecommunication Laboratories
Chunghwa Telecom Co., Ltd



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EELAR12890 for ietf-pkix-bks; Fri, 14 Mar 2003 06:21:10 -0800 (PST)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EEL8g12878 for <[e-mail]>; Fri, 14 Mar 2003 06:21:09 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maild.telia.com (8.12.8/8.12.8) with SMTP id h2EEKxvd029488; Fri, 14 Mar 2003 15:21:04 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <009401c2ea33$710e4ef0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Hallam-Baker, Phillip" <[e-mail]>
Subject: Q: XKMS - X.509.v3 interface
Date: Fri, 14 Mar 2003 15:10:12 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Phill,
In case you receive a signed message and associated cert-path,
is there an extension which can be used to retrieve the rest of
the cert-path up to the root using XKMS?

I.e. I would at the receival of a message from a new party
using an unknown CA be able to hit "OK" to get the root
"installed".

Thoughts?

Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EBaBK27255 for ietf-pkix-bks; Fri, 14 Mar 2003 03:36:11 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EBa9g27251 for <[e-mail]>; Fri, 14 Mar 2003 03:36:10 -0800 (PST)
Received: from localhost (212.247.5.91) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Fri, 14 Mar 2003 12:34:45 +0100
Date: Fri, 14 Mar 2003 12:34:11 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Certificate Policies
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <005301c2ea0f$6c402f70$0500a8c0@arport>
References: <008501c2e92e$d5de5380$0500a8c0@arport> <[e-mail]> <005301c2ea0f$6c402f70$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.2
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <005301c2ea0f$6c402f70$0500a8c0@arport> on Fri, 14 Mar 2003 10:52:22 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> Hi Richard,
anders.rundgren> 
anders.rundgren> >A policy implies what is written in it (in the CP
anders.rundgren> >and the CPS).  There's nothing in a policy OID that
anders.rundgren> >can tell you what the function or the legality of
anders.rundgren> >the policy is, you have to read the documents and
anders.rundgren> >decide that for yourself accordingly.
anders.rundgren> 
anders.rundgren> So far, I am with you.
anders.rundgren> 
anders.rundgren> Now assuming that a single CA key/cert can create N
anders.rundgren> different policies applied to M different EE
anders.rundgren> certificates, you get a potentially unmanageable
anders.rundgren> legal/function matrix.

A CA key/ct doesn't create policies.  It may contain N different
policies, of which one (at least that's what I assume) will be used
every time an EE certificate is issued.  I don't quite understand why
that would create such a matrix, does the policy change from one EE
certificate to another?  The way I see it, you keep track of N
policies when validating a path, period.

It sounds like you're creating problems where there aren't any, or
there is something that I haven't quite grasped yet...

anders.rundgren> BTW, why do some people believe that you need a lot
anders.rundgren> of different policies?  To keep legal departments
anders.rundgren> busy?  Why do you actually need more than one within
anders.rundgren> a given "trust-network"?

More than one is obvious.  You may a have different policy for EE
certificates given to people who are supposed to use them for million
dollar transactions than the one for EE certificates given to mail
users.

Why everyone seems to need to have their own "special" policy?  Beats
me.  Why do we have all those different program licenses that
essentially express the same thing?  Why do commercial programs come
with licenses written uniquely by each vendor?  Why can't they agree
to use the exact same license?  Why does each company have it's very
own contract form for employees instead of using a standard one?

I believe the answer is "welcome to the human condition" rather than
anything really rational, perhaps except that many CPs are written for
one specific CA (mentioned by name and so on) and is therefore not
usable for other CAs.  In any case, it's a matter of keeping control
over the stuff you use and produce, and I agree that it takes silly
proportions in this case.

If you write a set of CPs and submit them to some kind of standards
commitee (I think NIST has collected a few CPs), and I like them, I've
no problem with using them instead of writing my own.  If someone else
does the work and allows me to use the work in question, why should I
waste my time redoing the work?

anders.rundgren> It would be very interesting to see what purposes all
anders.rundgren> this stuff is supposed to fill in application software.
anders.rundgren> 
anders.rundgren>             Architecture?
anders.rundgren> 
anders.rundgren>             Data model?
anders.rundgren> 
anders.rundgren>             Links?

You keep on saying that, and you seem to forget there's a human side
to this as well.  There are people with needs of control.  I believe
that's the answer to your question much more than a programmatic one.

anders.rundgren> I occasionally look on this in a slightly
anders.rundgren> "philosophical" way:  If one large user like DoD,
anders.rundgren> deploys "something" but the rest of the market does
anders.rundgren> not, using my thinking, it was a failure for this
anders.rundgren> "something" (and long-term also for the DoD).

Not really.  Within DoD and others that have used PKI for a while,
this is old stuff.  Among "common people", this is really new, and
most of them haven't even been told this exists...  It takes a while
before this becomes common knowledge.  It's almost like the Internet;
according to John Doe on the street, the Internet started somewhere
like 1994 or 1995, or perhaps even later...  It takes a while before
knowledge spreads...

anders.rundgren> As not even X.500 directories and LDAP are sacred anymore
anders.rundgren> http://www.imc.org/ietf-pkix/mail-archive/msg05571.html ,
anders.rundgren> it seems that PKI technology is still to be regarded as being
anders.rundgren> highly immature.  That is, your answer is as good as mine.

You couldn't have said it better.  It hasn't matured yet, and we're
all working to help it mature (or to reject it :-)).

anders.rundgren> Unless somebody provides some more facts regarding PE
anders.rundgren> usage in application software, I suggest that we halt
anders.rundgren> this thread a while, and let the market do the final
anders.rundgren> selection...

Let me think about usage a bit and I'll get back to you (if I
remember).

About letting the market decide, I'm not sure I trust it very much.
Most people have a tendency to go for something cheap that works for
now, often resulting in a status quo of crap (for some definition of
"crap").  I have very little trust in the market's lookout for
quality, I've just seen too few examples of that happening.  If I'm
wrong, I'll joyfully be corrected!

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


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EAj9Z22202 for ietf-pkix-bks; Fri, 14 Mar 2003 02:45:09 -0800 (PST)
Received: from mail3.consignia.com (mail3.consignia.com [144.87.143.83]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EAj7g22198 for <[e-mail]>; Fri, 14 Mar 2003 02:45:08 -0800 (PST)
Received: from postoffice.co.uk (unknown [144.87.146.16]) by mail3.consignia.com (Postfix) with SMTP id 7748618F8CC; Fri, 14 Mar 2003 10:45:07 +0000 (GMT)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256CE9.003B1568 ; Fri, 14 Mar 2003 10:45:21 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: "Anders Rundgren" <[e-mail]>
Cc: "Santosh Chokhani" <[e-mail]>, [e-mail], [e-mail], "Richard Levitte - VMS Whacker" <[e-mail]>, [e-mail]
Message-ID: <[e-mail]>
Date: Fri, 14 Mar 2003 10:44:57 +0000
Subject: Re: Certificate Policies
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Now assuming that a single CA key/cert can create N different
> policies applied to M different EE-certificates, you get a potentially
> unmanageable legal/function matrix.

In my experience a single EE cert is created under a single policy.
There is nothing preventing that policy having within it more than
one Policy Identifier, however. It is up to the CA operators to
create manageable policies and it is up to the relying party to
understand the legal limits of the policy that they are relying
upon. I don't believe that this is a technical issue as such

> BTW, why do some people believe that you need a lot of
> different policies?  To keep legal departments busy?  Why do
> you actually need more than one within a given "trust-network"?

Two CA operators are unlikely to operate the same CPs and thus
accept the same liabilities. Even a single CA is unlikely to
issue certs in a single context. A face-to-face registration
carries far more trust than a low-level technology enabling
over-the-web registration a la Thawte secure email certificates.
CAs/UAs must be able to differentiate between the two at the
certificate definition level and the current mechanism in the
accepted design is certificatePolicies, regardless of how
effective it is at the moment in the absence of policy
enforcement at the UA level.

> It would be very interesting to see what purposes all this
> stuff is supposed to fill in application software.

Agreed. It's still at the level of a solution looking for
a problem and requires widespread adoption before it will work.

> I occasionally look on this in a slightly "philosophical" way:
> If one large user like DoD, deploys "something" but the rest of
> the market does not, using my thinking, it was a failure for this
> "something" (and long-term also for the DoD).

Natural selection. If it works (not just technologically) then
it will happen. If it doesn't then it will die and be superseded
by something that does, regardless of how elegant it is (Alas,
poor Ingres, I knew it well)

> it seems that PKI technology is still to be regarded as being
> highly immature

Agreed. TCPA and Palladium might have some benefits in this
direction methinks.

> Unless somebody provides some more facts regarding PE usage
> in application software, I suggest that we halt this thread a while,
> and let the market do the final selection...

It's given the issue a good airing. That can only be a good thing.

Chris




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EAeuB21657 for ietf-pkix-bks; Fri, 14 Mar 2003 02:40:56 -0800 (PST)
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EAesg21651 for <[e-mail]>; Fri, 14 Mar 2003 02:40:54 -0800 (PST)
Received: from ms6.chttl.com.tw (ms6 [10.144.2.116]) by fw.chttl.com.tw (8.12.8/8.11.6) with ESMTP id h2EAehMM011005 for <[e-mail]>; Fri, 14 Mar 2003 18:40:44 +0800 (CST)
Received: (from root@localhost) by ms6.chttl.com.tw (8.12.1/8.12.1) id h2EAeVM5005007 for [e-mail]; Fri, 14 Mar 2003 18:40:31 +0800
Received: from wcwang ([10.144.133.79]) by ms6.chttl.com.tw (8.12.1/8.12.1) with SMTP id h2EAeUbh004970 for <[e-mail]>; Fri, 14 Mar 2003 18:40:31 +0800
Message-ID: <019301c2ea16$32c7a500$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: <[e-mail]>
Subject: Distribution Point Name Matching Rule?
Date: Fri, 14 Mar 2003 18:40:58 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

In CRL processing/validation specified by both RFC 3280
and the X.509 standards, there is a requirement to at least 
match one of names (if any) in the distribution point name
field of the IDP extension of the CRL to one of the names in the
distribution point name of the CRLDP extension of the certificate.

However, it seems that neither RFC 3280 nor the X.509
standard specify the distribution point name matching rule.
Does the names need to be exactly matched? What about
case sensitivibility or whitespace ignorability?

Since both distribution point names are of GeneralNames type,
I believe that the matching rule for AuthorityAltName and
SubjectAltName could be applied to the distribution point name
matching. However, if so, please say so in the text.

It seems that we need a special section in the RFC to specify
the matching rules for GeneralNames. And then the text could
simply say that those matching rules can applied to anywhere two
GeneralNames are required to be matched.

-----
Wen-Cheng Wang
Project Researcher
Telecommunication Laboratories
Chunghwa Telecom Co., Ltd

 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2EA3LP18666 for ietf-pkix-bks; Fri, 14 Mar 2003 02:03:21 -0800 (PST)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2EA3Jg18661 for <[e-mail]>; Fri, 14 Mar 2003 02:03:20 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailb.telia.com (8.12.8/8.12.8) with SMTP id h2EA39S4012601; Fri, 14 Mar 2003 11:03:09 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <005301c2ea0f$6c402f70$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Richard Levitte - VMS Whacker" <[e-mail]>
Cc: <[e-mail]>, "Santosh Chokhani" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <006601c2e85f$69053000$0500a8c0@arport> <[e-mail]>            <008501c2e92e$d5de5380$0500a8c0@arport> <[e-mail]>
Subject: Re: Certificate Policies
Date: Fri, 14 Mar 2003 10:52:22 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: 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 Richard,

>A policy implies what is written in it (in the CP and the CPS).
>There's nothing in a policy OID that can tell you what the function or
>the legality of the policy is, you have to read the documents and
>decide that for yourself accordingly.

So far, I am with you.

Now assuming that a single CA key/cert can create N different
policies applied to M different EE-certificates, you get a potentially
unmanageable legal/function matrix.

BTW, why do some people believe that you need a lot of 
different policies?  To keep legal departments busy?  Why do
you actually need more than one within a given "trust-network"?

It would be very interesting to see what purposes all this
stuff is supposed to fill in application software.

            Architecture?

            Data model?

            Links?

I occasionally look on this in a slightly "philosophical" way:
If one large user like DoD, deploys "something" but the rest of 
the market does not, using my thinking, it was a failure for this 
"something" (and long-term also for the DoD).

As not even X.500 directories and LDAP are sacred anymore
http://www.imc.org/ietf-pkix/mail-archive/msg05571.html ,
it seems that PKI technology is still to be regarded as being
highly immature.  That is, your answer is as good as mine.
And vice versa :-)

Unless somebody provides some more facts regarding PE usage
in application software, I suggest that we halt this thread a while,
and let the market do the final selection...

Anders





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2E8CWk03386 for ietf-pkix-bks; Fri, 14 Mar 2003 00:12:32 -0800 (PST)
Received: from atsgw.cyber.ee (atsgw.cyber.ee [195.50.202.13]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2E8CVg03382 for <[e-mail]>; Fri, 14 Mar 2003 00:12:31 -0800 (PST)
Received: Message by Barricade atsgw.cyber.ee  with ESMTP id h2E8CUd10328; Fri, 14 Mar 2003 10:12:30 +0200
Message-ID: <[e-mail]>
Date: Fri, 14 Mar 2003 10:12:29 +0200
From: Margus Freudenthal <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: ee,et,en
MIME-Version: 1.0
To: Al Arsenault <[e-mail]>
CC: [e-mail]
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)
References: <007f01c2e75f$4b93ec10$2d00a8c0@Chokhani> <[e-mail]> <00b401c2e7ff$183fb420$0500a8c0@arport> <[e-mail]> <006601c2e85f$69053000$0500a8c0@arport> <[e-mail]> <[e-mail]> <007b01c2e96e$81e4b900$6501a8c0@SJOSEPH>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-info: Headers changed by Barricade
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Al Arsenault wrote:
> 
> >From a technical standpoint, typically nothing prevents this.  It's not
> commonly done because:
> 
>     a.  There's more of a management problem; e.g., if the key is ever
> compromised for whatever reason, you have to track down ALL of the
> certificates it was bound to and revoke them;  and
> 
Each certificate that is issued to you brings along some kind of
liability (documents signed using that certificate are considered to be
signed by you). Therefore you'd be crazy not to keep track of all your
certificates/liabilities.



-- 
Margus


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2E2BA713474 for ietf-pkix-bks; Thu, 13 Mar 2003 18:11:10 -0800 (PST)
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2E2B7g13467 for <[e-mail]>; Thu, 13 Mar 2003 18:11:08 -0800 (PST)
Received: from ms7.chttl.com.tw (ms7 [10.144.2.117]) by fw.chttl.com.tw (8.12.8/8.11.6) with ESMTP id h2E29o0L023516 for <[e-mail]>; Fri, 14 Mar 2003 10:09:51 +0800 (CST)
Received: (from root@localhost) by ms7.chttl.com.tw (8.12.3/8.12.1) id h2E28Yiw022205 for [e-mail]; Fri, 14 Mar 2003 10:08:34 +0800
Received: from wcwang ([10.144.133.79]) by ms7.chttl.com.tw (8.12.3/8.12.1) with SMTP id h2DFhVcU020327 for <[e-mail]>; Thu, 13 Mar 2003 23:43:51 +0800
Message-ID: <008501c2e977$8e8535f0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: <[e-mail]>
Subject: Will IDP syntax and semantics be changed in the future?
Date: Thu, 13 Mar 2003 23:45:02 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

Recently, I download the pre-published Technical Corrigendum 3 of X.509
4th edition (the prepublished X.509 TC3) from ITU-T website. The content
of the prepublished X.509 TC3 is mainly for correcting defect related to
CRL processing/validation. I do not know how soon the prepublished X.509
TC3 will come in force. However, I believe that, once it become in force, it
will introduce some conflicts between RFC 3280 and X.509 standards.
The syntax and semantics of Issuing Distribution Point
extension are different between RFC 3280 and the prepublished X.509
TC3 .

In RFC 3280, the definition of the IssuingDistributionPoint is as follows:
    IssuingDistributionPoint ::= SEQUENCE {
         distributionPoint    [0] DistributionPointName OPTIONAL,
         onlyContainsUserCerts    [1] BOOLEAN DEFAULT FALSE,
         onlyContainsCACerts    [2] BOOLEAN DEFAULT FALSE,
         onlySomeReasons    [3] ReasonFlags OPTIONAL,
         indirectCRL    [4] BOOLEAN DEFAULT FALSE,
         onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE }
(Note there is a typo in RFC 3280, the beginning "i" of
"issuingDistributionPoint" should be capitalized.)

In the prepublished X.509 TC 3 , the new definition is as follows:
    IssuingDistPointSyntax ::= SEQUENCE {
        distributionPoint   [0] DistributionPointName OPTIONAL,
        containsUserPublicKeyCerts [1] BOOLEAN DEFAULT FALSE,
        containsCACerts   [2] BOOLEAN DEFAULT FALSE,
        onlySomeReasons   [3] ReasonFlags OPTIONAL,
        indirectCRL    [4] BOOLEAN DEFAULT FALSE,
        containsUserAttributeCerts [5] BOOLEAN DEFAULT FALSE,
        containsAACerts   [6] BOOLEAN DEFAULT FALSE,
        containsSOAPublicKeyCerts [7] BOOLEAN DEFAULT FALSE }
(Note that the data type name is different, but it represents the same
thing.)
The most obvious change made by the prepublished X.509 TC 3 is that it
expands the onlyContainsAttributeCerts flag to two flags, namely
"containsUserAttributeCerts" and "containsAACerts", and it add another flag

named "containsSOAPublicKeyCerts" specifically for indicating whether the
set of certificates covered by the CRL contains the public-key certificates
of SOAs. Since these are PMI-related flags, the change of them are less
related to RFC 3280.
What we should note is that the remove of the adverb "only" from the
"onlyContainsUserCerts" flag and the "onlyContainsCACerts" flag. IMHO, the
remove of the adverb "only" from these flags not only changes the syntax but
also only changes the semantics. In RFC 3280, since the exist of the adverb
"only", these flags are exclusive to each other. That is, the
"onlyContainsUserCerts" flag and the "onlyContainsCACerts" flag cannot be
both set to TRUE at the same time. However, in the new definition, these
flags are not exclusive to each other anymore. That is, the
"containsUserPublicKeyCerts" flag and the "containsCACerts" flag can be both
set to TRUE at the same time. It seems that the semantics of these flags is
changed.

In RFC 3280, the semantics of these flags is as follows:
1. The onlyContainUserCerts flag indicates "whether the CRL scope ONLY
    covers EE certificates".
2. The onlyContainsCACerts flag indicates "whether the CRL scope ONLY
    covers CA certificates".
However, in the new definition, the semantics of these flags is as follows:
1. The containUserCerts flag indicates "whether the CRL scope covers EE
    certificates".
2. The containsCACerts flag indicates "whether the CRL scope covers CA
    certificates".
Fortunately, the default value of these flags are both FALSE, so that the
effect of letting one flag set to TRUE and the other flag set to FALSE or be
absent seems to be backward compatible to RFC 3280 and the original X.509
standards because:
1. a CRL with containUserCerts flag set to true and with containsCACerts
    absent means that its scope covers EE certificates but does not cover CA
    certificates; (That is, its scope only covers EE certificates.)
2. a CRL with containCACerts flag set to true and with containsUserCerts
    absent means that its scope covers CA certificates but does not cover EE
    certificates. (That is, its scope only covers CA certificates.)

The problem is that if containUserCerts flag and containsCACerts flag are
both absent, the accoding to the new semantics that will means the the scope
of the CRL does not cover both EE certificates and CA certificates since the
default value of these two flags are both FALSE. That is conflict with RFC
3280 and the original X.509 standard.

However, I believe that the author of the prepublished X.509 TC 3
also noticed the problem so that for maintaining back compatibility with
RFC 3280 and the original X.509 standard, the prepublished X.509 TC 3
specially specifies "if all these flags are absent, it indicates that the
CRL
scope covers both EE certificates and CA certificates". Unfortunately,
that is conflict with X.680 and X.690 standards. The ASN.1 rule is
"if the field has DEFAULT value and the field is absent, the DEFAULT
value is applied to the field".

With the new definition of IDP extension, to indicate that the CRL
scope covers both EE certificates and CA certificates, both flags
need to be set to TRUE. However, the the original definition, the
"onlyContainsUserCerts" flag and the "onlyContainsCACerts" flag cannot be
both set to TRUE at the same time since they are exclusive to each other.

Any comment?

-----
Wen-Cheng Wang
Project Researcher
Telecommunication Laboratories
Chunghwa Telecom Co., Ltd




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DLqMj02050 for ietf-pkix-bks; Thu, 13 Mar 2003 13:52:22 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DLqKg02033 for <[e-mail]>; Thu, 13 Mar 2003 13:52:20 -0800 (PST)
Subject: Re: Certificate Policies (addenda)
To: [e-mail]
Cc: Al Arsenault <[e-mail]>, [e-mail], Margus Freudenthal <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 13 Mar 2003 14:41:06 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 03/13/2003 04:53:34 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

note something related was discussed in sci.crypt regarding certification
of quality:
http://www.garlic.com/~lynn/2003d.html#71 SSL/TLS DHE suites and hsort
exponents

aka CA basically certifies the validity of some assertion in the
certificate. there has been little or no activity in the area of quality.
One is tempted to mention the joke in risks forum this week about the
person lost in a ballon
http://catless.ncl.ac.uk/Risks/22.63.html

we had been somewhat involved in the most prevalent certification in the
world today ... aka SSL domain name certificates for e-commerce:
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

at the time, included having to perform due dilligence visits on the major
certification players for SSL domain name certificates for e-commerce.

we strived to get some quality issues introduced into the certification
process with no success.

a significant issue is/was that certificates are primarily a pardigm for
offline, stale, static data. Risk and trust management has been moving the
state-of-the-art to a timely, dynamic data paradigm .... and it is
trivially shown that any environment that supports timely, dynamic data
paradigm ... also supports stale, static data as a subset. It wasn't so
much that there weren't any players in the risk & trust management arena
.... is was that they had just about all moved into a timely, dynamic data
paradigm. While it is possible to proove that a infrastructure that
involves timely, dynamic data .... can support as a subset all the
characteristics of stale, static data .... it is not possible to proove
that an offline, static, stale paradigm subsumes timely, dynamic data ....
aka in a paradigm with timely, dynamic data it is trivial to show that
offline, static, stale certificates are redundant and superfluous.

By comparison the certification authorities are just looking to certify
some assertions regarding static, stale data (usely by checking with some
totally different organization that is actually responsible for the
accuracy of the assertions).

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DHUih25375 for ietf-pkix-bks; Thu, 13 Mar 2003 09:30:44 -0800 (PST)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com (nymelsmtp01.firstdata.com [198.184.0.23]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DHUg325363 for <[e-mail]>; Thu, 13 Mar 2003 09:30:42 -0800 (PST)
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)
To: Al Arsenault <[e-mail]>
Cc: [e-mail], Margus Freudenthal <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 13 Mar 2003 10:30:48 -0700
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 03/13/2003 12:31:54 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

a similar argument was used with regard to plastics cards turned smartcards
.... however the most common failure was lost/stolen wallet containing all
such cards. there was absolutely no difference with management issues
whether there was a signle card or multiple cards .... for the most common
failure/exploit.

postulated was that the next most common failure (fraud, exploit,
availability, etc) might be hardware failure. however, the hardware failure
scenarios statistics didn't mandate a one-for-one mapping between token &
function .... it would just indicate that some might want
no-single-point-of-failure (two tokens, or at most three).

I would assert that if you need/require multiple certificates .... that
there is effectively nearly the same management process ... regardless of
whether a single key or multiple keys are involved.  You have to a mapping
between key to which certificate .... whether it is one-to-one or
one-to-many .... and you have to have a notification process for each
certificate. The issue then isn't the management of the information .... it
is just how many that might have to be notified for each key compromise ...
not the management problem of keeping track of all that might have to be
notified. It is slightly different if the information hasn't been managed
and it is necessary to reconstruct it after a compromise ... then if there
is only a one-to-one mapping .... then the scope of reconstruction may not
be as bad ... since the search for key-to-certificate mapping stops after
the correct certificate has been identified ... and the search for
notification process stops ... after the process for the specific
certificate is found.

issue with regard multiple or single key compromise .... would be if the
compromise modes have common components. For instance are all private keys
carried in the same hardware token or same encrypted file. If the most
common compromise/failure mode for keys .... are common multiple key
failure ... aka attack on encrypted file containing all private keys ....
then all certificates have to be revoked .... regardless of whether there
is a one-to-one policy or a one-to-many policy is allowed (aka similar to
the most common failure mode for cards .... the lost/stolen of wallet/purse
... where all cards are taken .... and there is no differentiation in this
failure mode whether there were single card or multiple cards .... all
cards fail). semantic note: "common" is used in the sense of "most
frequent" ... as well as the sense of "affectiing all keys".

I would also strongly assert that many policies are left over from
shared-secret key policies .... each infrastructure requiring a unique key
because of vulnerabilities specifically associated with shared-secret key.

I would contend that many of the vulnerabilities significantly changed
transitioning from shared-secret key infrastructure to public key
infrastructure .... and the vulnerability thresholds needed for various
organizations would still be met if the same public key were used in
different infrastructures ... aka many infrastructures never bothered
really redoing failure/vulnerability analysis. Possibly in the transition
from shared-secret to public; some bureaucrat just says that there is a
policy regarding keys .... and of course all keys are the same.
Bureaucratic policies have a life of their own.

--
Internet trivia, 20th anv: http://www.garlic.com/~lynn/rfcietff.htm


Al Arsenault <[e-mail]> on 3/13/2003 7:40 am wrote:

><snip>
> * When using multiple CA-s, what prevents you from issuing multiple
> certificates to the same key?
>

>From a technical standpoint, typically nothing prevents this.  It's not
commonly done because:

    a.  There's more of a management problem; e.g., if the key is ever
compromised for whatever reason, you have to track down ALL of the
certificates it was bound to and revoke them;  and

    b.  Policies typically restrict it.

But it could easily be done (and has in some specialized cases).

                Al Arsenault
                Chief Security Architect
                Diversinet Corp.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DGeTx22163 for ietf-pkix-bks; Thu, 13 Mar 2003 08:40:29 -0800 (PST)
Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DGeR322159; Thu, 13 Mar 2003 08:40:28 -0800 (PST)
Received: (from root@localhost) by fw1.gdm.de (8.11.6/8.11.6) id h2DGeBF03136; Thu, 13 Mar 2003 17:40:11 +0100 (CET)
Received: (from localhost) by fw1.gdm.de (MSCAN) id 2/fw1.gdm.de/smtp-gw/mscan; Thu Mar 13 17:40:10 2003
Subject: Antwort: Re: Certificate Policies (was Re: Trivial PKI Question)
To: "Anders Rundgren" <[e-mail]>
Cc: "Santosh Chokhani" <[e-mail]>, [e-mail], [e-mail], [e-mail], "Steve Hanna" <[e-mail]>
X-Mailer: Lotus Notes Release 5.07a  May 14, 2001
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 13 Mar 2003 11:18:06 +0100
X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 6.0|September 26, 2002) at 13.03.2003 17:39:51
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Maybe I got your point: certificate policies are useless without agreement
on the meaning of specific policy-OIDs and it is hard to establish such a
meaning in most cases.

However, not in all cases. The way europe deals with qualified signatures
looks like an issue where the certificate policy extension may be useful.
One may look at the EU directive on qualified signatures and the various
national laws implementing the directive in the member states as
standardized policies, granting certain features to a relying party. E.g.
the EU directive grants to a relying party that the private key is well
protected on a secure device and that the issuer of the certificate is
liable for the correctness of the content of the certificate and you can
identify uniquely a person related to the certificate and so on. The german
signature law grants all this and furthermore that electronic documents
carrying a qualified signature are treated as strong evidence in a german
court in almost the same way a written contract on paper is. So if a
relying party is interested in obtaining electronic documents that it may
use later like contracts it will ask for those features. It can do so by
checking for the presence of a standardized policy-OID.

A certificate policy extension with a standardized OID in it grants
specific features. Multiple policy extensions may grant different features
which is fine as long as those features are not in contradiction to each
other. A proper way to use certificate policy extension within the european
framework of qualified signatures would be to insert an identifier for
"adhering to the EU-directive" (ETSI did define one) and an additional
identifier for "adhering to the xyz member state law on this" (in Germany
an OID for this is defined).  So a relying party can ask for qualified
certificates in general or for qualified certificates with special
additional features as granted by national law. One can say it can ask for
a "car" or ask for a "green car". Looking more closely at it one may as
well use the tree-like organization of OIDs to construct policy-OIDs in an
OOP-like manner.

Of course the RP still has to decide which CAs to accept or not and
configure its trusted certificate repository accordingly. So if the RP is
interested in obtaining qualified signatures it may as well do this by
applying marks to the CAs stored in its trusted certificate repository, as
long as there is one-to-one relationship between a trusted CA key and a
policy. However I believe that proper usage of standardized policy-OID by
CAs would reduce the amount of configuration work at relying parties and
may help to avoid catch 22s in some cases.

Conclusion: a certificate policy extension is useful if standardized
policy-OIDs do exist .



                                                                                                                                        
                      "Anders Rundgren"                                                                                                 
                      <anders.rundgren@         An:      "Steve Hanna" <[e-mail]>                                            
                      telia.com>                Kopie:   "Santosh Chokhani" <[e-mail]>, <[e-mail]>,     
                      Gesendet von:             <[e-mail]>                                                                     
                      owner-ietf-pkix@m         Thema:   Re: Certificate Policies (was Re: Trivial PKI Question)                        
                      ail.imc.org                                                                                                       
                                                                                                                                        
                                                                                                                                        
                      13.03.2003 08:04                                                                                                  
                                                                                                                                        
                                                                                                                                        





Steve,
As PKI is too complex not only for IS-departments, but
even for [all of] us who claim we are experts on the subject,
I only take out one item, although a "favorite" :-)

>> - What do these policies imply (function: web-server/e-mail or
>>   legal: hi-value/lo-value)? This is IMO a pretty broken part
>>   of  policy extensions.  And very hard to "repair" as well

>As RFC 2527 and X.509 say, a certificate policy typically
>"indicates the applicability of a certificate to a particular
>community and/or class of application with common security
>requirements." Among other things, it might say what applications
>the certificate can be used for or what warranties are provided.
>So both "function" and "legal", in your terms.

>Could you elaborate on why you think this is broken?

Regardless of what I think of policy extensions I would
never mix information that does not belong to each other.
This is semantic overloading (AKA "smart" coding).
It _seems_ like a revision in "legal" would affect "function"
as well, as they are expressed as a single object.   This is
what I, while wearing my system architect cap, would
characterize as "broken beyond repair".

If I'm wrong here please pardon me, I do not claim to be
an expert in _this_ particular area of PKI.

Anders









Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DG0ls20883 for ietf-pkix-bks; Thu, 13 Mar 2003 08:00:47 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DG0k320879 for <[e-mail]>; Thu, 13 Mar 2003 08:00:46 -0800 (PST)
Received: from nomad.OpenLDAP.org (kurt@localhost [127.0.0.1]) by pretender.boolean.net (8.12.8/8.12.8) with ESMTP id h2DG0kCa073136 for <[e-mail]>; Thu, 13 Mar 2003 16:00:46 GMT (envelope-from [e-mail])
Message-Id: <5.2.0.9.0.20030313075456.02b95410@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 13 Mar 2003 07:58:55 -0800
To: [e-mail]
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: LDAP DN: "static table" v. "registry" approach discussions on the LDAPBIS list
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Today I (as editor) posted the following question to the LDAPBIS list:

  Should the WG pursue the "registry" approach as discussed in
  draft-zeilenga-ldapbis-rfc2253 in favor of the "static table"
  approach discussed in draft-ietf-ldapbis-dn?

PKIX'ers who care to comment on the question are encouraged
to post them to the LDAPBIS WG list <[e-mail]>.

The question will also be discussed during the LDAPBIS session
at IETF#56.

Kurt



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DEfoD18058 for ietf-pkix-bks; Thu, 13 Mar 2003 06:41:50 -0800 (PST)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DEfn318054 for <[e-mail]>; Thu, 13 Mar 2003 06:41:49 -0800 (PST)
Received: from SJOSEPH (pcp239416pcs.elictc01.md.comcast.net [68.55.244.2]) by mtaout04.icomcast.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with SMTP id <[e-mail]> for [e-mail]; Thu, 13 Mar 2003 09:41:45 -0500 (EST)
Date: Thu, 13 Mar 2003 09:40:35 -0500
From: Al Arsenault <[e-mail]>
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)
To: Margus Freudenthal <[e-mail]>, [e-mail]
Message-id: <007b01c2e96e$81e4b900$6501a8c0@SJOSEPH>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <007f01c2e75f$4b93ec10$2d00a8c0@Chokhani> <[e-mail]> <00b401c2e7ff$183fb420$0500a8c0@arport> <[e-mail]> <006601c2e85f$69053000$0500a8c0@arport> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message -----
From: "Margus Freudenthal" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, March 13, 2003 3:54 AM
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)


><snip>
> * When using multiple CA-s, what prevents you from issuing multiple
> certificates to the same key?
>

>From a technical standpoint, typically nothing prevents this.  It's not
commonly done because:

    a.  There's more of a management problem; e.g., if the key is ever
compromised for whatever reason, you have to track down ALL of the
certificates it was bound to and revoke them;  and

    b.  Policies typically restrict it.

But it could easily be done (and has in some specialized cases).

                Al Arsenault
                Chief Security Architect
                Diversinet Corp.





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2DCRHi06264 for ietf-pkix-bks; Thu, 13 Mar 2003 04:27:17 -0800 (PST)
Received: from nic.lp.se (nic.lp.se [212.247.5.91]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2DCRF306259 for <[e-mail]>; Thu, 13 Mar 2003 04:27:15 -0800 (PST)
Received: from localhost (212.247.5.91) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Thu, 13 Mar 2003 13:25:36 +0100
Date: Thu, 13 Mar 2003 13:25:04 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Certificate Policies
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <008501c2e92e$d5de5380$0500a8c0@arport>
References: <006601c2e85f$69053000$0500a8c0@arport> <[e-mail]> <008501c2e92e$d5de5380$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.2, Mew version 3.2
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 3.2 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <008501c2e92e$d5de5380$0500a8c0@arport> on Thu, 13 Mar 2003 08:04:48 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> 
anders.rundgren> Steve,
anders.rundgren> As PKI is too complex not only for IS-departments, but
anders.rundgren> even for [all of] us who claim we are experts on the subject,
anders.rundgren> I only take out one item, although a "favorite" :-)
anders.rundgren> 
anders.rundgren> >> - What do these policies imply (function:
anders.rundgren> >>   web-server/e-mail or legal: hi-value/lo-value)?
anders.rundgren> >>   This is IMO a pretty broken part of  policy
anders.rundgren> >>   extensions.  And very hard to "repair" as well

A policy implies what is written in it (in the CP and the CPS).
There's nothing in a policy OID that can tell you what the function or
the legality of the policy is, you have to read the documents and
decide that for yourself accordingly.

The way I see it, it's not much different from reading the license
that comes with a program, be it the Microsoft EULA, the GPL or
whatever...  Or you might parallell it to contracts, if you feel
better about that.  Either way, you have to read them to know what
they imply, no software in the world will do that for you.

It seems like you want the implication of a contract (in this case,
certificate policies) to be determined programatically.  I believe
that's a mistake.

anders.rundgren> Regardless of what I think of policy extensions I
anders.rundgren> would never mix information that does not belong to
anders.rundgren> each other.  This is semantic overloading (AKA
anders.rundgren> "smart" coding).  It _seems_ like a revision in
anders.rundgren> "legal" would affect "function" as well, as they are
anders.rundgren> expressed as a single object.   This is what I, while
anders.rundgren> wearing my system architect cap, would characterize
anders.rundgren> as "broken beyond repair".

Uhmm, to reuse the license or contract model, they are also documents
that combine function and legality.  Are they also broken beyond
repair?

But fine, I've no problem seeing having to write a legal document and
a functional document if it came down to that.  What makes you think
I'd not have them constantly combined in whatever certificate I decide
to create, more or less as if they were a single document?  Also, what
are the implications for such a scheme when validating a certificate?
Currently, all policies along the path are regarded as single entities
that may apply alone with no regard for the other policies that may
appear on the way.  If combined policies became the thing to do, how
would validation software know what policies should be kept combined?
And oh, are those combinations only pairs, or can we have combinations
of three policy documents?  As you can see, this leads to another can
of worms, and I doubt that's what you wanted, so I'll assume I
misunderstand you and let you explain what you were thinking...

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


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2D8svw16185 for ietf-pkix-bks; Thu, 13 Mar 2003 00:54:57 -0800 (PST)
Received: from atsgw.cyber.ee (atsgw.cyber.ee [195.50.202.13]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2D8st316177 for <[e-mail]>; Thu, 13 Mar 2003 00:54:55 -0800 (PST)
Received: Message by Barricade atsgw.cyber.ee  with ESMTP id h2D8ssJ24854 for <[e-mail]>; Thu, 13 Mar 2003 10:54:54 +0200
Message-ID: <[e-mail]>
Date: Thu, 13 Mar 2003 10:54:53 +0200
From: Margus Freudenthal <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: ee,et,en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)
References: <007f01c2e75f$4b93ec10$2d00a8c0@Chokhani> <[e-mail]> <00b401c2e7ff$183fb420$0500a8c0@arport> <[e-mail]> <006601c2e85f$69053000$0500a8c0@arport> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-info: Headers changed by Barricade
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Although I'm not implementing or planning to implement certificate
policy support, I would like to make some points from programmer's point
of view.

Steve Hanna wrote:
> 
> > - What does separate CA networks mean more than multiple keys
> >   (which should be piece of cake if you have proper CA SW)?
> 
> This is the system currently used by most commercial CAs.
> They typically have a separate root CA for each class of
> certificates (certificate policy). This root CA may certify
> subordinate CAs, which are also typically separated by class
> of certificate. Not only do you need a separate key pair
> for each class of certificate, you typically use a different
> CA name and have a separate set of CRLs. And, of course, the
> number of trust anchors in relying party software increases
> by a factor equal to the number of policies.
> 
* Certificate policy is also trust anchor, just like CA key (in fact,
all information that is used as input to certificate verification
procedure (besides cert chain itself) is trust anchor). In one case you
have to rely on several CA keys, in the other case you have one CA key
and several policy identifiers.

* When using multiple CA-s, what prevents you from issuing multiple
certificates to the same key?


-- 
Margus


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2D8oRD15334 for ietf-pkix-bks; Thu, 13 Mar 2003 00:50:27 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2D8oP315330 for <[e-mail]>; Thu, 13 Mar 2003 00:50:25 -0800 (PST)
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA20792; Thu, 13 Mar 2003 09:52:57 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id IAA14328; Thu, 13 Mar 2003 08:46:34 +0100
Message-ID: <[e-mail]>
Date: Thu, 13 Mar 2003 09:50:17 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: "'Stefan Santesson'" <[e-mail]>
CC: Sharon Boeyen <[e-mail]>, [e-mail]
Subject: Re: QC Declaration
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

I support Sharon's point of view.
No change should be done.

In general, I am *not* convinced that changes really need to be done
to RFC 3039. We need stable documents.

Denis

> It would have been compliant IF the semantics of the extension stated 
> that. However, the semantics of the extension dictate the opposite where 
> ALL statements are critical.
> 
>     -----Original Message-----
>     From: Stefan Santesson [mailto:[e-mail]]
>     Sent: Tuesday, March 11, 2003 4:49 PM
>     To: Sharon Boeyen; [e-mail]
>     Subject: RE: QC Declaration
> 
>     Sharon,
> 
>     The first step for me is to get the mechanics right.
> 
>     Are you saying that it would have been compliant with X.509 to
>     declare that a critical QCStatement (disregarding the current
>     declaration in RFC 3039) is valid if I can process at least one of
>     the present statements (similar to SubjectAltName).
> 
>     Not that I claim that it would be a good idea.
> 
>     /Stefan
> 
> 
>     At 16:30 2003-03-11 -0500, Sharon Boeyen wrote:
> 
>>     I don't want to get off on a non-relevant tangent regarding
>>     criticality, but think I do need to clarify a little bit on the
>>     subject Alt Name extension. If you check 8.3.2.3 (509) you'll find
>>     that the semantics of that extension are such that, if set to
>>     critical, "at least one of the name forms that is present shall be
>>     recognized and processed ...". So if, in your example, the ONLY
>>     name present in subjectAltName extension is the unknown otherName
>>     OID, then you are correct and the certificate shall be considered
>>     invalid. If however, that unknown otherName OID was present AND
>>     and rfc822Name was present - the RP might understand the
>>     rfc822Name and check it against the intended recipient of an
>>     encrypted email for example, and under those circumstances the
>>     certificate would be valid, even though the extension was critical
>>     and there was another nameform in there that was not understood.
>>      
>>     I suspect that its probably a bit too soon to profile the kind of
>>     contexts I think you're describing in 3039. I'd prefer to see a
>>     bit more practical use of QCs first so that we have a better
>>     handle on what constitutes a "context". For example, perhaps one
>>     context is with the ETSI qcstatement 1 plus a specific national qc
>>     statement and if both are present in a certificate that some
>>     'authority' (I don't mean a CA here) deems that when that
>>     combination is present the extension shall be set to critical. I'm
>>     not necessarily opposing the idea, just a little uncomfortable
>>     with the proposed timing without significant real world deployment
>>     to guide us with to the appropriate 'contexts'.
>>      
>>     Cheers,
>>     Sharon
>>
>>         -----Original Message-----
>>         From: Stefan Santesson [mailto:[e-mail]]
>>         Sent: Tuesday, March 11, 2003 4:06 PM
>>         To: Sharon Boeyen; Sharon Boeyen; [e-mail]
>>         Subject: RE: QC Declaration
>>
>>         Sharon,
>>         Thanks for the clarification.
>>
>>         "Elements of the syntax" really clarifies things.
>>
>>         So it is OK to accept an certificate with a critical policy
>>         extension containing an policy OID that I don't recognize,
>>         because it doesn't define any further syntax of the extension.
>>         The same goes with Extended key usage OIDs.
>>
>>         However. It would not be OK with a critical subjectAltName
>>         containing an unknown other name OID, since this OID would
>>         define further syntax.
>>         By the same reason I would need to understand all present
>>         QCStatements OIDs, because they do the same (define further
>>         syntax).
>>
>>
>>         Let me clarify that I never proposed that the QCStatement must
>>         be critical in all certificates.
>>         I'm just recognizing that it might be a valuable practice
>>         within certain contexts and the fact that some implementers
>>         actually ask for it.
>>         The question is whether any of those contexts can be
>>         identified within RFC 3039, or if they are better placed in
>>         local sub-profiles (Such as ETSI TS 101862), or if they don't
>>         exist in a way that can be standardized in a meaningful way.
>>
>>
>>         /Stefan
>>
>>
>>         At 11:37 2003-03-11 -0500, Sharon Boeyen wrote:
>>
>>>             Hi Stefan,
>>>
>>>               Remember first that RFC 3280 is a "profile" of X.509
>>>             and it does not replace the requirements of 509, but
>>>             rather profiles them to a subset.
>>>
>>>               X.509 in clause 7 allows unknown elements in
>>>             non-critical extensions only to be ignored. However, that
>>>             is more with respect to the elements in the syntax
>>>             itself (for example in the IDP extension no RP is allowed
>>>             to ignore the "onlySomeReasons" element if it is present
>>>             in the extension because the extension
>>>             can only be critical. The behaviour of RPs will differ
>>>             however depending on their specific capability with
>>>             respect to that element (some will use the CRL for
>>>             the specified reasons and others will seek a different
>>>             CRL that covers all reasons), however, no RP is permitted
>>>             to simply ignore the flag. Note also that in that
>>>             same clause, for extensions that can be marked critical
>>>             or non-critical, a system that understands the extension
>>>             is required to process it regardless of the
>>>             value of the criticality flag. It is ONLY systems that do
>>>             not understand an extension that can ignore it completely
>>>             if it is marked non-critical.
>>>
>>>               For the QC Statements extension, RFC 3039 says "This
>>>             extension may be critical or non-critical.  If the
>>>             extension is critical, this means that all statements
>>>             included in the extension are regarded as critical. "
>>>
>>>               Because of the semantics defined for the extension in
>>>             RFC 3039, marking it critical would result in the
>>>             problems I raised.
>>>
>>>             -----Original Message----- From: Stefan Santesson
>>>             [mailto:[e-mail]] Sent: Tuesday, March 11,
>>>             2003 11:23 AM To: Sharon Boeyen; [e-mail]
>>>             Subject: RE: QC Declaration
>>>
>>>             Hi Sharon,
>>>             My interpretation of criticality does not really match yours.
>>>             The only guidance on the meaning of criticality in RFC
>>>             3280 (section 4.2) that I can find is:
>>>
>>>
>>>
>>>  "A certificate using system MUST reject the
>>>
>>>certificate
>>>
>>>
>>>if it encounters a critical extension it does not recognize"
>>>
>>>
>>>             My interpretation is that it is OK to accept a
>>>             certificate if you recognize the extension as such. You
>>>             don't need to understand ALL information that the
>>>             extension contains.
>>>             It seam vital to agree on this issue before we can make
>>>             any conclusion on QCStatament criticality.
>>>             /Stefan
>>>
>>>             At 10:56 2003-03-11 -0500, Sharon Boeyen wrote:
>>>
>>>>                 Hi Stefan,
>>>>                 While I believe that in the longer term certificate
>>>>                 policies will be the optimum way to convey the
>>>>                 necessary information, I acknowledge that QC
>>>>                 Statements is the more popular scheme at present.
>>>>                 Therefore I wouldn't have any problem should this
>>>>                 extension be mandated in RFC 3039.
>>>>                 However, forcing its criticality is going too far I
>>>>                 believe. There is an important difference between
>>>>                 critical and non-critical extensions that we need to
>>>>                 keep in mind from the relying party's perspective.
>>>>                 If there is a non-critical extension that the RP
>>>>                 understands, but that extension includes some
>>>>                 elements that it does not, then the RP is free to
>>>>                 process the parts it does understand and ignore
>>>>                 others. If an extension is critical however, the RP
>>>>                 is required to understand ALL elements within the
>>>>                 extension.
>>>>                 Where I think this can become a problem is the
>>>>                 content of the QC Statements extension. Note that
>>>>                 RFC 3039 and the ETSI profile define DIFFERENT
>>>>                 statements for inclusion in the extension. Also
>>>>                 additional profiles may add their own local
>>>>                 statements and even narrower statements can get
>>>>                 added in specific deployment environments. While the
>>>>                 cert issuer may want to include many of these
>>>>                 statements to enable the cert to be used in various
>>>>                 environments, the RP should only be required to
>>>>                 understand and process the statements that are
>>>>                 appropriate to its own operating environment as
>>>>                 dictated by its local security policy (which could
>>>>                 be different than that under which the CA operated).
>>>>                 Therefore I think requiring it to be critical is
>>>>                 risky. Also requiring that it always be critical
>>>>                 would have interop/backward compatibility issues.
>>>>                 Cheers, Sharon
>>>>
>>>>
>>>>
>>>>                 -----Original Message----- From: Stefan Santesson
>>>>                 [mailto:[e-mail]] Sent: Tuesday, March
>>>>                 11, 2003 8:27 AM To: [e-mail] Subject: QC
>>>>                 Declaration
>>>>
>>>>
>>>>                 The EU directive introduced a requirement on each
>>>>                 CA, issuing QC (Qualified Certificates), to clearly
>>>>                 indicate in these certificate that they are issued
>>>>                 as QC.
>>>>                 ETSI implemented RFC 3039 in relation to the
>>>>                 European electronic signature directive through
>>>>                 their Technical Standard (TS 101862)
>>>>                 TS 101862 specified 2 alternative ways to declare a
>>>>                 certificate as QC.
>>>>                 1) By inclusion of a QCStatements extension 2) By
>>>>                 including a certificate policy identifying this property
>>>>                 Even though solution number 1) is far easier to
>>>>                 handle by applications, since they don't need to
>>>>                 recognize specific QC Policies, ETSI didn't make
>>>>                 solution 1) mandatory or even consider making it
>>>>                 critical, due to lack of confidence that clients
>>>>                 would widely deploy this solution. ETSI needed to
>>>>                 define a solution that could work even if no one
>>>>                 choose to implement the new extensions provided by
>>>>                 RFC 3039.
>>>>                 However, It is not feasible to keep clients updated
>>>>                 over time with different QC policies and even those
>>>>                 policies that are regarded standardized may be
>>>>                 updated with change of OID as a result. It would be
>>>>                 devastating if we can't update a QCP because that
>>>>                 would force an OID update and that would render
>>>>                 certificates useless because clients learned to
>>>>                 recognize only the old OID. This would be to build
>>>>                 in a new root certificate problem into the platforms.
>>>>                 My observations is that times have changed. I have
>>>>                 seen clear indications that market players want, and
>>>>                 even require for interoperability reasons, that use
>>>>                 QCStatements solution is made mandatory and maybe
>>>>                 even critical for QC.
>>>>                 Since both RFC 3039, and TS 101862 are up for
>>>>                 revision, it is time to revisit this issue.
>>>>                 I have some questions and proposals:
>>>>                 - Is there any experiences of this issue outside of
>>>>                 Europe. I.e. are there other legal systems that make
>>>>                 use of the same declaration logic as the EU
>>>>                 directive, where the RFC 3039 profile is used fully
>>>>                 or partly as a solution to this issue?
>>>>                 - I would suggest that the QCStatement mechanism is
>>>>                 ought to be a mandatory tool to communicate a
>>>>                 Qualified Status. The question is:     1) whether
>>>>                 this will have enough implementation support to
>>>>                 succeed?     2) whether is best specified in RFC
>>>>                 3039 or in local profiles (such as TS 101862)?    
>>>>                 3) If there could be a clear context defined where
>>>>                 criticality could be allowed or even required?
>>>>                 I would really like feedback from practical
>>>>                 experiences from this issue, as well as constructive
>>>>                 proposals.
>>>>                 /Stefan
>>>>
>>>>
>>>>
>>>>                 /Stefan
>>>>
>>>>
>>>>                 _____________________________ Stefan Santesson, 
>>>>                 Retrospekt AB http://www.retrospekt.com
>>>>             <http://www.retrospekt.com/> [phone] 
>>>
>>>             _____________________________ Stefan Santesson, 
>>>             Retrospekt AB http://www.retrospekt.com
>>>         <http://www.retrospekt.com/> [phone] 
>>
>>
>>     _____________________________
>>     Stefan Santesson,  Retrospekt AB
>>     http://www.retrospekt.com <http://www.retrospekt.com/>
>>     [phone]
> 
>     _____________________________
>     Stefan Santesson,  Retrospekt AB
>     http://www.retrospekt.com <http://www.retrospekt.com/>
>     [phone]
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2D7FYC00726 for ietf-pkix-bks; Wed, 12 Mar 2003 23:15:34 -0800 (PST)
Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2D7FW300718 for <[e-mail]>; Wed, 12 Mar 2003 23:15:33 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maile.telia.com (8.12.8/8.12.8) with SMTP id h2D7FXlU027788; Thu, 13 Mar 2003 08:15:34 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <008501c2e92e$d5de5380$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Steve Hanna" <[e-mail]>
Cc: "Santosh Chokhani" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <007f01c2e75f$4b93ec10$2d00a8c0@Chokhani> <[e-mail]> <00b401c2e7ff$183fb420$0500a8c0@arport> <[e-mail]> <006601c2e85f$69053000$0500a8c0@arport> <[e-mail]>
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)
Date: Thu, 13 Mar 2003 08:04:48 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,
As PKI is too complex not only for IS-departments, but
even for [all of] us who claim we are experts on the subject,
I only take out one item, although a "favorite" :-)

>> - What do these policies imply (function: web-server/e-mail or
>>   legal: hi-value/lo-value)? This is IMO a pretty broken part
>>   of  policy extensions.  And very hard to "repair" as well

>As RFC 2527 and X.509 say, a certificate policy typically
>"indicates the applicability of a certificate to a particular
>community and/or class of application with common security
>requirements." Among other things, it might say what applications
>the certificate can be used for or what warranties are provided.
>So both "function" and "legal", in your terms.

>Could you elaborate on why you think this is broken?

Regardless of what I think of policy extensions I would
never mix information that does not belong to each other.
This is semantic overloading (AKA "smart" coding).
It _seems_ like a revision in "legal" would affect "function"
as well, as they are expressed as a single object.   This is
what I, while wearing my system architect cap, would
characterize as "broken beyond repair". 

If I'm wrong here please pardon me, I do not claim to be
an expert in _this_ particular area of PKI.

Anders






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2D64nj25281 for ietf-pkix-bks; Wed, 12 Mar 2003 22:04:49 -0800 (PST)
Received: from center.kisa.or.kr ([211.252.150.11]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2D64k325277 for <[e-mail]>; Wed, 12 Mar 2003 22:04:47 -0800 (PST)
Received: from foreverkhopri (localhost [127.0.0.1]) by center.kisa.or.kr (8.11.6/8.11.1) with ESMTP id h2D61gR13170; Thu, 13 Mar 2003 15:01:42 +0900 (KST)
From: "Jong-Wook, Park" <[e-mail]>
To: <[e-mail]>
Cc: "Carlisle Adams" <[e-mail]>
Subject: draft-ietf-pkix-rfc2510bis-07.txt : IAK(Initial Authentication Key)
Date: Thu, 13 Mar 2003 15:04:30 +0900
Message-ID: <008501c2e926$6a1ab740$aa0310ac@foreverkhopri>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0086_01C2E971.DA025F40"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0086_01C2E971.DA025F40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello all, 
 
As for the IAK which used for authenticating the sender,
rfc2510bis-07.txt  describes it as follows :
 
   The end entity has an out of band interaction with the CA/RA.  This
   transaction established the shared secret, the referenceNumber and
   OPTIONALLY the distinguished name used for both sender and subject
   name in the certificate template.  It is RECOMMENDED that the shared
   secret be at least 12 characters long.

But it doesn't tell how 12 characters long comes out. If anybody can
tell, please let me know the reason why.
I know this matter on the length of IAK is entirely depends on a
cryptographic problem, not PKI.
However, it would be better to comment some reasons or references, if
any,  relating to the minimal length of IAK.
 
Thanks,
Park.
 
Park, Jong-Wook
 
Security Consultant
 
Korea Information Security Agency
Korea Certification Authority Central
 
4th FL., IT-Venture Tower B/D, 78, Garak-Dong, Songpa-Gu, Seoul, Korea
138-803
Tel : [phone]  
Fax : [phone]
Mobile : [phone]
E-mail :  <mailto:[e-mail]> [e-mail] or
[e-mail] 
 
Visit  <http://www.kisa.or.kr/> http://www.kisa.or.kr or
<http://www.rootca.or.kr/> http://www.rootca.or.kr for more info,
please.
 
Always Thanks !
 
 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>&#47700;&#49884;&#51648;</TITLE>

<META content=3D"MSHTML 6.00.2722.900" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D671591105-13032003><FONT face=3D"Times New =
Roman">Hello all,=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D671591105-13032003><FONT=20
face=3D"Times New Roman"></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D671591105-13032003><FONT face=3D"Times New Roman">As =
for the IAK=20
which used for authenticating the sender,&nbsp; rfc2510bis-07.txt&nbsp;=20
describes it as follows :</FONT></SPAN></DIV>
<DIV><SPAN class=3D671591105-13032003><FONT=20
face=3D"Times New Roman"></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D671591105-13032003><FONT face=3D"Times New =
Roman">&nbsp;&nbsp;=20
The end entity has an out of band interaction with the CA/RA.&nbsp;=20
This<BR>&nbsp;&nbsp; transaction established the shared secret, the=20
referenceNumber and<BR>&nbsp;&nbsp; OPTIONALLY the distinguished name =
used for=20
both sender and subject<BR>&nbsp;&nbsp; name in the certificate =
template.&nbsp;=20
It is RECOMMENDED that the shared<BR>&nbsp;&nbsp; secret be at least 12=20
characters long.<BR></FONT></SPAN></DIV>
<DIV><SPAN class=3D671591105-13032003><FONT face=3D"Times New Roman">But =
it doesn't=20
tell&nbsp;how 12 characters long comes out. <SPAN =
class=3D671591105-13032003><FONT=20
face=3D"Times New Roman">If anybody can tell, please let me know the =
reason=20
why.</FONT></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D671591105-13032003><FONT face=3D"Times New Roman">I =
know=20
this&nbsp;matter on the length of IAK is entirely&nbsp;depends on&nbsp;a =

cryptographic problem, not PKI.</DIV></FONT></SPAN>
<DIV><SPAN class=3D671591105-13032003><FONT=20
face=3D"Times New Roman">However,&nbsp;it would be better to =
comment&nbsp;some=20
reasons or references, if any, &nbsp;relating to the minimal length of=20
IAK.</FONT></SPAN></DIV>
<DIV><SPAN class=3D671591105-13032003></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D671591105-13032003>Thanks,</SPAN></DIV>
<DIV><SPAN class=3D671591105-13032003>Park.</SPAN></DIV>
<DIV><SPAN class=3D671591105-13032003></SPAN>&nbsp;</DIV>
<DIV><FONT face=3DTahoma size=3D4><STRONG>Park, =
Jong-Wook</STRONG></FONT></DIV>
<DIV align=3Dleft>
<DIV align=3Dleft>
<DIV align=3Dleft>
<DIV align=3Dleft><FONT size=3D2><FONT size=3D1><FONT =
face=3D&#44404;&#47548;><FONT=20
face=3D"Times New Roman" =
size=3D3></FONT>&nbsp;</DIV></FONT></FONT></FONT>
<DIV align=3Dleft><FONT face=3DTahoma =
size=3D2>Security&nbsp;Consultant</FONT></DIV>
<DIV align=3Dleft><FONT face=3DTahoma size=3D2><FONT size=3D1><FONT =
face=3DTahoma><FONT=20
face=3D"Times New Roman" =
size=3D3></FONT>&nbsp;</DIV></FONT></FONT></FONT>
<DIV align=3Dleft><STRONG><U><FONT face=3DTahoma><FONT =
color=3D#ff0000>K</FONT>orea=20
<FONT color=3D#ff0000>I</FONT>nformation <FONT =
color=3D#ff0000>S</FONT>ecurity <FONT=20
color=3D#ff0000>A</FONT>gency</FONT></U></STRONG></DIV>
<DIV align=3Dleft><FONT face=3DTahoma size=3D2>Korea Certification =
Authority=20
Central</FONT></DIV>
<DIV align=3Dleft><FONT face=3DTahoma size=3D2><FONT size=3D1><FONT =
face=3DTahoma><FONT=20
color=3D#000000></FONT>&nbsp;</DIV></FONT></FONT></FONT>
<DIV align=3Dleft><FONT face=3DTahoma size=3D2>4th FL., IT-Venture Tower =
B/D, 78,=20
Garak-Dong, Songpa-Gu, Seoul, Korea 138-803</FONT></DIV>
<DIV align=3Dleft><FONT face=3DTahoma size=3D2>Tel : =
[phone]&nbsp;=20
</FONT></DIV>
<DIV align=3Dleft><FONT face=3DTahoma size=3D2>Fax : =
[phone]</FONT></DIV>
<DIV align=3Dleft><FONT face=3DTahoma size=3D2>Mobile : =
[phone]</FONT></DIV>
<DIV align=3Dleft><FONT face=3DTahoma size=3D2>E-mail : </FONT><A=20
href=3D"mailto:[e-mail]"><FONT face=3DTahoma=20
size=3D2>[e-mail]</FONT></A><FONT face=3DTahoma =
size=3D2>&nbsp;or <A=20
href=3D"mailto:[e-mail]">[e-mail]</A> =
</FONT></DIV>
<DIV align=3Dleft><FONT face=3DTahoma size=3D1><FONT size=3D1><FONT =
face=3DTahoma><FONT=20
color=3D#000000></FONT>&nbsp;</DIV></FONT></FONT></FONT>
<DIV align=3Dleft><FONT face=3DTahoma size=3D2>Visit </FONT><A=20
href=3D"http://www.kisa.or.kr/"><FONT face=3DTahoma=20
size=3D2>http://www.kisa.or.kr</FONT></A><FONT face=3DTahoma size=3D2> =
or </FONT><A=20
href=3D"http://www.rootca.or.kr/"><FONT face=3DTahoma=20
size=3D2>http://www.rootca.or.kr</FONT></A><FONT face=3DTahoma =
size=3D2>&nbsp;for more=20
info, please.</FONT></DIV>
<DIV align=3Dleft><FONT face=3DTahoma size=3D2><FONT size=3D1><FONT =
face=3DTahoma><FONT=20
color=3D#000000></FONT>&nbsp;</DIV></FONT></FONT></FONT>
<DIV align=3Dleft><FONT face=3DTahoma><STRONG><EM>Always Thanks=20
!</EM></STRONG></FONT></DIV></DIV></DIV>
<DIV>&nbsp;</DIV></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0086_01C2E971.DA025F40--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CNKDQ14120 for ietf-pkix-bks; Wed, 12 Mar 2003 15:20:13 -0800 (PST)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CNKC314115 for <[e-mail]>; Wed, 12 Mar 2003 15:20:12 -0800 (PST)
Received: from [10.1.70.145] (SSH.BBN.COM [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2CNK45w009024; Wed, 12 Mar 2003 18:20:08 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05111a00ba94f8ba77b9@[128.33.238.253]>
In-Reply-To: <004401c2e72f$b4c03610$0500a8c0@arport>
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]> <[e-mail]> <[e-mail]> <004401c2e72f$b4c03610$0500a8c0@arport>
Date: Wed, 12 Mar 2003 18:20:30 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
Cc: <[e-mail]>, "Stefan Santesson" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 7:06 PM +0100 3/10/03, Anders Rundgren wrote:
>Stefan,
>
>>The conclusion is that in your opinion there is no problem with
>>RFC 3039 with regard to this.
>
>>Personally I have had a hard time see the problem with this.
>>  This was sorted out many years ago and X.520 as even updated to
>>clarify that it was appropriate to accommodate this use, i.e. assigning
>>identifiers to humans. (X.520: "The Serial Number attribute
>>type specifies an identifier, the serial number of an object. ")
>
>I know this but based on private mails the PI advocates still
>think this a bad use of serialNumber.   As you probably don't care
>about PI you have nothing to worry about.
>
>In case you DO care about PI, please show me how YOU would
>apply PI to the following RFC3039 compliant "Swedish" certificate:
>
>DN: CN=John Doe, serialNumber=676767666767, C=SE
>
>Anders
A more appropriate structure for the Subject DN you cite above would be:

	DN: (CN=John Doe, serialNumber=676767666767), C=SE

The SET of common name and serial number is an appropriate terminal 
RDN, based on the tree structure model that underlies X.500 names.

I think we all agree that it is legitimate to have a Subject DN of 
the form cited here. The problem you cited, long ago, is that there 
is no way for an RP to know that this specific DN is also a PI. My 
recollection is that you originally proposed a structure to be 
inserted into a CA cert to indicate that the Subject DNs were PIs. 
However, the proposed structure was deficient, i.e., it did not 
accommodate a wide range of legitimate DN structures. Thus, it was 
not a good approach for a standard.

You repeatedly point to the notion of "existing practices" and 
complain that PKIX standards do not always encompass these practices. 
That's correct. If an existing practice is a good one, one that 
scales well and does not conflict with other PKIX standards, then I 
don't think PKIX has any problem with embracing it, after suitable WG 
evaluation and process.  But, if the practice is a bad one, e.g., it 
has clear technical flaws, then the fact that is is widely used is 
NOT a good basis for endorsing it in a PKIX standard.  That is the 
basis by which we have operated, and I expect we will continue to 
operate.  It is NOT the purpose of this WG to endorse bad ideas put 
forth by vendors, irrespective of market share.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CMuqD13530 for ietf-pkix-bks; Wed, 12 Mar 2003 14:56:52 -0800 (PST)
Received: from vmmr8.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CMun313525 for <[e-mail]>; Wed, 12 Mar 2003 14:56:49 -0800 (PST)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr8.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AII03833; Wed, 12 Mar 2003 17:56:48 -0500 (EST)
Received: from laptop-cpq.retrospekt.com (1Cust171.tnt6.stk3.swe.da.uu.net [213.116.236.171]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ABW80668; Wed, 12 Mar 2003 17:56:42 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 12 Mar 2003 23:56:39 +0100
To: Sharon Boeyen <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: RE: QC Declaration
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_26737626==.ALT"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Thank you Sharon

Now I'm clear about what the situation is.
I'll come back with some reasoning about this issue.

/Stefan

At 15:19 2003-03-12 -0500, Sharon Boeyen wrote:
>It would have been compliant IF the semantics of the extension stated 
>that. However, the semantics of the extension dictate the opposite where 
>ALL statements are critical.
>-----Original Message-----
>From: Stefan Santesson [mailto:[e-mail]]
>Sent: Tuesday, March 11, 2003 4:49 PM
>To: Sharon Boeyen; [e-mail]
>Subject: RE: QC Declaration
>
>Sharon,
>
>The first step for me is to get the mechanics right.
>
>Are you saying that it would have been compliant with X.509 to declare 
>that a critical QCStatement (disregarding the current declaration in RFC 
>3039) is valid if I can process at least one of the present statements 
>(similar to SubjectAltName).
>
>Not that I claim that it would be a good idea.
>
>/Stefan
>
>
>At 16:30 2003-03-11 -0500, Sharon Boeyen wrote:
>>I don't want to get off on a non-relevant tangent regarding criticality, 
>>but think I do need to clarify a little bit on the subject Alt Name 
>>extension. If you check 8.3.2.3 (509) you'll find that the semantics of 
>>that extension are such that, if set to critical, "at least one of the 
>>name forms that is present shall be recognized and processed ...". So if, 
>>in your example, the ONLY name present in subjectAltName extension is the 
>>unknown otherName OID, then you are correct and the certificate shall be 
>>considered invalid. If however, that unknown otherName OID was present 
>>AND and rfc822Name was present - the RP might understand the rfc822Name 
>>and check it against the intended recipient of an encrypted email for 
>>example, and under those circumstances the certificate would be valid, 
>>even though the extension was critical and there was another nameform in 
>>there that was not understood.
>>
>>I suspect that its probably a bit too soon to profile the kind of 
>>contexts I think you're describing in 3039. I'd prefer to see a bit more 
>>practical use of QCs first so that we have a better handle on what 
>>constitutes a "context". For example, perhaps one context is with the 
>>ETSI qcstatement 1 plus a specific national qc statement and if both are 
>>present in a certificate that some 'authority' (I don't mean a CA here) 
>>deems that when that combination is present the extension shall be set to 
>>critical. I'm not necessarily opposing the idea, just a little 
>>uncomfortable with the proposed timing without significant real world 
>>deployment to guide us with to the appropriate 'contexts'.
>>
>>Cheers,
>>Sharon
>>-----Original Message-----
>>From: Stefan Santesson [mailto:[e-mail]]
>>Sent: Tuesday, March 11, 2003 4:06 PM
>>To: Sharon Boeyen; Sharon Boeyen; [e-mail]
>>Subject: RE: QC Declaration
>>
>>Sharon,
>>Thanks for the clarification.
>>"Elements of the syntax" really clarifies things.
>>So it is OK to accept an certificate with a critical policy extension 
>>containing an policy OID that I don't recognize, because it doesn't 
>>define any further syntax of the extension.
>>The same goes with Extended key usage OIDs.
>>However. It would not be OK with a critical subjectAltName containing an 
>>unknown other name OID, since this OID would define further syntax.
>>By the same reason I would need to understand all present QCStatements 
>>OIDs, because they do the same (define further syntax).
>>Let me clarify that I never proposed that the QCStatement must be 
>>critical in all certificates.
>>I'm just recognizing that it might be a valuable practice within certain 
>>contexts and the fact that some implementers actually ask for it.
>>The question is whether any of those contexts can be identified within 
>>RFC 3039, or if they are better placed in local sub-profiles (Such as 
>>ETSI TS 101862), or if they don't exist in a way that can be standardized 
>>in a meaningful way.
>>
>>/Stefan
>>
>>At 11:37 2003-03-11 -0500, Sharon Boeyen wrote:
>>>Hi Stefan,
>>>
>>>Remember first that RFC 3280 is a "profile" of X.509 and it does not 
>>>replace the requirements of 509, but rather profiles them to a subset.
>>>
>>>X.509 in clause 7 allows unknown elements in non-critical extensions 
>>>only to be ignored. However, that is more with respect to the elements 
>>>in the syntax
>>>itself (for example in the IDP extension no RP is allowed to ignore the 
>>>"onlySomeReasons" element if it is present in the extension because the 
>>>extension
>>>can only be critical. The behaviour of RPs will differ however depending 
>>>on their specific capability with respect to that element (some will use 
>>>the CRL for
>>>the specified reasons and others will seek a different CRL that covers 
>>>all reasons), however, no RP is permitted to simply ignore the flag. 
>>>Note also that in that
>>>same clause, for extensions that can be marked critical or non-critical, 
>>>a system that understands the extension is required to process it 
>>>regardless of the
>>>value of the criticality flag. It is ONLY systems that do not understand 
>>>an extension that can ignore it completely if it is marked non-critical.
>>>
>>>For the QC Statements extension, RFC 3039 says "This extension may be 
>>>critical or non-critical.  If the extension is critical, this means that 
>>>all statements
>>>included in the extension are regarded as critical. "
>>>
>>>Because of the semantics defined for the extension in RFC 3039, marking 
>>>it critical would result in the problems I raised.
>>>
>>>-----Original Message-----
>>>From: Stefan Santesson [mailto:[e-mail]]
>>>Sent: Tuesday, March 11, 2003 11:23 AM
>>>To: Sharon Boeyen; [e-mail]
>>>Subject: RE: QC Declaration
>>>
>>>Hi Sharon,
>>>My interpretation of criticality does not really match yours.
>>>The only guidance on the meaning of criticality in RFC 3280 (section 
>>>4.2) that I can find is:
>>>
>>>
>>>
>>>
>>>   "A certificate using system MUST reject the
>>>
>>>
>>>certificate
>>>
>>>
>>>
>>>if it encounters a critical extension it does not recognize"
>>>
>>>My interpretation is that it is OK to accept a certificate if you 
>>>recognize the extension as such. You don't need to understand ALL 
>>>information that the extension contains.
>>>It seam vital to agree on this issue before we can make any conclusion 
>>>on QCStatament criticality.
>>>/Stefan
>>>At 10:56 2003-03-11 -0500, Sharon Boeyen wrote:
>>>>Hi Stefan,
>>>>While I believe that in the longer term certificate policies will be the
>>>>optimum
>>>>way to convey the necessary information, I acknowledge that QC 
>>>>Statements is
>>>>the
>>>>more popular scheme at present. Therefore I wouldn't have any problem 
>>>>should
>>>>this
>>>>extension be mandated in RFC 3039.
>>>>However, forcing its criticality is going too far I believe. There is an
>>>>important
>>>>difference between critical and non-critical extensions that we need to 
>>>>keep
>>>>in
>>>>mind from the relying party's perspective. If there is a non-critical
>>>>extension that
>>>>the RP understands, but that extension includes some elements that it does
>>>>not, then
>>>>the RP is free to process the parts it does understand and ignore 
>>>>others. If
>>>>an extension
>>>>is critical however, the RP is required to understand ALL elements within
>>>>the extension.
>>>>Where I think this can become a problem is the content of the QC 
>>>>Statements
>>>>extension. Note
>>>>that RFC 3039 and the ETSI profile define DIFFERENT statements for 
>>>>inclusion
>>>>in the extension.
>>>>Also additional profiles may add their own local statements and even
>>>>narrower statements can
>>>>get added in specific deployment environments. While the cert issuer may
>>>>want to include many
>>>>of these statements to enable the cert to be used in various environments,
>>>>the RP should only
>>>>be required to understand and process the statements that are 
>>>>appropriate to
>>>>its own
>>>>operating environment as dictated by its local security policy (which 
>>>>could
>>>>be different than
>>>>that under which the CA operated). Therefore I think requiring it to be
>>>>critical is risky.
>>>>Also requiring that it always be critical would have interop/backward
>>>>compatibility issues.
>>>>Cheers,
>>>>Sharon
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: Stefan Santesson [mailto:[e-mail]]
>>>>Sent: Tuesday, March 11, 2003 8:27 AM
>>>>To: [e-mail]
>>>>Subject: QC Declaration
>>>>
>>>>The EU directive introduced a requirement on each CA, issuing QC 
>>>>(Qualified
>>>>Certificates), to clearly indicate in these certificate that they are
>>>>issued as QC.
>>>>ETSI implemented RFC 3039 in relation to the European electronic signature
>>>>directive through their Technical Standard (TS 101862)
>>>>TS 101862 specified 2 alternative ways to declare a certificate as QC.
>>>>1) By inclusion of a QCStatements extension
>>>>2) By including a certificate policy identifying this property
>>>>Even though solution number 1) is far easier to handle by applications,
>>>>since they don't need to recognize specific QC Policies, ETSI didn't make
>>>>solution 1) mandatory or even consider making it critical, due to lack of
>>>>confidence that clients would widely deploy this solution. ETSI needed to
>>>>define a solution that could work even if no one choose to implement the
>>>>new extensions provided by RFC 3039.
>>>>However, It is not feasible to keep clients updated over time with
>>>>different QC policies and even those policies that are regarded
>>>>standardized may be updated with change of OID as a result. It would be
>>>>devastating if we can't update a QCP because that would force an OID 
>>>>update
>>>>and that would render certificates useless because clients learned to
>>>>recognize only the old OID. This would be to build in a new root
>>>>certificate problem into the platforms.
>>>>My observations is that times have changed. I have seen clear indications
>>>>that market players want, and even require for interoperability reasons,
>>>>that use QCStatements solution is made mandatory and maybe even critical
>>>>for QC.
>>>>Since both RFC 3039, and TS 101862 are up for revision, it is time to
>>>>revisit this issue.
>>>>I have some questions and proposals:
>>>>- Is there any experiences of this issue outside of Europe. I.e. are there
>>>>other legal systems that make use of the same declaration logic as the EU
>>>>directive, where the RFC 3039 profile is used fully or partly as a 
>>>>solution
>>>>to this issue?
>>>>- I would suggest that the QCStatement mechanism is ought to be a 
>>>>mandatory
>>>>tool to communicate a Qualified Status. The question is:
>>>>     1) whether this will have enough implementation support to succeed?
>>>>     2) whether is best specified in RFC 3039 or in local profiles 
>>>> (such as
>>>>TS 101862)?
>>>>     3) If there could be a clear context defined where criticality 
>>>> could be
>>>>allowed or even required?
>>>>I would really like feedback from practical experiences from this 
>>>>issue, as
>>>>well as constructive proposals.
>>>>/Stefan
>>>>
>>>>
>>>>/Stefan
>>>>
>>>>_____________________________
>>>>Stefan Santesson,  Retrospekt AB
>>>>http://www.retrospekt.com
>>>>[phone]
>>>_____________________________
>>>Stefan Santesson,  Retrospekt AB
>>>http://www.retrospekt.com
>>>[phone]
>>
>>_____________________________
>>Stefan Santesson,  Retrospekt AB
>>http://www.retrospekt.com
>>[phone]
>
>_____________________________
>Stefan Santesson,  Retrospekt AB
>http://www.retrospekt.com
>[phone]

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone] 
--=====================_26737626==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Thank you Sharon<br><br>
Now I'm clear about what the situation is.<br>
I'll come back with some reasoning about this issue.<br><br>
/Stefan<br><br>
At 15:19 2003-03-12 -0500, Sharon Boeyen wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#0000FF">It
would have been compliant IF the semantics of the extension stated that.
However, the semantics of the extension dictate the opposite where ALL
statements are critical</font><font face="arial">.<br>
</font>
<dl>
<dd><font face="tahoma" size=2>-----Original Message-----<br>

<dd>From:</b> Stefan Santesson
[<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>]<br>

<dd>Sent:</b> Tuesday, March 11, 2003 4:49 PM<br>

<dd>To:</b> Sharon Boeyen; [e-mail]<br>

<dd>Subject:</b> RE: QC Declaration<br><br>
</font>
<dd>Sharon,<br><br>

<dd>The first step for me is to get the mechanics right.<br><br>

<dd>Are you saying that it would have been compliant with X.509 to
declare that a critical QCStatement (disregarding the current declaration
in RFC 3039) is valid if I can process at least one of the present
statements (similar to SubjectAltName).<br><br>

<dd>Not that I claim that it would be a good idea.<br><br>

<dd>/Stefan<br><br>
<br>

<dd>At 16:30 2003-03-11 -0500, Sharon Boeyen wrote:<br>
<blockquote type=cite class=cite cite>
<dd><font face="arial" size=2 color="#0000FF">I don't want to get off on
a non-relevant tangent regarding criticality, but think I do need to
clarify a little bit on the subject Alt Name extension. If you check
8.3.2.3 (509) you'll find that the semantics of that extension are such
that, if set to critical, &quot;at least one of the name forms that is
present shall be recognized and processed ...&quot;. So if, in your
example, the ONLY name present in subjectAltName extension is the unknown
otherName OID, then you are correct and the certificate shall be
considered invalid. If however, that unknown otherName OID was present
AND and rfc822Name was present - the RP might understand the rfc822Name
and check it against the intended recipient of an encrypted email for
example, and under those circumstances the certificate would be valid,
even though the extension was critical and there was another nameform in
there that was not understood.</font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2 color="#0000FF">I suspect that its probably
a bit too soon to profile the kind of contexts I think you're describing
in 3039. I'd prefer to see a bit more practical use of QCs first so that
we have a better handle on what constitutes a &quot;context&quot;. For
example, perhaps one context is with the ETSI qcstatement 1 plus a
specific national qc statement and if both are present in a certificate
that some 'authority' (I don't mean a CA here) deems that when that
combination is present the extension shall be set to critical. I'm not
necessarily opposing the idea, just a little uncomfortable with the
proposed timing without significant real world deployment to guide us
with to the appropriate 'contexts'.</font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2 color="#0000FF">Cheers,</font><br>

<dd><font face="arial" size=2 color="#0000FF">Sharon</font>
<dd><font face="tahoma" size=2>-----Original Message-----
<dd>From: Stefan Santesson
[<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>]
<dd>Sent: Tuesday, March 11, 2003 4:06 PM
<dd>To: Sharon Boeyen; Sharon Boeyen; [e-mail]
<dd>Subject: RE: QC Declaration<br><br>
</font>
<dd>Sharon,
<dd>Thanks for the clarification.<br>

<dd>&quot;Elements of the syntax&quot; really clarifies things.<br>

<dd>So it is OK to accept an certificate with a critical policy extension
containing an policy OID that I don't recognize, because it doesn't
define any further syntax of the extension.
<dd>The same goes with Extended key usage OIDs.<br>

<dd>However. It would not be OK with a critical subjectAltName containing
an unknown other name OID, since this OID would define further syntax.
<dd>By the same reason I would need to understand all present
QCStatements OIDs, because they do the same (define further 
syntax).<br>

<dd>Let me clarify that I never proposed that the QCStatement must be
critical in all certificates.
<dd>I'm just recognizing that it might be a valuable practice within
certain contexts and the fact that some implementers actually ask for
it.
<dd>The question is whether any of those contexts can be identified
within RFC 3039, or if they are better placed in local sub-profiles (Such
as ETSI TS 101862), or if they don't exist in a way that can be
standardized in a meaningful way.<br>
<br>

<dd>/Stefan<br>
<br>

<dd>At 11:37 2003-03-11 -0500, Sharon Boeyen
wrote:<blockquote type=cite class=cite cite>
<dd><font face="arial" size=2 color="#0000FF">Hi Stefan,</font><br>

<dd>&nbsp; 
<dd><font face="arial" size=2 color="#0000FF">Remember first that RFC
3280 is a &quot;profile&quot; of X.509 and it does not replace the
requirements of 509, but rather profiles them to a subset. </font><br>

<dd>&nbsp; 
<dd><font face="arial" size=2 color="#0000FF">X.509 in clause 7 allows
unknown elements in non-critical extensions only to be ignored. However,
that is more with respect to the elements in the syntax </font>
<dd><font face="arial" size=2 color="#0000FF">itself (for example in the
IDP extension no RP is allowed to ignore the &quot;onlySomeReasons&quot;
element if it is present in the extension because the extension </font>
<dd><font face="arial" size=2 color="#0000FF">can only be critical. The
behaviour of RPs will differ however depending on their specific
capability with respect to that element (some will use the CRL for
</font>
<dd><font face="arial" size=2 color="#0000FF">the specified reasons and
others will seek a different CRL that covers all reasons), however, no RP
is permitted to simply ignore the flag. Note also that in that</font>
<dd><font face="arial" size=2 color="#0000FF">same clause, for extensions
that can be marked critical or non-critical, a system that understands
the extension is required to process it regardless of the </font>
<dd><font face="arial" size=2 color="#0000FF">value of the criticality
flag. It is ONLY systems that do not understand an extension that can
ignore it completely if it is marked non-critical. </font><br>

<dd>&nbsp; 
<dd><font face="arial" size=2 color="#0000FF">For the QC Statements
extension, RFC 3039 says &quot;This extension may be critical or
non-critical.&nbsp; If the extension is critical, this means that all
statements </font>
<dd><font face="arial" size=2 color="#0000FF">included in the extension
are regarded as
critical.</font><font face="Times New Roman, Times" size=2 color="#0000FF">
</font><font face="arial" size=2 color="#0000FF">&quot; </font><br>

<dd>&nbsp; 
<dd><font face="arial" size=2 color="#0000FF">Because of the semantics
defined for the extension in RFC 3039, marking it critical would result
in the problems I raised.
</font><font face="Times New Roman, Times" size=2 color="#0000FF"><br><br>
</font>
<dd><font face="tahoma" size=2>-----Original Message----- 
<dd>From: Stefan Santesson
[<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>] 
<dd>Sent: Tuesday, March 11, 2003 11:23 AM 
<dd>To: Sharon Boeyen; [e-mail] 
<dd>Subject: RE: QC Declaration<br><br>
</font>
<dd>Hi Sharon,
<dd>My interpretation of criticality does not really match yours.
<dd>The only guidance on the meaning of criticality in RFC 3280 (section
4.2) that I can find is:<br>
<br>
<br>
<br><br>

<dd><pre>&nbsp; &quot;A certificate using system MUST reject the


<dd>certificate



<dd>if it encounters a critical extension it does not recognize&quot;

</pre><font face="Courier New, Courier"></font>
<dd>My interpretation is that it is OK to accept a certificate if you
recognize the extension as such. You don't need to understand ALL
information that the extension contains.
<dd>It seam vital to agree on this issue before we can make any
conclusion on QCStatament criticality.
<dd>/Stefan<br>

<dd>At 10:56 2003-03-11 -0500, Sharon Boeyen wrote:
<blockquote type=cite class=cite cite>
<dd>Hi Stefan,
<dd>While I believe that in the longer term certificate policies will be
the 
<dd>optimum 
<dd>way to convey the necessary information, I acknowledge that QC
Statements is 
<dd>the 
<dd>more popular scheme at present. Therefore I wouldn't have any problem
should 
<dd>this 
<dd>extension be mandated in RFC 3039. 
<dd>However, forcing its criticality is going too far I believe. There is
an 
<dd>important 
<dd>difference between critical and non-critical extensions that we need
to keep 
<dd>in 
<dd>mind from the relying party's perspective. If there is a non-critical 
<dd>extension that 
<dd>the RP understands, but that extension includes some elements that it
does 
<dd>not, then 
<dd>the RP is free to process the parts it does understand and ignore
others. If 
<dd>an extension 
<dd>is critical however, the RP is required to understand ALL elements
within 
<dd>the extension.
<dd>Where I think this can become a problem is the content of the QC
Statements 
<dd>extension. Note 
<dd>that RFC 3039 and the ETSI profile define DIFFERENT statements for
inclusion 
<dd>in the extension. 
<dd>Also additional profiles may add their own local statements and even 
<dd>narrower statements can 
<dd>get added in specific deployment environments. While the cert issuer
may 
<dd>want to include many 
<dd>of these statements to enable the cert to be used in various
environments, 
<dd>the RP should only 
<dd>be required to understand and process the statements that are
appropriate to 
<dd>its own 
<dd>operating environment as dictated by its local security policy (which
could 
<dd>be different than 
<dd>that under which the CA operated). Therefore I think requiring it to
be 
<dd>critical is risky. 
<dd>Also requiring that it always be critical would have interop/backward 
<dd>compatibility issues.
<dd>Cheers, 
<dd>Sharon<br>
<br>
<br>

<dd>-----Original Message----- 
<dd>From: Stefan Santesson
[<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>] 
<dd>Sent: Tuesday, March 11, 2003 8:27 AM 
<dd>To: [e-mail] 
<dd>Subject: QC Declaration<br>
<br>

<dd>The EU directive introduced a requirement on each CA, issuing QC
(Qualified 
<dd>Certificates), to clearly indicate in these certificate that they are 
<dd>issued as QC.
<dd>ETSI implemented RFC 3039 in relation to the European electronic
signature 
<dd>directive through their Technical Standard (TS 101862)
<dd>TS 101862 specified 2 alternative ways to declare a certificate as
QC.
<dd>1) By inclusion of a QCStatements extension 
<dd>2) By including a certificate policy identifying this property
<dd>Even though solution number 1) is far easier to handle by
applications, 
<dd>since they don't need to recognize specific QC Policies, ETSI didn't
make 
<dd>solution 1) mandatory or even consider making it critical, due to
lack of 
<dd>confidence that clients would widely deploy this solution. ETSI
needed to 
<dd>define a solution that could work even if no one choose to implement
the 
<dd>new extensions provided by RFC 3039.
<dd>However, It is not feasible to keep clients updated over time with 
<dd>different QC policies and even those policies that are regarded 
<dd>standardized may be updated with change of OID as a result. It would
be 
<dd>devastating if we can't update a QCP because that would force an OID
update 
<dd>and that would render certificates useless because clients learned to 
<dd>recognize only the old OID. This would be to build in a new root 
<dd>certificate problem into the platforms.
<dd>My observations is that times have changed. I have seen clear
indications 
<dd>that market players want, and even require for interoperability
reasons, 
<dd>that use QCStatements solution is made mandatory and maybe even
critical 
<dd>for QC.
<dd>Since both RFC 3039, and TS 101862 are up for revision, it is time to 
<dd>revisit this issue.
<dd>I have some questions and proposals:
<dd>- Is there any experiences of this issue outside of Europe. I.e. are
there 
<dd>other legal systems that make use of the same declaration logic as
the EU 
<dd>directive, where the RFC 3039 profile is used fully or partly as a
solution 
<dd>to this issue?
<dd>- I would suggest that the QCStatement mechanism is ought to be a
mandatory 
<dd>tool to communicate a Qualified Status. The question is: 
<dd>&nbsp;&nbsp;&nbsp; 1) whether this will have enough implementation
support to succeed? 
<dd>&nbsp;&nbsp;&nbsp; 2) whether is best specified in RFC 3039 or in
local profiles (such as 
<dd>TS 101862)? 
<dd>&nbsp;&nbsp;&nbsp; 3) If there could be a clear context defined where
criticality could be 
<dd>allowed or even required?
<dd>I would really like feedback from practical experiences from this
issue, as 
<dd>well as constructive proposals.
<dd>/Stefan<br>
<br>
<br>

<dd>/Stefan<br>
<br>

<dd>_____________________________ 
<dd>Stefan Santesson,&nbsp; Retrospekt AB 
<dd><a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a> 
<dd>[phone] </blockquote>
<dd>_____________________________ 
<dd>Stefan Santesson,&nbsp; Retrospekt AB 
<dd><a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a> 
<dd>[phone] </blockquote>
</dl><br>
_____________________________<br>
Stefan Santesson,&nbsp; Retrospekt AB<br>
<a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a><br>
[phone] </blockquote><br>
_____________________________<br>
Stefan Santesson,&nbsp; Retrospekt AB<br>
<a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a><br>
[phone] <br>
</blockquote>
<x-sigsep><p></x-sigsep>
_____________________________<br>
Stefan Santesson,&nbsp; Retrospekt AB<br>
<a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a><br>
[phone]</body>
</html>

--=====================_26737626==.ALT--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CKJZT03353 for ietf-pkix-bks; Wed, 12 Mar 2003 12:19:35 -0800 (PST)
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CKJY303349 for <[e-mail]>; Wed, 12 Mar 2003 12:19:34 -0800 (PST)
Received: from SOTTMXS01.entrust.com (sottmxs01.entrust.com [10.4.61.7]) by sottmxssm.entrust.com (Switch-2.2.5/Switch-2.2.4) with ESMTP id V2CK1GEX01032; Wed, 12 Mar 2003 15:16:50 -0500
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <GXR5N6GG>; Wed, 12 Mar 2003 15:19:28 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, [e-mail]
Subject: RE: QC Declaration
Date: Wed, 12 Mar 2003 15:19:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E8D4.AE2FBC70"
Sender: [e-mail]
Precedence: 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_01C2E8D4.AE2FBC70
Content-Type: text/plain

It would have been compliant IF the semantics of the extension stated that.
However, the semantics of the extension dictate the opposite where ALL
statements are critical.


-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]
Sent: Tuesday, March 11, 2003 4:49 PM
To: Sharon Boeyen; [e-mail]
Subject: RE: QC Declaration


Sharon,

The first step for me is to get the mechanics right.

Are you saying that it would have been compliant with X.509 to declare that
a critical QCStatement (disregarding the current declaration in RFC 3039) is
valid if I can process at least one of the present statements (similar to
SubjectAltName).

Not that I claim that it would be a good idea.

/Stefan


At 16:30 2003-03-11 -0500, Sharon Boeyen wrote:


I don't want to get off on a non-relevant tangent regarding criticality, but
think I do need to clarify a little bit on the subject Alt Name extension.
If you check 8.3.2.3 (509) you'll find that the semantics of that extension
are such that, if set to critical, "at least one of the name forms that is
present shall be recognized and processed ...". So if, in your example, the
ONLY name present in subjectAltName extension is the unknown otherName OID,
then you are correct and the certificate shall be considered invalid. If
however, that unknown otherName OID was present AND and rfc822Name was
present - the RP might understand the rfc822Name and check it against the
intended recipient of an encrypted email for example, and under those
circumstances the certificate would be valid, even though the extension was
critical and there was another nameform in there that was not understood.
 
I suspect that its probably a bit too soon to profile the kind of contexts I
think you're describing in 3039. I'd prefer to see a bit more practical use
of QCs first so that we have a better handle on what constitutes a
"context". For example, perhaps one context is with the ETSI qcstatement 1
plus a specific national qc statement and if both are present in a
certificate that some 'authority' (I don't mean a CA here) deems that when
that combination is present the extension shall be set to critical. I'm not
necessarily opposing the idea, just a little uncomfortable with the proposed
timing without significant real world deployment to guide us with to the
appropriate 'contexts'.
 
Cheers,
Sharon


-----Original Message-----


From: Stefan Santesson [ mailto:[e-mail]
<mailto:[e-mail]> ]


Sent: Tuesday, March 11, 2003 4:06 PM


To: Sharon Boeyen; Sharon Boeyen; [e-mail]


Subject: RE: QC Declaration



Sharon,


Thanks for the clarification.



"Elements of the syntax" really clarifies things.



So it is OK to accept an certificate with a critical policy extension
containing an policy OID that I don't recognize, because it doesn't define
any further syntax of the extension.


The same goes with Extended key usage OIDs.



However. It would not be OK with a critical subjectAltName containing an
unknown other name OID, since this OID would define further syntax.


By the same reason I would need to understand all present QCStatements OIDs,
because they do the same (define further syntax).




Let me clarify that I never proposed that the QCStatement must be critical
in all certificates.


I'm just recognizing that it might be a valuable practice within certain
contexts and the fact that some implementers actually ask for it.


The question is whether any of those contexts can be identified within RFC
3039, or if they are better placed in local sub-profiles (Such as ETSI TS
101862), or if they don't exist in a way that can be standardized in a
meaningful way.




/Stefan




At 11:37 2003-03-11 -0500, Sharon Boeyen wrote:



Hi Stefan,



  

Remember first that RFC 3280 is a "profile" of X.509 and it does not replace
the requirements of 509, but rather profiles them to a subset. 



  

X.509 in clause 7 allows unknown elements in non-critical extensions only to
be ignored. However, that is more with respect to the elements in the syntax



itself (for example in the IDP extension no RP is allowed to ignore the
"onlySomeReasons" element if it is present in the extension because the
extension 


can only be critical. The behaviour of RPs will differ however depending on
their specific capability with respect to that element (some will use the
CRL for 


the specified reasons and others will seek a different CRL that covers all
reasons), however, no RP is permitted to simply ignore the flag. Note also
that in that


same clause, for extensions that can be marked critical or non-critical, a
system that understands the extension is required to process it regardless
of the 


value of the criticality flag. It is ONLY systems that do not understand an
extension that can ignore it completely if it is marked non-critical. 



  

For the QC Statements extension, RFC 3039 says "This extension may be
critical or non-critical.  If the extension is critical, this means that all
statements 


included in the extension are regarded as critical. " 



  

Because of the semantics defined for the extension in RFC 3039, marking it
critical would result in the problems I raised. 



-----Original Message----- 

From: Stefan Santesson [ mailto:[e-mail]
<mailto:[e-mail]> ] 

Sent: Tuesday, March 11, 2003 11:23 AM 

To: Sharon Boeyen; [e-mail] 

Subject: RE: QC Declaration



Hi Sharon,


My interpretation of criticality does not really match yours.


The only guidance on the meaning of criticality in RFC 3280 (section 4.2)
that I can find is:







  "A certificate using system MUST reject the


certificate




if it encounters a critical extension it does not recognize"



My interpretation is that it is OK to accept a certificate if you recognize
the extension as such. You don't need to understand ALL information that the
extension contains.


It seam vital to agree on this issue before we can make any conclusion on
QCStatament criticality.


/Stefan



At 10:56 2003-03-11 -0500, Sharon Boeyen wrote: 


Hi Stefan,


While I believe that in the longer term certificate policies will be the 

optimum 

way to convey the necessary information, I acknowledge that QC Statements is


the 

more popular scheme at present. Therefore I wouldn't have any problem should


this 

extension be mandated in RFC 3039. 


However, forcing its criticality is going too far I believe. There is an 

important 

difference between critical and non-critical extensions that we need to keep


in 

mind from the relying party's perspective. If there is a non-critical 

extension that 

the RP understands, but that extension includes some elements that it does 

not, then 

the RP is free to process the parts it does understand and ignore others. If


an extension 

is critical however, the RP is required to understand ALL elements within 

the extension.


Where I think this can become a problem is the content of the QC Statements 

extension. Note 

that RFC 3039 and the ETSI profile define DIFFERENT statements for inclusion


in the extension. 

Also additional profiles may add their own local statements and even 

narrower statements can 

get added in specific deployment environments. While the cert issuer may 

want to include many 

of these statements to enable the cert to be used in various environments, 

the RP should only 

be required to understand and process the statements that are appropriate to


its own 

operating environment as dictated by its local security policy (which could 

be different than 

that under which the CA operated). Therefore I think requiring it to be 

critical is risky. 

Also requiring that it always be critical would have interop/backward 

compatibility issues.


Cheers, 

Sharon







-----Original Message----- 

From: Stefan Santesson [ mailto:[e-mail]
<mailto:[e-mail]> ] 

Sent: Tuesday, March 11, 2003 8:27 AM 

To: [e-mail] 

Subject: QC Declaration




The EU directive introduced a requirement on each CA, issuing QC (Qualified 

Certificates), to clearly indicate in these certificate that they are 

issued as QC.


ETSI implemented RFC 3039 in relation to the European electronic signature 

directive through their Technical Standard (TS 101862)


TS 101862 specified 2 alternative ways to declare a certificate as QC.


1) By inclusion of a QCStatements extension 

2) By including a certificate policy identifying this property


Even though solution number 1) is far easier to handle by applications, 

since they don't need to recognize specific QC Policies, ETSI didn't make 

solution 1) mandatory or even consider making it critical, due to lack of 

confidence that clients would widely deploy this solution. ETSI needed to 

define a solution that could work even if no one choose to implement the 

new extensions provided by RFC 3039.


However, It is not feasible to keep clients updated over time with 

different QC policies and even those policies that are regarded 

standardized may be updated with change of OID as a result. It would be 

devastating if we can't update a QCP because that would force an OID update 

and that would render certificates useless because clients learned to 

recognize only the old OID. This would be to build in a new root 

certificate problem into the platforms.


My observations is that times have changed. I have seen clear indications 

that market players want, and even require for interoperability reasons, 

that use QCStatements solution is made mandatory and maybe even critical 

for QC.


Since both RFC 3039, and TS 101862 are up for revision, it is time to 

revisit this issue.


I have some questions and proposals:


- Is there any experiences of this issue outside of Europe. I.e. are there 

other legal systems that make use of the same declaration logic as the EU 

directive, where the RFC 3039 profile is used fully or partly as a solution 

to this issue?


- I would suggest that the QCStatement mechanism is ought to be a mandatory 

tool to communicate a Qualified Status. The question is: 

    1) whether this will have enough implementation support to succeed? 

    2) whether is best specified in RFC 3039 or in local profiles (such as 

TS 101862)? 

    3) If there could be a clear context defined where criticality could be 

allowed or even required?


I would really like feedback from practical experiences from this issue, as 

well as constructive proposals.


/Stefan





/Stefan




_____________________________ 

Stefan Santesson,  Retrospekt AB 

http://www.retrospekt.com <http://www.retrospekt.com/>  

[phone] 

_____________________________ 

Stefan Santesson,  Retrospekt AB 

http://www.retrospekt.com <http://www.retrospekt.com/>  

[phone] 


_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com <http://www.retrospekt.com/> 
[phone] 


_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com <http://www.retrospekt.com/> 
[phone] 


------_=_NextPart_001_01C2E8D4.AE2FBC70
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">


<META content="MSHTML 5.50.4922.900" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=828161920-12032003><FONT face=Arial color=#0000ff size=2>It 
would have been compliant IF the semantics of the extension stated that. 
However, the semantics of the extension dictate the opposite where ALL 
statements are critical<FONT color=#000000 
size=3>.<BR></FONT></FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Stefan Santesson 
  [mailto:[e-mail]]<BR><B>Sent:</B> Tuesday, March 11, 2003 4:49 
  PM<BR><B>To:</B> Sharon Boeyen; [e-mail]<BR><B>Subject:</B> RE: QC 
  Declaration<BR><BR></FONT></DIV>Sharon,<BR><BR>The first step for me is to get 
  the mechanics right.<BR><BR>Are you saying that it would have been compliant 
  with X.509 to declare that a critical QCStatement (disregarding the current 
  declaration in RFC 3039) is valid if I can process at least one of the present 
  statements (similar to SubjectAltName).<BR><BR>Not that I claim that it would 
  be a good idea.<BR><BR>/Stefan<BR><BR><BR>At 16:30 2003-03-11 -0500, Sharon 
  Boeyen wrote:<BR>
  <BLOCKQUOTE class=cite cite type="cite"><FONT face=arial color=#0000ff 
    size=2>I don't want to get off on a non-relevant tangent regarding 
    criticality, but think I do need to clarify a little bit on the subject Alt 
    Name extension. If you check 8.3.2.3 (509) you'll find that the semantics of 
    that extension are such that, if set to critical, "at least one of the name 
    forms that is present shall be recognized and processed ...". So if, in your 
    example, the ONLY name present in subjectAltName extension is the unknown 
    otherName OID, then you are correct and the certificate shall be considered 
    invalid. If however, that unknown otherName OID was present AND and 
    rfc822Name was present - the RP might understand the rfc822Name and check it 
    against the intended recipient of an encrypted email for example, and under 
    those circumstances the certificate would be valid, even though the 
    extension was critical and there was another nameform in there that was not 
    understood.</FONT><BR>&nbsp;<BR><FONT face=arial color=#0000ff size=2>I 
    suspect that its probably a bit too soon to profile the kind of contexts I 
    think you're describing in 3039. I'd prefer to see a bit more practical use 
    of QCs first so that we have a better handle on what constitutes a 
    "context". For example, perhaps one context is with the ETSI qcstatement 1 
    plus a specific national qc statement and if both are present in a 
    certificate that some 'authority' (I don't mean a CA here) deems that when 
    that combination is present the extension shall be set to critical. I'm not 
    necessarily opposing the idea, just a little uncomfortable with the proposed 
    timing without significant real world deployment to guide us with to the 
    appropriate 'contexts'.</FONT><BR>&nbsp;<BR><FONT face=arial color=#0000ff 
    size=2>Cheers,</FONT><BR><FONT face=arial color=#0000ff 
    size=2>Sharon</FONT><BR>
    <DL>
      <DD><FONT face=tahoma size=2>-----Original Message-----<BR>
      <DD>From:</B> Stefan Santesson [<A href="mailto:[e-mail]" 
      eudora="autourl">mailto:[e-mail]</A>]<BR>
      <DD>Sent:</B> Tuesday, March 11, 2003 4:06 PM<BR>
      <DD>To:</B> Sharon Boeyen; Sharon Boeyen; [e-mail]<BR>
      <DD>Subject:</B> RE: QC Declaration<BR><BR></FONT>
      <DD>Sharon,<BR>
      <DD>Thanks for the clarification.<BR><BR>
      <DD>"Elements of the syntax" really clarifies things.<BR><BR>
      <DD>So it is OK to accept an certificate with a critical policy extension 
      containing an policy OID that I don't recognize, because it doesn't define 
      any further syntax of the extension.<BR>
      <DD>The same goes with Extended key usage OIDs.<BR><BR>
      <DD>However. It would not be OK with a critical subjectAltName containing 
      an unknown other name OID, since this OID would define further syntax.<BR>
      <DD>By the same reason I would need to understand all present QCStatements 
      OIDs, because they do the same (define further syntax).<BR><BR><BR>
      <DD>Let me clarify that I never proposed that the QCStatement must be 
      critical in all certificates.<BR>
      <DD>I'm just recognizing that it might be a valuable practice within 
      certain contexts and the fact that some implementers actually ask for 
      it.<BR>
      <DD>The question is whether any of those contexts can be identified within 
      RFC 3039, or if they are better placed in local sub-profiles (Such as ETSI 
      TS 101862), or if they don't exist in a way that can be standardized in a 
      meaningful way.<BR><BR><BR>
      <DD>/Stefan<BR><BR><BR>
      <DD>At 11:37 2003-03-11 -0500, Sharon Boeyen wrote:<BR>
      <BLOCKQUOTE class=cite cite type="cite">
        <DD><FONT face=arial color=#0000ff size=2>Hi Stefan,</FONT><BR>
        <DD><BR>&nbsp;
        <DD><FONT face=arial color=#0000ff size=2>Remember first that RFC 3280 
        is a "profile" of X.509 and it does not replace the requirements of 509, 
        but rather profiles them to a subset. </FONT><BR>
        <DD><BR>&nbsp;
        <DD><FONT face=arial color=#0000ff size=2>X.509 in clause 7 allows 
        unknown elements in non-critical extensions only to be ignored. However, 
        that is more with respect to the elements in the syntax </FONT><BR>
        <DD><FONT face=arial color=#0000ff size=2>itself (for example in the IDP 
        extension no RP is allowed to ignore the "onlySomeReasons" element if it 
        is present in the extension because the extension </FONT><BR>
        <DD><FONT face=arial color=#0000ff size=2>can only be critical. The 
        behaviour of RPs will differ however depending on their specific 
        capability with respect to that element (some will use the CRL for 
        </FONT><BR>
        <DD><FONT face=arial color=#0000ff size=2>the specified reasons and 
        others will seek a different CRL that covers all reasons), however, no 
        RP is permitted to simply ignore the flag. Note also that in 
        that</FONT><BR>
        <DD><FONT face=arial color=#0000ff size=2>same clause, for extensions 
        that can be marked critical or non-critical, a system that understands 
        the extension is required to process it regardless of the </FONT><BR>
        <DD><FONT face=arial color=#0000ff size=2>value of the criticality flag. 
        It is ONLY systems that do not understand an extension that can ignore 
        it completely if it is marked non-critical. </FONT><BR>
        <DD><BR>&nbsp;
        <DD><FONT face=arial color=#0000ff size=2>For the QC Statements 
        extension, RFC 3039 says "This extension may be critical or 
        non-critical.&nbsp; If the extension is critical, this means that all 
        statements </FONT><BR>
        <DD><FONT face=arial color=#0000ff size=2>included in the extension are 
        regarded as critical.</FONT><FONT face="Times New Roman, Times" 
        color=#0000ff size=2> </FONT><FONT face=arial color=#0000ff size=2>" 
        </FONT><BR>
        <DD><BR>&nbsp;
        <DD><FONT face=arial color=#0000ff size=2>Because of the semantics 
        defined for the extension in RFC 3039, marking it critical would result 
        in the problems I raised. </FONT><FONT face="Times New Roman, Times" 
        color=#0000ff size=2><BR><BR></FONT>
        <DD><FONT face=tahoma size=2>-----Original Message----- 
        <DD>From: Stefan Santesson [<A href="mailto:[e-mail]" 
        eudora="autourl">mailto:[e-mail]</A>] 
        <DD>Sent: Tuesday, March 11, 2003 11:23 AM 
        <DD>To: Sharon Boeyen; [e-mail] 
        <DD>Subject: RE: QC Declaration<BR><BR></FONT>
        <DD>Hi Sharon,<BR>
        <DD>My interpretation of criticality does not really match yours.<BR>
        <DD>The only guidance on the meaning of criticality in RFC 3280 (section 
        4.2) that I can find is:<BR><BR><BR><BR>
        <DD><PRE>&nbsp; "A certificate using system MUST reject the

<DD>certificate


<DD>if it encounters a critical extension it does not recognize"

</DD></PRE><FONT face="Courier New, Courier"></FONT>
        <DD>My interpretation is that it is OK to accept a certificate if you 
        recognize the extension as such. You don't need to understand ALL 
        information that the extension contains.<BR>
        <DD>It seam vital to agree on this issue before we can make any 
        conclusion on QCStatament criticality.<BR>
        <DD>/Stefan<BR><BR>
        <DD>At 10:56 2003-03-11 -0500, Sharon Boeyen wrote:
        <BLOCKQUOTE class=cite cite type="cite">
          <DD>Hi Stefan,<BR>
          <DD>While I believe that in the longer term certificate policies will 
          be the 
          <DD>optimum 
          <DD>way to convey the necessary information, I acknowledge that QC 
          Statements is 
          <DD>the 
          <DD>more popular scheme at present. Therefore I wouldn't have any 
          problem should 
          <DD>this 
          <DD>extension be mandated in RFC 3039. <BR>
          <DD>However, forcing its criticality is going too far I believe. There 
          is an 
          <DD>important 
          <DD>difference between critical and non-critical extensions that we 
          need to keep 
          <DD>in 
          <DD>mind from the relying party's perspective. If there is a 
          non-critical 
          <DD>extension that 
          <DD>the RP understands, but that extension includes some elements that 
          it does 
          <DD>not, then 
          <DD>the RP is free to process the parts it does understand and ignore 
          others. If 
          <DD>an extension 
          <DD>is critical however, the RP is required to understand ALL elements 
          within 
          <DD>the extension.<BR>
          <DD>Where I think this can become a problem is the content of the QC 
          Statements 
          <DD>extension. Note 
          <DD>that RFC 3039 and the ETSI profile define DIFFERENT statements for 
          inclusion 
          <DD>in the extension. 
          <DD>Also additional profiles may add their own local statements and 
          even 
          <DD>narrower statements can 
          <DD>get added in specific deployment environments. While the cert 
          issuer may 
          <DD>want to include many 
          <DD>of these statements to enable the cert to be used in various 
          environments, 
          <DD>the RP should only 
          <DD>be required to understand and process the statements that are 
          appropriate to 
          <DD>its own 
          <DD>operating environment as dictated by its local security policy 
          (which could 
          <DD>be different than 
          <DD>that under which the CA operated). Therefore I think requiring it 
          to be 
          <DD>critical is risky. 
          <DD>Also requiring that it always be critical would have 
          interop/backward 
          <DD>compatibility issues.<BR>
          <DD>Cheers, 
          <DD>Sharon<BR><BR><BR><BR>
          <DD> 
          <DD>-----Original Message----- 
          <DD>From: Stefan Santesson [<A href="mailto:[e-mail]" 
          eudora="autourl">mailto:[e-mail]</A>] 
          <DD>Sent: Tuesday, March 11, 2003 8:27 AM 
          <DD>To: [e-mail] 
          <DD>Subject: QC Declaration<BR><BR><BR>
          <DD>The EU directive introduced a requirement on each CA, issuing QC 
          (Qualified 
          <DD>Certificates), to clearly indicate in these certificate that they 
          are 
          <DD>issued as QC.<BR>
          <DD>ETSI implemented RFC 3039 in relation to the European electronic 
          signature 
          <DD>directive through their Technical Standard (TS 101862)<BR>
          <DD>TS 101862 specified 2 alternative ways to declare a certificate as 
          QC.<BR>
          <DD>1) By inclusion of a QCStatements extension 
          <DD>2) By including a certificate policy identifying this property<BR>
          <DD>Even though solution number 1) is far easier to handle by 
          applications, 
          <DD>since they don't need to recognize specific QC Policies, ETSI 
          didn't make 
          <DD>solution 1) mandatory or even consider making it critical, due to 
          lack of 
          <DD>confidence that clients would widely deploy this solution. ETSI 
          needed to 
          <DD>define a solution that could work even if no one choose to 
          implement the 
          <DD>new extensions provided by RFC 3039.<BR>
          <DD>However, It is not feasible to keep clients updated over time with 

          <DD>different QC policies and even those policies that are regarded 
          <DD>standardized may be updated with change of OID as a result. It 
          would be 
          <DD>devastating if we can't update a QCP because that would force an 
          OID update 
          <DD>and that would render certificates useless because clients learned 
          to 
          <DD>recognize only the old OID. This would be to build in a new root 
          <DD>certificate problem into the platforms.<BR>
          <DD>My observations is that times have changed. I have seen clear 
          indications 
          <DD>that market players want, and even require for interoperability 
          reasons, 
          <DD>that use QCStatements solution is made mandatory and maybe even 
          critical 
          <DD>for QC.<BR>
          <DD>Since both RFC 3039, and TS 101862 are up for revision, it is time 
          to 
          <DD>revisit this issue.<BR>
          <DD>I have some questions and proposals:<BR>
          <DD>- Is there any experiences of this issue outside of Europe. I.e. 
          are there 
          <DD>other legal systems that make use of the same declaration logic as 
          the EU 
          <DD>directive, where the RFC 3039 profile is used fully or partly as a 
          solution 
          <DD>to this issue?<BR>
          <DD>- I would suggest that the QCStatement mechanism is ought to be a 
          mandatory 
          <DD>tool to communicate a Qualified Status. The question is: 
          <DD>&nbsp;&nbsp;&nbsp; 1) whether this will have enough implementation 
          support to succeed? 
          <DD>&nbsp;&nbsp;&nbsp; 2) whether is best specified in RFC 3039 or in 
          local profiles (such as 
          <DD>TS 101862)? 
          <DD>&nbsp;&nbsp;&nbsp; 3) If there could be a clear context defined 
          where criticality could be 
          <DD>allowed or even required?<BR>
          <DD>I would really like feedback from practical experiences from this 
          issue, as 
          <DD>well as constructive proposals.<BR>
          <DD>/Stefan<BR><BR><BR><BR>
          <DD>/Stefan<BR><BR><BR>
          <DD>_____________________________ 
          <DD>Stefan Santesson,&nbsp; Retrospekt AB 
          <DD><A href="http://www.retrospekt.com/" 
          eudora="autourl">http://www.retrospekt.com</A> 
          <DD>[phone] </DD></BLOCKQUOTE>
        <DD>_____________________________ 
        <DD>Stefan Santesson,&nbsp; Retrospekt AB 
        <DD><A href="http://www.retrospekt.com/" 
        eudora="autourl">http://www.retrospekt.com</A> 
        <DD>[phone] 
    </DD></BLOCKQUOTE></DD></DL><BR>_____________________________<BR>Stefan 
    Santesson,&nbsp; Retrospekt AB<BR><A href="http://www.retrospekt.com/" 
    eudora="autourl">http://www.retrospekt.com</A><BR>[phone] 
  <BR></BLOCKQUOTE><X-SIGSEP>
  <P></X-SIGSEP>_____________________________<BR>Stefan Santesson,&nbsp; 
  Retrospekt AB<BR><A href="http://www.retrospekt.com/" 
  eudora="autourl">http://www.retrospekt.com</A><BR>[phone] 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C2E8D4.AE2FBC70--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CIpRv00782 for ietf-pkix-bks; Wed, 12 Mar 2003 10:51:27 -0800 (PST)
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CIpP300777 for <[e-mail]>; Wed, 12 Mar 2003 10:51:25 -0800 (PST)
Received: from SOTTMXS01.entrust.com (sottmxs01.entrust.com [10.4.61.7]) by sottmxssm.entrust.com (Switch-2.2.5/Switch-2.2.4) with ESMTP id V2CI2CTX24786; Wed, 12 Mar 2003 13:48:29 -0500
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <GXR5NZGF>; Wed, 12 Mar 2003 13:51:07 -0500
Message-ID: <[e-mail]>
From: Tim Moses <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>, Anders Rundgren <[e-mail]>
Cc: Santosh Chokhani <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Certificate Policies (was Re: Trivial PKI Question)
Date: Wed, 12 Mar 2003 13:51:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
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>

Colleagues - Another unfortunate side-effect of implementing a distinct
hierarchy for each policy is that, in order to sign a transaction, the
signer has to choose the key/certificate/hierarchy/policy that will be
accepted by the relying party for the particular transaction.  If he/she
chooses wrongly, then the transaction will be rejected.

On the other hand, if the signer only has one key/certificate, then the
signer has no choice to make.  He/she signs the transaction with his/her
only key and (if a suitable certification path exists) the relying party
discovers and validates it in accordance with its policy requirements.

Of course, solutions could be developed to solve this problem for the case
of distinct hierarchies, but the solution already exists and is thoroughly
tested for the "multiple-policies per certificate" case.

All the best.  Tim.

-----Original Message-----
From: Steve Hanna [mailto:[e-mail]]
Sent: Wednesday, March 12, 2003 10:39 AM
To: Anders Rundgren
Cc: Santosh Chokhani; [e-mail]; [e-mail]
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)



Anders Rundgren wrote:
> there is no reason to get excited :-)

I'm not excited, just trying to redirect the conversation
away from unsubstantiated attacks and toward solid technical
analysis.

> >The method you described (having a separate CA network
> >for each policy) is cumbersome. So, yes, I do think we
> >should work on getting support for certificate policies
> >into relying party software.
> 
> I know little about the systems that you indirectly refer to, but
> may I put some questions here?

Yes, this is good. We're having a real dialog, exchanging
information! As I said before, I'm not an expert on
certificate policies. However, I'll try to answer your
questions. Anyone who knows more about certificate policies
should feel free to jump in at any time. I also suggest
that you (Anders) might want to read RFC 2527 or the
Internet Draft that is being prepared to succeed it:
draft-ietf-pkix-ipki-new-rfc2527-01.txt. This describes
certificate policies in some detail.

> - What does separate CA networks mean more than multiple keys
>   (which should be piece of cake if you have proper CA SW)?

This is the system currently used by most commercial CAs.
They typically have a separate root CA for each class of
certificates (certificate policy). This root CA may certify
subordinate CAs, which are also typically separated by class
of certificate. Not only do you need a separate key pair
for each class of certificate, you typically use a different
CA name and have a separate set of CRLs. And, of course, the
number of trust anchors in relying party software increases
by a factor equal to the number of policies.

> - What do these policies imply (function: web-server/e-mail or
>   legal: hi-value/lo-value)? This is IMO a pretty broken part
>   of  policy extensions.  And very hard to "repair" as well

As RFC 2527 and X.509 say, a certificate policy typically
"indicates the applicability of a certificate to a particular
community and/or class of application with common security
requirements." Among other things, it might say what applications
the certificate can be used for or what warranties are provided.
So both "function" and "legal", in your terms.

Could you elaborate on why you think this is broken?

Personally, I'm concerned that the expense and inconvenience
of defining certificate policies and agreeing on them between
all the parties in a PKI is slowing down PKI deployment. I'm
interested in working on possible solutions to that problem:
standard CPs, minimal CPs, and other ideas. But this problem
arises regardless of whether you use the certificate policies
extension or establish a separate CA network for each policy.

Maybe your objection is to certificate policies in
general and not to the certificate policies extension
in particular. If so, how do you propose that CAs and
relying parties would agree on what the certificates
mean? And why should you object if some people want
to identify certificate policies in the certificate?
Nobody will force you to do so and it addresses their
requirements.

> - How does these guys plan to communicate outside of their
>   tightly matched (unique) system?

An application that requires one particular certificate
policy generally won't accept another policy unless policy
mapping has established that the other is acceptable.
For these applications, maintaining security is apparently
more important than being able to accept any certificate.
Other applications might not have such a requirement.

As for the merits of attribute certificates, directories,
the U.S. Government, etc., let's set that discussion aside
for now and focus on certificate policies. We can work on
those topics some other time.

Thanks,

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CFfEa18908 for ietf-pkix-bks; Wed, 12 Mar 2003 07:41:14 -0800 (PST)
Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CFf8318898 for <[e-mail]>; Wed, 12 Mar 2003 07:41:08 -0800 (PST)
Received: from sydney.East.Sun.COM ([129.148.9.16]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13676; Wed, 12 Mar 2003 08:41:09 -0700 (MST)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h2CFf8028195; Wed, 12 Mar 2003 10:41:08 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 12 Mar 2003 10:38:46 -0500
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: Santosh Chokhani <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)
References: <007f01c2e75f$4b93ec10$2d00a8c0@Chokhani> <[e-mail]> <00b401c2e7ff$183fb420$0500a8c0@arport> <[e-mail]> <006601c2e85f$69053000$0500a8c0@arport>
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 Rundgren wrote:
> there is no reason to get excited :-)

I'm not excited, just trying to redirect the conversation
away from unsubstantiated attacks and toward solid technical
analysis.

> >The method you described (having a separate CA network
> >for each policy) is cumbersome. So, yes, I do think we
> >should work on getting support for certificate policies
> >into relying party software.
> 
> I know little about the systems that you indirectly refer to, but
> may I put some questions here?

Yes, this is good. We're having a real dialog, exchanging
information! As I said before, I'm not an expert on
certificate policies. However, I'll try to answer your
questions. Anyone who knows more about certificate policies
should feel free to jump in at any time. I also suggest
that you (Anders) might want to read RFC 2527 or the
Internet Draft that is being prepared to succeed it:
draft-ietf-pkix-ipki-new-rfc2527-01.txt. This describes
certificate policies in some detail.

> - What does separate CA networks mean more than multiple keys
>   (which should be piece of cake if you have proper CA SW)?

This is the system currently used by most commercial CAs.
They typically have a separate root CA for each class of
certificates (certificate policy). This root CA may certify
subordinate CAs, which are also typically separated by class
of certificate. Not only do you need a separate key pair
for each class of certificate, you typically use a different
CA name and have a separate set of CRLs. And, of course, the
number of trust anchors in relying party software increases
by a factor equal to the number of policies.

> - What do these policies imply (function: web-server/e-mail or
>   legal: hi-value/lo-value)? This is IMO a pretty broken part
>   of  policy extensions.  And very hard to "repair" as well

As RFC 2527 and X.509 say, a certificate policy typically
"indicates the applicability of a certificate to a particular
community and/or class of application with common security
requirements." Among other things, it might say what applications
the certificate can be used for or what warranties are provided.
So both "function" and "legal", in your terms.

Could you elaborate on why you think this is broken?

Personally, I'm concerned that the expense and inconvenience
of defining certificate policies and agreeing on them between
all the parties in a PKI is slowing down PKI deployment. I'm
interested in working on possible solutions to that problem:
standard CPs, minimal CPs, and other ideas. But this problem
arises regardless of whether you use the certificate policies
extension or establish a separate CA network for each policy.

Maybe your objection is to certificate policies in
general and not to the certificate policies extension
in particular. If so, how do you propose that CAs and
relying parties would agree on what the certificates
mean? And why should you object if some people want
to identify certificate policies in the certificate?
Nobody will force you to do so and it addresses their
requirements.

> - How does these guys plan to communicate outside of their
>   tightly matched (unique) system?

An application that requires one particular certificate
policy generally won't accept another policy unless policy
mapping has established that the other is acceptable.
For these applications, maintaining security is apparently
more important than being able to accept any certificate.
Other applications might not have such a requirement.

As for the merits of attribute certificates, directories,
the U.S. Government, etc., let's set that discussion aside
for now and focus on certificate policies. We can work on
those topics some other time.

Thanks,

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CEUvw16744 for ietf-pkix-bks; Wed, 12 Mar 2003 06:30:57 -0800 (PST)
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CEUp316734 for <[e-mail]>; Wed, 12 Mar 2003 06:30:51 -0800 (PST)
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09998 for <[e-mail]>; Wed, 12 Mar 2003 06:30:47 -0800 (PST)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h2CEUk019381 for <[e-mail]>; Wed, 12 Mar 2003 09:30:46 -0500 (EST)
Message-ID: <[e-mail]>
Date: Wed, 12 Mar 2003 09:28:24 -0500
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)
References: <007f01c2e75f$4b93ec10$2d00a8c0@Chokhani> <[e-mail]> <00b401c2e7ff$183fb420$0500a8c0@arport>
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>

Apparently, this email (which I sent yesterday) was not
posted to the PKIX list. I am resending it now. Apologies
for any duplicates.

-Steve

-------- Original Message --------
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)
Date: Tue, 11 Mar 2003 17:18:40 -0500
From: Steve Hanna <[e-mail]>
To: Anders Rundgren <[e-mail]>
CC: Santosh Chokhani
<[e-mail]>,[e-mail], [e-mail]
References: <007f01c2e75f$4b93ec10$2d00a8c0@Chokhani>
<[e-mail]> <00b401c2e7ff$183fb420$0500a8c0@arport>

Anders Rundgren wrote:
> We apparently do not agree on the value of policy extensions
> in certificates.

Yes, so it seems.

> >If we refuse to work on anything that's not already
> >widely deployed, we'll have to stop all innovation.
> 
> Even if the method described in my previous message already is
> deployed, pretty universal, and works with all existing software?

The method you described (having a separate CA network
for each policy) is cumbersome. So, yes, I do think we
should work on getting support for certificate policies
into relying party software.

> X.509 Attribute certificates have also been touted as an
> important addition to PKI technology.  I don't think even the
> authors believe that anymore.  At least not in private.

Stop taking unsupported potshots at other technology.
It doesn't help your case.

> >Instead, we must continue to address real problems with
> >real solutions. If customers see value in these solutions,
> >they will be implemented by vendors.
> 
> But how are they going to rollout this particular stuff?
> StarOffice will add such settings?  It seems to me to be
> yet an additional way to fail with PKI.

I think you're asking how end users will configure which
certificate policies they want to require. I suspect that
there will be some button labelled "Advanced" or some
configuration file where they will specify this. But most
users won't use this feature, just as they don't use any
of the security-related user interface. They'll just use
whatever their system administrator has configured. Which
should be fine. Some programs (like email applications)
may have an option to display the certificate policy
associated with the sender (mapping it to a string like
"High Security" via a configuration file).

Another important way that these policies might be used
is that server software might require a "High Security"
certificate policy for clients or peer servers.

And, of course, you managed to slip in another negative
comment about PKI. Again, this does not advance your argument.

> >Certificate policies have definite utility. Several communities
> >are piloting their use, such as the U.S. Government.
> 
> Although government PKIs like to position themselves as being
> in the forefront technically, I believe they are only in the
> forefront in terms of complexity and costs.  If they had
> considered using high-level PKI models, they would never have
> had to use bridge CAs either.

An ad hominem attack.

I suggest you focus your attention on making a convincing
technical argument. So far, the only argument I have heard
from you is that certificate policies are complicated and
not supported by most current software. Therefore, people
should set up a separate CA network (or hierarchy) for
each policy. That's not very convincing.

-Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CA3Yt25460 for ietf-pkix-bks; Wed, 12 Mar 2003 02:03:34 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CA3X325450 for <[e-mail]>; Wed, 12 Mar 2003 02:03:33 -0800 (PST)
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA43840; Wed, 12 Mar 2003 11:06:08 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA03332; Wed, 12 Mar 2003 09:59:46 +0100
Message-ID: <[e-mail]>
Date: Wed, 12 Mar 2003 11:03:31 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: [e-mail]
Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]> <[e-mail]> <[e-mail]> <004401c2e72f$b4c03610$0500a8c0@arport> <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

> At 17:57 2003-03-11 +0100, Denis Pinkas wrote:
>  >I do kown that in fact 676767666767 would allow to uniquely identify 
> the individual, but this is not the semantics of that attribute.

> Denis,

> Where is the semantics broken?

The semantics (extracted from RF 3039) is:

    The serialNumber attribute type SHALL, when present, be used to
    differentiate between names where the subject field would otherwise
    be identical.  This attribute has no defined semantics beyond
    ensuring uniqueness of subject names.  It MAY contain a number or
    code assigned by the CA or an identifier assigned by a government or
    civil authority.  It is the CA's responsibility to ensure that the
    serialNumber is sufficient to resolve any subject name collisions.

It is not broken.

> Who says that a serial number need to start with 1 and be sequential 
> with increment = 1

Nobody.

Denis


> You have only to look at most software products, TV sets or similar to 
> see another truth.
> 676767666767 is a perfectly fine serial number to me.
> 
> /Stefan
> 
> 
> 
> 
> _____________________________
> Stefan Santesson,  Retrospekt AB
> http://www.retrospekt.com
> [phone]
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2CA1G025022 for ietf-pkix-bks; Wed, 12 Mar 2003 02:01:16 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2CA1E325014 for <[e-mail]>; Wed, 12 Mar 2003 02:01:15 -0800 (PST)
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA37668; Wed, 12 Mar 2003 11:03:44 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA03314; Wed, 12 Mar 2003 09:57:21 +0100
Message-ID: <[e-mail]>
Date: Wed, 12 Mar 2003 11:01:05 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail], Stefan Santesson <[e-mail]>
Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]> <[e-mail]> <[e-mail]> <004401c2e72f$b4c03610$0500a8c0@arport> <[e-mail]> <00cc01c2e805$f15400d0$0500a8c0@arport>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

> Denis,

> A crux with your suggestion is that it is correct but "looks" strange
> and leads to confusion.   To use a nonsense disambiguer like "3"
> ("why do you call me John Doe the 3:rd?") when there already is a 
> known and meaningful "676767666767" leads to the effective
> duplication of this information in most real PI-cases.

Extract from RFC 3039:

    The serialNumber attribute type SHALL, when present, be used to
    differentiate between names where the subject field would otherwise
    be identical.  This attribute has no defined semantics beyond
    ensuring uniqueness of subject names.  It MAY contain a number or
    code assigned by the CA or an identifier assigned by a government or
    civil authority.  It is the CA's responsibility to ensure that the
    serialNumber is sufficient to resolve any subject name collisions.

"3" or "676767666767" are both valid values, but have no defined semantics 
beyond ensuring uniqueness of subject names. The SN attribute cannot be used 
in isolation to make an access control decision, since, from this 
definition, it is perfectly allowed for a CA to issue certificates for 
different entities that include the same SN value.

I believe that your question has been answered.

Denis


> This means that CAs have little motives for ever dropping their
> RFC3039-variant of "PI".  And new CAs will likely also follow
> RFC3039 due to the same issue.
> 
> Since most of these permanent-identifier-using CAs only support
> a single name-space (given the non-utility of policy-extensions in
> real-world software), the motives for adding the other part of
> the PI-information also becomes limited.  Particularly as RPs
> are equally singular in most cases.
> 
> And how are RPs supposed to know when they can drop support
> for the RFC3039 way of doing things?
> 
> That's why I rather early, suggested that we together, should bring
> out another scheme, where high-level PKI objects as constituted by
> CA/EE, would be made conformant to the schemes used in most other
> parts of the IT-industry, i.e. self-describing to some extent.  
> 
> Such a scheme would be a true companion to RFC3039 instead of a
> "competitor" regarding "where to stuff identify information".
> 
> ====================================================
>     If the Internet had reached the same technical maturity level as PKI
>     as represented by RFC3280, we would still not have had DNS,
>     but rather be fully occupied tweaking "hosts" files.
> ====================================================
> 
> 
>>Using such a large number is allowed but not strictly needed, since if there 
>>are four people with the attributes DN: CN=John Doe, C=SE then using serial 
>>numbers from 1 to 4 would be sufficient. I do kown that in fact 676767666767 
>>would allow to uniquely identify the individual, but this is not the 
>>semantics of that attribute.
> 
> 
> This is though specified as an option in RFC3039 (although the text is
> not that well written). 
> 
> Anders
> 
> ----- Original Message ----- 
> From: "Denis Pinkas" <[e-mail]>
> To: "Anders Rundgren" <[e-mail]>
> Cc: <[e-mail]>; "Stefan Santesson" <[e-mail]>
> Sent: Tuesday, March 11, 2003 17:57
> Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
> 
> 
> Anders,
> 
> Since you asked, here is a short TECHNICAL reply.
> 
> 
>>Stefan,
>>
>>
>>>The conclusion is that in your opinion there is no problem with
>>>RFC 3039 with regard to this.
>>
>>>Personally I have had a hard time see the problem with this.
>>>This was sorted out many years ago and X.520 as even updated to
>>>clarify that it was appropriate to accommodate this use, i.e. assigning
>>>identifiers to humans. (X.520: "The Serial Number attribute
>>>type specifies an identifier, the serial number of an object. ")
>>
>>I know this but based on private mails the PI advocates still
>>think this a bad use of serialNumber.   As you probably don't care
>>about PI you have nothing to worry about.
>>
>>In case you DO care about PI, please show me how YOU would
>>apply PI to the following RFC3039 compliant "Swedish" certificate:
>>
>>DN: CN=John Doe, serialNumber=676767666767, C=SE
> 
> 
> serialNumber=676767666767 is used to make the difference between two 
> entities that otherwise would have the same name, i.e. DN: CN=John Doe, C=SE.
> 
> Using such a large number is allowed but not strictly needed, since if there 
> are four people with the attributes DN: CN=John Doe, C=SE then using serial 
> numbers from 1 to 4 would be sufficient. I do kown that in fact 676767666767 
> would allow to uniquely identify the individual, but this is not the 
> semantics of that attribute.
> 
> However placing 676767666767 is the PI (with a Assigner Authority like 
> "Swedish XXX" defined using an OID) does allow to uniquely identify the 
> individual, irrespective of its DN.
> 
> So there is no contradiction.
> 
> Denis
> 
> 
> 
> 
> 
> 
> 
> 
>>Anders
>>
>>
> 
> 
> 
> 
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2C6Uia28232 for ietf-pkix-bks; Tue, 11 Mar 2003 22:30:44 -0800 (PST)
Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2C6Ug328228 for <[e-mail]>; Tue, 11 Mar 2003 22:30:42 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailb.telia.com (8.12.8/8.12.8) with SMTP id h2C6UhnD018696; Wed, 12 Mar 2003 07:30:43 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <006601c2e85f$69053000$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Steve Hanna" <[e-mail]>
Cc: "Santosh Chokhani" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <007f01c2e75f$4b93ec10$2d00a8c0@Chokhani> <[e-mail]> <00b401c2e7ff$183fb420$0500a8c0@arport> <[e-mail]>
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)
Date: Wed, 12 Mar 2003 07:19:59 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: 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 Steve,
there is no reason to get excited :-)

>The method you described (having a separate CA network
>for each policy) is cumbersome. So, yes, I do think we
>should work on getting support for certificate policies
>into relying party software.

I know little about the systems that you indirectly refer to, but
may I put some questions here?

- What does separate CA networks mean more than multiple keys
  (which should be piece of cake if you have proper CA SW)?

- What do these policies imply (function: web-server/e-mail or
  legal: hi-value/lo-value)? This is IMO a pretty broken part
  of  policy extensions.  And very hard to "repair" as well

- How does these guys plan to communicate outside of their
  tightly matched (unique) system?

>> X.509 Attribute certificates have also been touted as an
>> important addition to PKI technology.  I don't think even the
>> authors believe that anymore.  At least not in private.

>Stop taking unsupported potshots at other technology.

You want more proofs?  Ok, here is some (see attribute cert):
   http://www.imc.org/ietf-pkix/mail-archive/msg05855.html
An AC author's disillusioned view: 
  http://www.imc.org/ietf-pkix/mail-archive/msg05195.html

Regarding the "ad hominem attack" on the US GOV PKI programs:
In case you are interested in how you can reduce the need for
building systems constituting of:
- Tightly matched private (or community-based) X.500 directories
- Bridge CAs
- Policy extensions as a part of client software

The following are the cornerstones of such an alternative system.
- Communicate only through nodes using "authority stamp signatures".
  Eliminates person-to-person PKI on the client level completely
- Use SAML for intranet access.  Directories only support tree-
  shaped "boring" information, the intranet supports anything

If you look in "server-PKI" in the aforementioned rationale
there is an almost unbearable amount of additional information
on this topic :-)

To get rid of directories, I believe is a major issue for
successful PKI adaption.  Phill H-B, P Gutman agrees to that as
well.  As the directory is the center of most (not the Swedish
one actually) public sector PKI programs, I think we have a
"little" problem in the making here.

Regards
Anders





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2C3EiO23139 for ietf-pkix-bks; Tue, 11 Mar 2003 19:14:44 -0800 (PST)
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2C3Eg323135 for <[e-mail]>; Tue, 11 Mar 2003 19:14:42 -0800 (PST)
Received: from tsg1 (unknown[12.81.120.63]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003031203143911200mfb1pe>; Wed, 12 Mar 2003 03:14:40 +0000
Message-ID: <001e01c2e845$607ac040$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]> <[e-mail]> <[e-mail]> <004401c2e72f$b4c03610$0500a8c0@arport> <[e-mail]> <[e-mail]>
Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
Date: Tue, 11 Mar 2003 19:13:30 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message -----
From: "Stefan Santesson" <[e-mail]>
To: "todd glassey" <[e-mail]>; "Denis Pinkas"
<[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, March 11, 2003 3:27 PM
Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda


>
> Todd,
>
> Is there anything in this statment that reveals any problem with the way
> RFC 3039 defines use of the SN attribute?

No of course not - I wasnt responding to whether there were multiple and
ambiguous uses of the serialNumber attribute in 3039. I was responding to
why one likely should start with one or some known state and increment
upwards monotonically as part of the SN process.

>
> /Stefan
>
> At 14:53 2003-03-11 -0800, todd glassey wrote:
> >Stefan - the key issue is that SN's are only comparable to SN's issued by
> >the same instance or ones that are correlated between instances. The SN
> >itself is a component of the Policy Control process and so it is only
> >relevant to like instances, which is why timestamps are so important -
since
> >they in many senses represent portable SN's - or ones that are easily
> >compared between machines.
> >
> >Todd
> >
> >----- Original Message -----
> >From: "Stefan Santesson" <[e-mail]>
> >To: "Denis Pinkas" <[e-mail]>
> >Cc: <[e-mail]>
> >Sent: Tuesday, March 11, 2003 12:37 PM
> >Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
> >
> >
> > >
> > > At 17:57 2003-03-11 +0100, Denis Pinkas wrote:
> > >  >I do kown that in fact 676767666767 would allow to uniquely identify
the
> > > individual, but this is not the semantics of that attribute.
> > >
> > > Denis,
> > >
> > > Where is the semantics broken?
> > >
> > > Who says that a serial number need to start with 1 and be sequential
with
> > > increment = 1
> > >
> > > You have only to look at most software products, TV sets or similar to
see
> > > another truth.
> > > 676767666767 is a perfectly fine serial number to me.
> > >
> > > /Stefan
> > >
> > >
> > >
> > >
> > > _____________________________
> > > Stefan Santesson,  Retrospekt AB
> > > http://www.retrospekt.com
> > > [phone]
> > >
>
> _____________________________
> Stefan Santesson,  Retrospekt AB
> http://www.retrospekt.com
> [phone]
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2C35WY22911 for ietf-pkix-bks; Tue, 11 Mar 2003 19:05:32 -0800 (PST)
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2C35U322907 for <[e-mail]>; Tue, 11 Mar 2003 19:05:30 -0800 (PST)
Received: from calendar.nist.gov (calendar-ether.nist.gov [129.6.16.10]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h2C35UCZ026211 for <[e-mail]>; Tue, 11 Mar 2003 22:05:30 -0500 (EST)
Received: from calendar.nist.gov (localhost [127.0.0.1]) by calendar.nist.gov (8.12.2/8.12.2) with ESMTP id h2C35T6E028516 for <[e-mail]>; Tue, 11 Mar 2003 22:05:29 -0500 (EST)
Received: (from nobody@localhost) by calendar.nist.gov (8.12.2/8.12.2/Submit) id h2C35TTB028513 for [e-mail]; Tue, 11 Mar 2003 22:05:29 -0500 (EST)
X-Authentication-Warning: calendar.nist.gov: nobody set sender to [e-mail] using -f
Received: from 141.156.219.32 ( [141.156.219.32]) as user [e-mail] by imp.nist.gov with HTTP; Tue, 11 Mar 2003 22:05:29 -0500
Message-ID: <[e-mail]>
Date: Tue, 11 Mar 2003 22:05:29 -0500
From: [e-mail]
To: [e-mail]
Subject: Draft Agenda for PKIX
MIME-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 2.3.7-cvs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

Here is the draft agenda for the PKIX meeting.  I believe I have accomodated 
all requests for a time slot.  If I missed your, please contact me ASAP.  In 
theory, we have twenty minutes of unused time.  However, I back loaded the 
agenda with the directory discussions.  If history serves, that is sure to 
consume the remaining time!

Thanks,

Tim Polk


--------------------Draft Agenda for PKIX at the 56th IETF-----------------


PKIX WG (pkix-wg)

THURSDAY, March 20, 2003 0900-1130
=================================

CHAIR: Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>

AGENDA:

1. Document Status Review Tim Polk (NIST)
      The working group has thirty two Internet-Drafts.  A number of 
      documents are with the ADs or in various stages of WG Last Call.
      Several others are ready for Last Call. (5 min.)

2. Delegated Path Discovery & Validation (DPD/DPV)

      The working group has completed the DPD/DPV Requirements document;
      this specification has become RFC 3379.  The requirements document was
      developed as baseline for evaluation of competing proposals.  The
      evaluation is complete and SCVP has been selected as the PKIX DPD/DPV
      protocol  (25 min. - 5 min. strawpoll, 15 min. SCVP, 5 min. discussion)

      2.1 DPD/DPV Protocol Selection    Tim Polk 
        
           The WG co-chairs selected SCVP as the PKIX protocol for DPD/DPV
           based on a strawpoll of the WG, along with evidence of compliance
           to the requirements stated in 3379.

      2.2 Simple Certificate Validation Protocol   Trevor Freeman (MicroSoft)

         http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-11.txt

           An additional draft of SCVP is expected to achieve full
           compliance with RFC 3379.  Analysis posted to the list suggests
           a list of possible open issues based on the compliance matrix.
           These issues will be addressed, then WG Last Call will commence.

      2.3 Open Mike Discussion DPD/DPV Protocols

3. Proxy Certificate Profile - Von Welch (Univ. of Chicago)

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-04.txt

      Use of a proxy credential for impersonation is a common technique used in
      security systems, allowing an entity A to grant to another entity B the
      right for B to authenticate with others as if it were A.  This document
      defines a certificate profile for proxy credentials based on RFC 3280.
      (10 min.)

4. Attribute Certificate Policy extension - Christopher Francis (WetStone)

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-
02.txt

      This document defines an attribute certificate policy extension, which is
      an analog to the certificate policies extension for public key 
certificates.
      This extension can be used to assert the policy governing issuance of the
      attribute certificate in which it appears. (10 min.)

5.  Trusted Archive Protocol - Carl Wallace (Cygnacom)

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-tap-00.txt

      A Trusted Archive Authority (TAA) is a service that supports long-
      term non-repudiation by maintaining secure storage of 
      cryptographically refreshed information.  This document defines a set 
      of transactions for interacting with a Trusted Archive Authority 
      (TAA) and establishes a means of representing archived information.
      (10 min.)

6.  RFC 3039bis Qualified Certificates Update - Stefan Santesson (Retrospekt)

      http://www.ietf.org/internet-drafts/draft-ietf-pkix-sonof3039-00.txt

      An update to RFC 3039, Qualified Certificate Profile, has been submitted.
      The presentation will describe the proposed modifications and the 
supporting
      rationale for those changes.  (10 min.)

7.  RFC 3280 Interoperability Testing Report - Tim Polk (NIST)

      NIST is currently performing the interoperability testing for RFC 3280.
      This presentation will update the WG on NIST's progress, projected
      completion date, and issues identified to date.  (5 min.)

8.  European Open Standards for Electronic Signatures: the EESSI
                                             - Riccardo Genghini (SG&A)

      The European Elctronic Signature Standardization Initiative (EESSI) is an
      industry initiative in Support of the European Directive on Electronic
      Signatures.  EESSI is entering the maintenance phase for their 
specifications,
      and would like to factor feedback from the technical experts in PKIX into
      their evolution. (10 min.)

9. Multi Domian PKI Test Suite -- the result of JNSA Challenge PKI 2002
                                                          Ryu Inada (JNSA)

      The Japan Network Security Association conducted JNSA Challenge PKI 2002.
      One of the results was a Multi-Domain PKI Test Suite.  This presentation
      will include a brief demonstration of the test suite. (10 min.)

10. Maximizing Alignment Between X.500 and LDAP - Skip Slone (Lockheed Martin)

      http://www.ietf.org/internet-drafts/draft-slone-ldap-x500-align-00.txt 

      This personal draft is intended to provide information of interest to 
      developers of Lightweight Directory Access Protocol (LDAP) specifications
      and products.  It is intended to provide background information and to
      facilitate discussion within IETF Working Groups, most notably LDAPbis.
      This presentation will focus on the alignment of features used when
      supporting PKI (10 min.)

11. LDAP: Schemas, String Values, and more - David Chadwick (Univ of Salford)
                                 Kurt Zeilenga, co-chair of LDAPbis (OpenLDAP)

      LDAP is a critical technology for distribution of certificates and CRLs,
      but there are interoperability issues when used to support PKIX
      implementations. Some functional requirements (e.g., directory searches 
      based on certificate contents) remain unmet.  Some of these problems
      need to be resolved in the PKIX WG; others are in the LDAPbis WG problem
      space.  We have a number of unresolved issues to discuss including scope 
      of work for the LDAP PKI schema, matching rules, and string values for DN
      attributes.  The presentation will include the options for PKIX, along
      with recommendations from LDAPbis. (25 min.)


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BNSHm15566 for ietf-pkix-bks; Tue, 11 Mar 2003 15:28:17 -0800 (PST)
Received: from vmmr7.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BNSF315553 for <[e-mail]>; Tue, 11 Mar 2003 15:28:15 -0800 (PST)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id OSR69840; Tue, 11 Mar 2003 18:28:15 -0500 (EST)
Received: from laptop-cpq.retrospekt.com (1Cust122.tnt1.stk3.swe.da.uu.net [213.116.224.122]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ABV11375; Tue, 11 Mar 2003 18:28:12 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 12 Mar 2003 00:27:32 +0100
To: "todd glassey" <[e-mail]>, "Denis Pinkas" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
Cc: <[e-mail]>
In-Reply-To: <016901c2e823$713f52f0$020aff0a@tsg1>
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]> <[e-mail]> <[e-mail]> <004401c2e72f$b4c03610$0500a8c0@arport> <[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>

Todd,

Is there anything in this statment that reveals any problem with the way 
RFC 3039 defines use of the SN attribute?

/Stefan

At 14:53 2003-03-11 -0800, todd glassey wrote:
>Stefan - the key issue is that SN's are only comparable to SN's issued by
>the same instance or ones that are correlated between instances. The SN
>itself is a component of the Policy Control process and so it is only
>relevant to like instances, which is why timestamps are so important - since
>they in many senses represent portable SN's - or ones that are easily
>compared between machines.
>
>Todd
>
>----- Original Message -----
>From: "Stefan Santesson" <[e-mail]>
>To: "Denis Pinkas" <[e-mail]>
>Cc: <[e-mail]>
>Sent: Tuesday, March 11, 2003 12:37 PM
>Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
>
>
> >
> > At 17:57 2003-03-11 +0100, Denis Pinkas wrote:
> >  >I do kown that in fact 676767666767 would allow to uniquely identify the
> > individual, but this is not the semantics of that attribute.
> >
> > Denis,
> >
> > Where is the semantics broken?
> >
> > Who says that a serial number need to start with 1 and be sequential with
> > increment = 1
> >
> > You have only to look at most software products, TV sets or similar to see
> > another truth.
> > 676767666767 is a perfectly fine serial number to me.
> >
> > /Stefan
> >
> >
> >
> >
> > _____________________________
> > Stefan Santesson,  Retrospekt AB
> > http://www.retrospekt.com
> > [phone]
> >

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone] 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BNBoQ14329 for ietf-pkix-bks; Tue, 11 Mar 2003 15:11:50 -0800 (PST)
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BNBm314325 for <[e-mail]>; Tue, 11 Mar 2003 15:11:48 -0800 (PST)
Received: from tsg1 (unknown[12.81.120.63]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003031123114211200mcm6ge>; Tue, 11 Mar 2003 23:11:43 +0000
Message-ID: <016901c2e823$713f52f0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]> <[e-mail]> <[e-mail]> <004401c2e72f$b4c03610$0500a8c0@arport> <[e-mail]>
Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
Date: Tue, 11 Mar 2003 14:53:28 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan - the key issue is that SN's are only comparable to SN's issued by
the same instance or ones that are correlated between instances. The SN
itself is a component of the Policy Control process and so it is only
relevant to like instances, which is why timestamps are so important - since
they in many senses represent portable SN's - or ones that are easily
compared between machines.

Todd

----- Original Message -----
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, March 11, 2003 12:37 PM
Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda


>
> At 17:57 2003-03-11 +0100, Denis Pinkas wrote:
>  >I do kown that in fact 676767666767 would allow to uniquely identify the
> individual, but this is not the semantics of that attribute.
>
> Denis,
>
> Where is the semantics broken?
>
> Who says that a serial number need to start with 1 and be sequential with
> increment = 1
>
> You have only to look at most software products, TV sets or similar to see
> another truth.
> 676767666767 is a perfectly fine serial number to me.
>
> /Stefan
>
>
>
>
> _____________________________
> Stefan Santesson,  Retrospekt AB
> http://www.retrospekt.com
> [phone]
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BLoOS11346 for ietf-pkix-bks; Tue, 11 Mar 2003 13:50:24 -0800 (PST)
Received: from vmmr7.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BLoM311339 for <[e-mail]>; Tue, 11 Mar 2003 13:50:22 -0800 (PST)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id OSR57453; Tue, 11 Mar 2003 16:50:14 -0500 (EST)
Received: from laptop-cpq.retrospekt.com (2Cust95.tnt8.stk3.swe.da.uu.net [213.116.241.95]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ABU95769; Tue, 11 Mar 2003 16:50:08 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 11 Mar 2003 22:49:28 +0100
To: Sharon Boeyen <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: RE: QC Declaration
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_302478601==.ALT"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Sharon,

The first step for me is to get the mechanics right.

Are you saying that it would have been compliant with X.509 to declare that 
a critical QCStatement (disregarding the current declaration in RFC 3039) 
is valid if I can process at least one of the present statements (similar 
to SubjectAltName).

Not that I claim that it would be a good idea.

/Stefan


At 16:30 2003-03-11 -0500, Sharon Boeyen wrote:
>I don't want to get off on a non-relevant tangent regarding criticality, 
>but think I do need to clarify a little bit on the subject Alt Name 
>extension. If you check 8.3.2.3 (509) you'll find that the semantics of 
>that extension are such that, if set to critical, "at least one of the 
>name forms that is present shall be recognized and processed ...". So if, 
>in your example, the ONLY name present in subjectAltName extension is the 
>unknown otherName OID, then you are correct and the certificate shall be 
>considered invalid. If however, that unknown otherName OID was present AND 
>and rfc822Name was present - the RP might understand the rfc822Name and 
>check it against the intended recipient of an encrypted email for example, 
>and under those circumstances the certificate would be valid, even though 
>the extension was critical and there was another nameform in there that 
>was not understood.
>
>I suspect that its probably a bit too soon to profile the kind of contexts 
>I think you're describing in 3039. I'd prefer to see a bit more practical 
>use of QCs first so that we have a better handle on what constitutes a 
>"context". For example, perhaps one context is with the ETSI qcstatement 1 
>plus a specific national qc statement and if both are present in a 
>certificate that some 'authority' (I don't mean a CA here) deems that when 
>that combination is present the extension shall be set to critical. I'm 
>not necessarily opposing the idea, just a little uncomfortable with the 
>proposed timing without significant real world deployment to guide us with 
>to the appropriate 'contexts'.
>
>Cheers,
>Sharon
>-----Original Message-----
>From: Stefan Santesson [mailto:[e-mail]]
>Sent: Tuesday, March 11, 2003 4:06 PM
>To: Sharon Boeyen; Sharon Boeyen; [e-mail]
>Subject: RE: QC Declaration
>
>Sharon,
>Thanks for the clarification.
>
>"Elements of the syntax" really clarifies things.
>
>So it is OK to accept an certificate with a critical policy extension 
>containing an policy OID that I don't recognize, because it doesn't define 
>any further syntax of the extension.
>The same goes with Extended key usage OIDs.
>
>However. It would not be OK with a critical subjectAltName containing an 
>unknown other name OID, since this OID would define further syntax.
>By the same reason I would need to understand all present QCStatements 
>OIDs, because they do the same (define further syntax).
>
>
>Let me clarify that I never proposed that the QCStatement must be critical 
>in all certificates.
>I'm just recognizing that it might be a valuable practice within certain 
>contexts and the fact that some implementers actually ask for it.
>The question is whether any of those contexts can be identified within RFC 
>3039, or if they are better placed in local sub-profiles (Such as ETSI TS 
>101862), or if they don't exist in a way that can be standardized in a 
>meaningful way.
>
>
>/Stefan
>
>
>At 11:37 2003-03-11 -0500, Sharon Boeyen wrote:
>>Hi Stefan,
>>
>>Remember first that RFC 3280 is a "profile" of X.509 and it does not 
>>replace the requirements of 509, but rather profiles them to a subset.
>>
>>X.509 in clause 7 allows unknown elements in non-critical extensions only 
>>to be ignored. However, that is more with respect to the elements in the 
>>syntax
>>itself (for example in the IDP extension no RP is allowed to ignore the 
>>"onlySomeReasons" element if it is present in the extension because the 
>>extension
>>can only be critical. The behaviour of RPs will differ however depending 
>>on their specific capability with respect to that element (some will use 
>>the CRL for
>>the specified reasons and others will seek a different CRL that covers 
>>all reasons), however, no RP is permitted to simply ignore the flag. Note 
>>also that in that
>>same clause, for extensions that can be marked critical or non-critical, 
>>a system that understands the extension is required to process it 
>>regardless of the
>>value of the criticality flag. It is ONLY systems that do not understand 
>>an extension that can ignore it completely if it is marked non-critical.
>>
>>For the QC Statements extension, RFC 3039 says "This extension may be 
>>critical or non-critical.  If the extension is critical, this means that 
>>all statements
>>included in the extension are regarded as critical. "
>>
>>Because of the semantics defined for the extension in RFC 3039, marking 
>>it critical would result in the problems I raised.
>>
>>-----Original Message-----
>>From: Stefan Santesson [mailto:[e-mail]]
>>Sent: Tuesday, March 11, 2003 11:23 AM
>>To: Sharon Boeyen; [e-mail]
>>Subject: RE: QC Declaration
>>
>>Hi Sharon,
>>My interpretation of criticality does not really match yours.
>>The only guidance on the meaning of criticality in RFC 3280 (section 4.2) 
>>that I can find is:
>>
>>
>>
>>   "A certificate using system MUST reject the
>>
>>certificate
>>
>>
>>if it encounters a critical extension it does not recognize"
>>
>>My interpretation is that it is OK to accept a certificate if you 
>>recognize the extension as such. You don't need to understand ALL 
>>information that the extension contains.
>>It seam vital to agree on this issue before we can make any conclusion on 
>>QCStatament criticality.
>>/Stefan
>>
>>At 10:56 2003-03-11 -0500, Sharon Boeyen wrote:
>>>Hi Stefan,
>>>While I believe that in the longer term certificate policies will be the
>>>optimum
>>>way to convey the necessary information, I acknowledge that QC 
>>>Statements is
>>>the
>>>more popular scheme at present. Therefore I wouldn't have any problem 
>>>should
>>>this
>>>extension be mandated in RFC 3039.
>>>However, forcing its criticality is going too far I believe. There is an
>>>important
>>>difference between critical and non-critical extensions that we need to 
>>>keep
>>>in
>>>mind from the relying party's perspective. If there is a non-critical
>>>extension that
>>>the RP understands, but that extension includes some elements that it does
>>>not, then
>>>the RP is free to process the parts it does understand and ignore 
>>>others. If
>>>an extension
>>>is critical however, the RP is required to understand ALL elements within
>>>the extension.
>>>Where I think this can become a problem is the content of the QC Statements
>>>extension. Note
>>>that RFC 3039 and the ETSI profile define DIFFERENT statements for 
>>>inclusion
>>>in the extension.
>>>Also additional profiles may add their own local statements and even
>>>narrower statements can
>>>get added in specific deployment environments. While the cert issuer may
>>>want to include many
>>>of these statements to enable the cert to be used in various environments,
>>>the RP should only
>>>be required to understand and process the statements that are 
>>>appropriate to
>>>its own
>>>operating environment as dictated by its local security policy (which could
>>>be different than
>>>that under which the CA operated). Therefore I think requiring it to be
>>>critical is risky.
>>>Also requiring that it always be critical would have interop/backward
>>>compatibility issues.
>>>Cheers,
>>>Sharon
>>>
>>>
>>>
>>>
>>>-----Original Message-----
>>>From: Stefan Santesson [mailto:[e-mail]]
>>>Sent: Tuesday, March 11, 2003 8:27 AM
>>>To: [e-mail]
>>>Subject: QC Declaration
>>>
>>>
>>>The EU directive introduced a requirement on each CA, issuing QC (Qualified
>>>Certificates), to clearly indicate in these certificate that they are
>>>issued as QC.
>>>ETSI implemented RFC 3039 in relation to the European electronic signature
>>>directive through their Technical Standard (TS 101862)
>>>TS 101862 specified 2 alternative ways to declare a certificate as QC.
>>>1) By inclusion of a QCStatements extension
>>>2) By including a certificate policy identifying this property
>>>Even though solution number 1) is far easier to handle by applications,
>>>since they don't need to recognize specific QC Policies, ETSI didn't make
>>>solution 1) mandatory or even consider making it critical, due to lack of
>>>confidence that clients would widely deploy this solution. ETSI needed to
>>>define a solution that could work even if no one choose to implement the
>>>new extensions provided by RFC 3039.
>>>However, It is not feasible to keep clients updated over time with
>>>different QC policies and even those policies that are regarded
>>>standardized may be updated with change of OID as a result. It would be
>>>devastating if we can't update a QCP because that would force an OID update
>>>and that would render certificates useless because clients learned to
>>>recognize only the old OID. This would be to build in a new root
>>>certificate problem into the platforms.
>>>My observations is that times have changed. I have seen clear indications
>>>that market players want, and even require for interoperability reasons,
>>>that use QCStatements solution is made mandatory and maybe even critical
>>>for QC.
>>>Since both RFC 3039, and TS 101862 are up for revision, it is time to
>>>revisit this issue.
>>>I have some questions and proposals:
>>>- Is there any experiences of this issue outside of Europe. I.e. are there
>>>other legal systems that make use of the same declaration logic as the EU
>>>directive, where the RFC 3039 profile is used fully or partly as a solution
>>>to this issue?
>>>- I would suggest that the QCStatement mechanism is ought to be a mandatory
>>>tool to communicate a Qualified Status. The question is:
>>>     1) whether this will have enough implementation support to succeed?
>>>     2) whether is best specified in RFC 3039 or in local profiles (such as
>>>TS 101862)?
>>>     3) If there could be a clear context defined where criticality 
>>> could be
>>>allowed or even required?
>>>I would really like feedback from practical experiences from this issue, as
>>>well as constructive proposals.
>>>/Stefan
>>>
>>>
>>>
>>>/Stefan
>>>
>>>
>>>_____________________________
>>>Stefan Santesson,  Retrospekt AB
>>>http://www.retrospekt.com
>>>[phone]
>>_____________________________
>>Stefan Santesson,  Retrospekt AB
>>http://www.retrospekt.com
>>[phone]
>
>_____________________________
>Stefan Santesson,  Retrospekt AB
>http://www.retrospekt.com
>[phone]

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone] 
--=====================_302478601==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Sharon,<br><br>
The first step for me is to get the mechanics right.<br><br>
Are you saying that it would have been compliant with X.509 to declare
that a critical QCStatement (disregarding the current declaration in RFC
3039) is valid if I can process at least one of the present statements
(similar to SubjectAltName).<br><br>
Not that I claim that it would be a good idea.<br><br>
/Stefan<br><br>
<br>
At 16:30 2003-03-11 -0500, Sharon Boeyen wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#0000FF">I
don't want to get off on a non-relevant tangent regarding criticality,
but think I do need to clarify a little bit on the subject Alt Name
extension. If you check 8.3.2.3 (509) you'll find that the semantics of
that extension are such that, if set to critical, &quot;at least one of
the name forms that is present shall be recognized and processed
...&quot;. So if, in your example, the ONLY name present in
subjectAltName extension is the unknown otherName OID, then you are
correct and the certificate shall be considered invalid. If however, that
unknown otherName OID was present AND and rfc822Name was present - the RP
might understand the rfc822Name and check it against the intended
recipient of an encrypted email for example, and under those
circumstances the certificate would be valid, even though the extension
was critical and there was another nameform in there that was not
understood.</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">I suspect that its probably a
bit too soon to profile the kind of contexts I think you're describing in
3039. I'd prefer to see a bit more practical use of QCs first so that we
have a better handle on what constitutes a &quot;context&quot;. For
example, perhaps one context is with the ETSI qcstatement 1 plus a
specific national qc statement and if both are present in a certificate
that some 'authority' (I don't mean a CA here) deems that when that
combination is present the extension shall be set to critical. I'm not
necessarily opposing the idea, just a little uncomfortable with the
proposed timing without significant real world deployment to guide us
with to the appropriate 'contexts'.</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Cheers,</font><br>
<font face="arial" size=2 color="#0000FF">Sharon</font><br>

<dl>
<dd><font face="tahoma" size=2>-----Original Message-----<br>

<dd>From:</b> Stefan Santesson
[<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>]<br>

<dd>Sent:</b> Tuesday, March 11, 2003 4:06 PM<br>

<dd>To:</b> Sharon Boeyen; Sharon Boeyen; [e-mail]<br>

<dd>Subject:</b> RE: QC Declaration<br><br>
</font>
<dd>Sharon,<br>

<dd>Thanks for the clarification.<br><br>

<dd>&quot;Elements of the syntax&quot; really clarifies things.<br><br>

<dd>So it is OK to accept an certificate with a critical policy extension
containing an policy OID that I don't recognize, because it doesn't
define any further syntax of the extension.<br>

<dd>The same goes with Extended key usage OIDs.<br><br>

<dd>However. It would not be OK with a critical subjectAltName containing
an unknown other name OID, since this OID would define further
syntax.<br>

<dd>By the same reason I would need to understand all present
QCStatements OIDs, because they do the same (define further
syntax).<br><br>
<br>

<dd>Let me clarify that I never proposed that the QCStatement must be
critical in all certificates.<br>

<dd>I'm just recognizing that it might be a valuable practice within
certain contexts and the fact that some implementers actually ask for
it.<br>

<dd>The question is whether any of those contexts can be identified
within RFC 3039, or if they are better placed in local sub-profiles (Such
as ETSI TS 101862), or if they don't exist in a way that can be
standardized in a meaningful way.<br><br>
<br>

<dd>/Stefan<br><br>
<br>

<dd>At 11:37 2003-03-11 -0500, Sharon Boeyen wrote:<br>
<blockquote type=cite class=cite cite>
<dd><font face="arial" size=2 color="#0000FF">Hi Stefan,</font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2 color="#0000FF">Remember first that RFC
3280 is a &quot;profile&quot; of X.509 and it does not replace the
requirements of 509, but rather profiles them to a subset. </font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2 color="#0000FF">X.509 in clause 7 allows
unknown elements in non-critical extensions only to be ignored. However,
that is more with respect to the elements in the syntax </font><br>

<dd><font face="arial" size=2 color="#0000FF">itself (for example in the
IDP extension no RP is allowed to ignore the &quot;onlySomeReasons&quot;
element if it is present in the extension because the extension
</font><br>

<dd><font face="arial" size=2 color="#0000FF">can only be critical. The
behaviour of RPs will differ however depending on their specific
capability with respect to that element (some will use the CRL for
</font><br>

<dd><font face="arial" size=2 color="#0000FF">the specified reasons and
others will seek a different CRL that covers all reasons), however, no RP
is permitted to simply ignore the flag. Note also that in
that</font><br>

<dd><font face="arial" size=2 color="#0000FF">same clause, for extensions
that can be marked critical or non-critical, a system that understands
the extension is required to process it regardless of the </font><br>

<dd><font face="arial" size=2 color="#0000FF">value of the criticality
flag. It is ONLY systems that do not understand an extension that can
ignore it completely if it is marked non-critical. </font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2 color="#0000FF">For the QC Statements
extension, RFC 3039 says &quot;This extension may be critical or
non-critical.&nbsp; If the extension is critical, this means that all
statements </font><br>

<dd><font face="arial" size=2 color="#0000FF">included in the extension
are regarded as
critical.</font><font face="Times New Roman, Times" size=2 color="#0000FF">
</font><font face="arial" size=2 color="#0000FF">&quot; </font><br>

<dd>&nbsp;<br>

<dd><font face="arial" size=2 color="#0000FF">Because of the semantics
defined for the extension in RFC 3039, marking it critical would result
in the problems I raised.
</font><font face="Times New Roman, Times" size=2 color="#0000FF"><br><br></font>
<dd><font face="tahoma" size=2>-----Original Message-----
<dd>From: Stefan Santesson
[<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>]
<dd>Sent: Tuesday, March 11, 2003 11:23 AM
<dd>To: Sharon Boeyen; [e-mail]
<dd>Subject: RE: QC Declaration<br><br>
</font>
<dd>Hi Sharon,<br>

<dd>My interpretation of criticality does not really match yours.<br>

<dd>The only guidance on the meaning of criticality in RFC 3280 (section
4.2) that I can find is:<br>
<br>
<br><br>

<dd><pre>&nbsp; &quot;A certificate using system MUST reject the

<dd>certificate


<dd>if it encounters a critical extension it does not recognize&quot;

</pre><font face="Courier New, Courier"></font>
<dd>My interpretation is that it is OK to accept a certificate if you
recognize the extension as such. You don't need to understand ALL
information that the extension contains.<br>

<dd>It seam vital to agree on this issue before we can make any
conclusion on QCStatament criticality.<br>

<dd>/Stefan<br>
<br>

<dd>At 10:56 2003-03-11 -0500, Sharon Boeyen
wrote:<blockquote type=cite class=cite cite>
<dd>Hi Stefan,<br>

<dd>While I believe that in the longer term certificate policies will be
the
<dd>optimum 
<dd>way to convey the necessary information, I acknowledge that QC
Statements is
<dd>the 
<dd>more popular scheme at present. Therefore I wouldn't have any problem
should
<dd>this 
<dd>extension be mandated in RFC 3039. <br>

<dd>However, forcing its criticality is going too far I believe. There is
an
<dd>important 
<dd>difference between critical and non-critical extensions that we need
to keep
<dd>in 
<dd>mind from the relying party's perspective. If there is a
non-critical
<dd>extension that 
<dd>the RP understands, but that extension includes some elements that it
does
<dd>not, then 
<dd>the RP is free to process the parts it does understand and ignore
others. If
<dd>an extension 
<dd>is critical however, the RP is required to understand ALL elements
within
<dd>the extension.<br>

<dd>Where I think this can become a problem is the content of the QC
Statements
<dd>extension. Note 
<dd>that RFC 3039 and the ETSI profile define DIFFERENT statements for
inclusion
<dd>in the extension. 
<dd>Also additional profiles may add their own local statements and 
even
<dd>narrower statements can 
<dd>get added in specific deployment environments. While the cert issuer
may
<dd>want to include many 
<dd>of these statements to enable the cert to be used in various
environments,
<dd>the RP should only 
<dd>be required to understand and process the statements that are
appropriate to
<dd>its own 
<dd>operating environment as dictated by its local security policy (which
could
<dd>be different than 
<dd>that under which the CA operated). Therefore I think requiring it to
be
<dd>critical is risky. 
<dd>Also requiring that it always be critical would have
interop/backward
<dd>compatibility issues.<br>

<dd>Cheers,
<dd>Sharon<br>
<br>
<br>
<br>

<dd>&nbsp; 
<dd>-----Original Message-----
<dd>From: Stefan Santesson
[<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>]
<dd>Sent: Tuesday, March 11, 2003 8:27 AM
<dd>To: [e-mail]
<dd>Subject: QC Declaration<br>
<br>
<br>

<dd>The EU directive introduced a requirement on each CA, issuing QC
(Qualified 
<dd>Certificates), to clearly indicate in these certificate that they are 
<dd>issued as QC.<br>

<dd>ETSI implemented RFC 3039 in relation to the European electronic
signature 
<dd>directive through their Technical Standard (TS 101862)<br>

<dd>TS 101862 specified 2 alternative ways to declare a certificate as
QC.<br>

<dd>1) By inclusion of a QCStatements extension
<dd>2) By including a certificate policy identifying this property<br>

<dd>Even though solution number 1) is far easier to handle by
applications, 
<dd>since they don't need to recognize specific QC Policies, ETSI didn't
make 
<dd>solution 1) mandatory or even consider making it critical, due to
lack of 
<dd>confidence that clients would widely deploy this solution. ETSI
needed to 
<dd>define a solution that could work even if no one choose to implement
the 
<dd>new extensions provided by RFC 3039.<br>

<dd>However, It is not feasible to keep clients updated over time with 
<dd>different QC policies and even those policies that are regarded 
<dd>standardized may be updated with change of OID as a result. It would
be 
<dd>devastating if we can't update a QCP because that would force an OID
update 
<dd>and that would render certificates useless because clients learned to 
<dd>recognize only the old OID. This would be to build in a new root 
<dd>certificate problem into the platforms.<br>

<dd>My observations is that times have changed. I have seen clear
indications 
<dd>that market players want, and even require for interoperability
reasons, 
<dd>that use QCStatements solution is made mandatory and maybe even
critical 
<dd>for QC.<br>

<dd>Since both RFC 3039, and TS 101862 are up for revision, it is time to 
<dd>revisit this issue.<br>

<dd>I have some questions and proposals:<br>

<dd>- Is there any experiences of this issue outside of Europe. I.e. are
there 
<dd>other legal systems that make use of the same declaration logic as
the EU 
<dd>directive, where the RFC 3039 profile is used fully or partly as a
solution 
<dd>to this issue?<br>

<dd>- I would suggest that the QCStatement mechanism is ought to be a
mandatory 
<dd>tool to communicate a Qualified Status. The question is:
<dd>&nbsp;&nbsp;&nbsp; 1) whether this will have enough implementation
support to succeed?
<dd>&nbsp;&nbsp;&nbsp; 2) whether is best specified in RFC 3039 or in
local profiles (such as 
<dd>TS 101862)?
<dd>&nbsp;&nbsp;&nbsp; 3) If there could be a clear context defined where
criticality could be 
<dd>allowed or even required?<br>

<dd>I would really like feedback from practical experiences from this
issue, as 
<dd>well as constructive proposals.<br>

<dd>/Stefan<br>
<br>
<br>
<br>

<dd>/Stefan<br>
<br>
<br>

<dd>_____________________________
<dd>Stefan Santesson,&nbsp; Retrospekt AB
<dd><a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a>
<dd>[phone] </blockquote>
<dd>_____________________________
<dd>Stefan Santesson,&nbsp; Retrospekt AB
<dd><a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a>
<dd>[phone] </blockquote>
</dl><br>
_____________________________<br>
Stefan Santesson,&nbsp; Retrospekt AB<br>
<a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a><br>
[phone] <br>
</blockquote>
<x-sigsep><p></x-sigsep>
_____________________________<br>
Stefan Santesson,&nbsp; Retrospekt AB<br>
<a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a><br>
[phone]</body>
</html>

--=====================_302478601==.ALT--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BLUDB09896 for ietf-pkix-bks; Tue, 11 Mar 2003 13:30:13 -0800 (PST)
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BLUC309889 for <[e-mail]>; Tue, 11 Mar 2003 13:30:12 -0800 (PST)
Received: from SOTTMXS01.entrust.com (sottmxs01.entrust.com [10.4.61.7]) by sottmxssm.entrust.com (Switch-2.2.5/Switch-2.2.4) with ESMTP id V2BL0RS932450; Tue, 11 Mar 2003 16:27:28 -0500
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <GXR5NGWN>; Tue, 11 Mar 2003 16:30:06 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, [e-mail]
Subject: RE: QC Declaration
Date: Tue, 11 Mar 2003 16:30:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E815.619F1CD0"
Sender: [e-mail]
Precedence: 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_01C2E815.619F1CD0
Content-Type: text/plain

I don't want to get off on a non-relevant tangent regarding criticality, but
think I do need to clarify a little bit on the subject Alt Name extension.
If you check 8.3.2.3 (509) you'll find that the semantics of that extension
are such that, if set to critical, "at least one of the name forms that is
present shall be recognized and processed ...". So if, in your example, the
ONLY name present in subjectAltName extension is the unknown otherName OID,
then you are correct and the certificate shall be considered invalid. If
however, that unknown otherName OID was present AND and rfc822Name was
present - the RP might understand the rfc822Name and check it against the
intended recipient of an encrypted email for example, and under those
circumstances the certificate would be valid, even though the extension was
critical and there was another nameform in there that was not understood.
 
I suspect that its probably a bit too soon to profile the kind of contexts I
think you're describing in 3039. I'd prefer to see a bit more practical use
of QCs first so that we have a better handle on what constitutes a
"context". For example, perhaps one context is with the ETSI qcstatement 1
plus a specific national qc statement and if both are present in a
certificate that some 'authority' (I don't mean a CA here) deems that when
that combination is present the extension shall be set to critical. I'm not
necessarily opposing the idea, just a little uncomfortable with the proposed
timing without significant real world deployment to guide us with to the
appropriate 'contexts'.
 
Cheers,
Sharon

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]
Sent: Tuesday, March 11, 2003 4:06 PM
To: Sharon Boeyen; Sharon Boeyen; [e-mail]
Subject: RE: QC Declaration


Sharon,
Thanks for the clarification.

"Elements of the syntax" really clarifies things.

So it is OK to accept an certificate with a critical policy extension
containing an policy OID that I don't recognize, because it doesn't define
any further syntax of the extension.
The same goes with Extended key usage OIDs.

However. It would not be OK with a critical subjectAltName containing an
unknown other name OID, since this OID would define further syntax.
By the same reason I would need to understand all present QCStatements OIDs,
because they do the same (define further syntax).


Let me clarify that I never proposed that the QCStatement must be critical
in all certificates.
I'm just recognizing that it might be a valuable practice within certain
contexts and the fact that some implementers actually ask for it.
The question is whether any of those contexts can be identified within RFC
3039, or if they are better placed in local sub-profiles (Such as ETSI TS
101862), or if they don't exist in a way that can be standardized in a
meaningful way.


/Stefan


At 11:37 2003-03-11 -0500, Sharon Boeyen wrote:


Hi Stefan,
 
Remember first that RFC 3280 is a "profile" of X.509 and it does not replace
the requirements of 509, but rather profiles them to a subset. 
 
X.509 in clause 7 allows unknown elements in non-critical extensions only to
be ignored. However, that is more with respect to the elements in the syntax

itself (for example in the IDP extension no RP is allowed to ignore the
"onlySomeReasons" element if it is present in the extension because the
extension 
can only be critical. The behaviour of RPs will differ however depending on
their specific capability with respect to that element (some will use the
CRL for 
the specified reasons and others will seek a different CRL that covers all
reasons), however, no RP is permitted to simply ignore the flag. Note also
that in that
same clause, for extensions that can be marked critical or non-critical, a
system that understands the extension is required to process it regardless
of the 
value of the criticality flag. It is ONLY systems that do not understand an
extension that can ignore it completely if it is marked non-critical. 
 
For the QC Statements extension, RFC 3039 says "This extension may be
critical or non-critical.  If the extension is critical, this means that all
statements 
included in the extension are regarded as critical. " 
 
Because of the semantics defined for the extension in RFC 3039, marking it
critical would result in the problems I raised. 



-----Original Message-----


From: Stefan Santesson [ mailto:[e-mail]
<mailto:[e-mail]> ]


Sent: Tuesday, March 11, 2003 11:23 AM


To: Sharon Boeyen; [e-mail]


Subject: RE: QC Declaration



Hi Sharon,



My interpretation of criticality does not really match yours.



The only guidance on the meaning of criticality in RFC 3280 (section 4.2)
that I can find is:






  "A certificate using system MUST reject the

certificate


if it encounters a critical extension it does not recognize"



My interpretation is that it is OK to accept a certificate if you recognize
the extension as such. You don't need to understand ALL information that the
extension contains.



It seam vital to agree on this issue before we can make any conclusion on
QCStatament criticality.



/Stefan




At 10:56 2003-03-11 -0500, Sharon Boeyen wrote:



Hi Stefan,



While I believe that in the longer term certificate policies will be the


optimum 


way to convey the necessary information, I acknowledge that QC Statements is


the 


more popular scheme at present. Therefore I wouldn't have any problem should


this 


extension be mandated in RFC 3039. 



However, forcing its criticality is going too far I believe. There is an


important 


difference between critical and non-critical extensions that we need to keep


in 


mind from the relying party's perspective. If there is a non-critical


extension that 


the RP understands, but that extension includes some elements that it does


not, then 


the RP is free to process the parts it does understand and ignore others. If


an extension 


is critical however, the RP is required to understand ALL elements within


the extension.



Where I think this can become a problem is the content of the QC Statements


extension. Note 


that RFC 3039 and the ETSI profile define DIFFERENT statements for inclusion


in the extension. 


Also additional profiles may add their own local statements and even


narrower statements can 


get added in specific deployment environments. While the cert issuer may


want to include many 


of these statements to enable the cert to be used in various environments,


the RP should only 


be required to understand and process the statements that are appropriate to


its own 


operating environment as dictated by its local security policy (which could


be different than 


that under which the CA operated). Therefore I think requiring it to be


critical is risky. 


Also requiring that it always be critical would have interop/backward


compatibility issues.



Cheers,


Sharon






  

-----Original Message-----


From: Stefan Santesson [ mailto:[e-mail]
<mailto:[e-mail]> ]


Sent: Tuesday, March 11, 2003 8:27 AM


To: [e-mail]


Subject: QC Declaration





The EU directive introduced a requirement on each CA, issuing QC (Qualified 


Certificates), to clearly indicate in these certificate that they are 


issued as QC.



ETSI implemented RFC 3039 in relation to the European electronic signature 


directive through their Technical Standard (TS 101862)



TS 101862 specified 2 alternative ways to declare a certificate as QC.



1) By inclusion of a QCStatements extension


2) By including a certificate policy identifying this property



Even though solution number 1) is far easier to handle by applications, 


since they don't need to recognize specific QC Policies, ETSI didn't make 


solution 1) mandatory or even consider making it critical, due to lack of 


confidence that clients would widely deploy this solution. ETSI needed to 


define a solution that could work even if no one choose to implement the 


new extensions provided by RFC 3039.



However, It is not feasible to keep clients updated over time with 


different QC policies and even those policies that are regarded 


standardized may be updated with change of OID as a result. It would be 


devastating if we can't update a QCP because that would force an OID update 


and that would render certificates useless because clients learned to 


recognize only the old OID. This would be to build in a new root 


certificate problem into the platforms.



My observations is that times have changed. I have seen clear indications 


that market players want, and even require for interoperability reasons, 


that use QCStatements solution is made mandatory and maybe even critical 


for QC.



Since both RFC 3039, and TS 101862 are up for revision, it is time to 


revisit this issue.



I have some questions and proposals:



- Is there any experiences of this issue outside of Europe. I.e. are there 


other legal systems that make use of the same declaration logic as the EU 


directive, where the RFC 3039 profile is used fully or partly as a solution 


to this issue?



- I would suggest that the QCStatement mechanism is ought to be a mandatory 


tool to communicate a Qualified Status. The question is:


    1) whether this will have enough implementation support to succeed?


    2) whether is best specified in RFC 3039 or in local profiles (such as 


TS 101862)?


    3) If there could be a clear context defined where criticality could be 


allowed or even required?



I would really like feedback from practical experiences from this issue, as 


well as constructive proposals.



/Stefan






/Stefan





_____________________________


Stefan Santesson,  Retrospekt AB


http://www.retrospekt.com <http://www.retrospekt.com/> 


[phone] 


_____________________________


Stefan Santesson,  Retrospekt AB


http://www.retrospekt.com <http://www.retrospekt.com/> 


[phone] 





_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com <http://www.retrospekt.com/> 
[phone] 


------_=_NextPart_001_01C2E815.619F1CD0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">


<META content="MSHTML 5.50.4922.900" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=907592221-11032003><FONT face=Arial color=#0000ff size=2>I 
don't want to get off on a non-relevant tangent regarding criticality, but think 
I do need to clarify a little bit on the subject Alt Name extension. If you 
check 8.3.2.3 (509) you'll find that the semantics of that extension are such 
that, if set to critical, "at least one of the name forms that is present shall 
be recognized and processed ...". So if, in your example, the ONLY name present 
in subjectAltName extension is the unknown otherName OID, then you are correct 
and the certificate shall be considered invalid. If however, that unknown 
otherName OID was present AND and rfc822Name was present - the RP might 
understand the rfc822Name and check it against the intended recipient of an 
encrypted email for example, and under those circumstances the certificate would 
be valid, even though the extension was critical and there was another nameform 
in there that was not understood.</FONT></SPAN></DIV>
<DIV><SPAN class=907592221-11032003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=907592221-11032003><FONT face=Arial color=#0000ff size=2>I 
suspect that its probably a bit too soon to profile the kind of contexts I think 
you're describing in 3039. I'd prefer to see a bit more practical use of QCs 
first so that we have a better handle on what constitutes a "context". For 
example, perhaps one context is with the ETSI qcstatement 1 plus a specific 
national qc statement and if both are present in a certificate that some 
'authority' (I don't mean a CA here) deems that when that combination is present 
the extension shall be set to critical. I'm not necessarily opposing the idea, 
just a little uncomfortable with the proposed timing without significant real 
world deployment to guide us with to the appropriate 
'contexts'.</FONT></SPAN></DIV>
<DIV><SPAN class=907592221-11032003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=907592221-11032003><FONT face=Arial color=#0000ff 
size=2>Cheers,</FONT></SPAN></DIV>
<DIV><SPAN class=907592221-11032003><FONT face=Arial color=#0000ff 
size=2>Sharon</FONT></SPAN></DIV>
<BLOCKQUOTE>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Stefan Santesson 
  [mailto:[e-mail]]<BR><B>Sent:</B> Tuesday, March 11, 2003 4:06 
  PM<BR><B>To:</B> Sharon Boeyen; Sharon Boeyen; 
  [e-mail]<BR><B>Subject:</B> RE: QC 
  Declaration<BR><BR></FONT></DIV>Sharon,<BR>Thanks for the 
  clarification.<BR><BR>"Elements of the syntax" really clarifies 
  things.<BR><BR>So it is OK to accept an certificate with a critical policy 
  extension containing an policy OID that I don't recognize, because it doesn't 
  define any further syntax of the extension.<BR>The same goes with Extended key 
  usage OIDs.<BR><BR>However. It would not be OK with a critical subjectAltName 
  containing an unknown other name OID, since this OID would define further 
  syntax.<BR>By the same reason I would need to understand all present 
  QCStatements OIDs, because they do the same (define further 
  syntax).<BR><BR><BR>Let me clarify that I never proposed that the QCStatement 
  must be critical in all certificates.<BR>I'm just recognizing that it might be 
  a valuable practice within certain contexts and the fact that some 
  implementers actually ask for it.<BR>The question is whether any of those 
  contexts can be identified within RFC 3039, or if they are better placed in 
  local sub-profiles (Such as ETSI TS 101862), or if they don't exist in a way 
  that can be standardized in a meaningful way.<BR><BR><BR>/Stefan<BR><BR><BR>At 
  11:37 2003-03-11 -0500, Sharon Boeyen wrote:<BR>
  <BLOCKQUOTE class=cite cite type="cite"><FONT face=arial color=#0000ff 
    size=2>Hi Stefan,</FONT><BR>&nbsp;<BR><FONT face=arial color=#0000ff 
    size=2>Remember first that RFC 3280 is a "profile" of X.509 and it does not 
    replace the requirements of 509, but rather profiles them to a subset. 
    </FONT><BR>&nbsp;<BR><FONT face=arial color=#0000ff size=2>X.509 in clause 7 
    allows unknown elements in non-critical extensions only to be ignored. 
    However, that is more with respect to the elements in the syntax 
    </FONT><BR><FONT face=arial color=#0000ff size=2>itself (for example in the 
    IDP extension no RP is allowed to ignore the "onlySomeReasons" element if it 
    is present in the extension because the extension </FONT><BR><FONT 
    face=arial color=#0000ff size=2>can only be critical. The behaviour of RPs 
    will differ however depending on their specific capability with respect to 
    that element (some will use the CRL for </FONT><BR><FONT face=arial 
    color=#0000ff size=2>the specified reasons and others will seek a different 
    CRL that covers all reasons), however, no RP is permitted to simply ignore 
    the flag. Note also that in that</FONT><BR><FONT face=arial color=#0000ff 
    size=2>same clause, for extensions that can be marked critical or 
    non-critical, a system that understands the extension is required to process 
    it regardless of the </FONT><BR><FONT face=arial color=#0000ff size=2>value 
    of the criticality flag. It is ONLY systems that do not understand an 
    extension that can ignore it completely if it is marked non-critical. 
    </FONT><BR>&nbsp;<BR><FONT face=arial color=#0000ff size=2>For the QC 
    Statements extension, RFC 3039 says "This extension may be critical or 
    non-critical.&nbsp; If the extension is critical, this means that all 
    statements </FONT><BR><FONT face=arial color=#0000ff size=2>included in the 
    extension are regarded as critical.</FONT><FONT 
    face="Times New Roman, Times" color=#0000ff size=2> </FONT><FONT face=arial 
    color=#0000ff size=2>" </FONT><BR>&nbsp;<BR><FONT face=arial color=#0000ff 
    size=2>Because of the semantics defined for the extension in RFC 3039, 
    marking it critical would result in the problems I raised. </FONT><FONT 
    face="Times New Roman, Times" color=#0000ff size=2><BR><BR></FONT>
    <DL>
      <DD><FONT face=tahoma size=2>-----Original Message-----<BR>
      <DD>From:</B> Stefan Santesson [<A href="mailto:[e-mail]" 
      eudora="autourl">mailto:[e-mail]</A>]<BR>
      <DD>Sent:</B> Tuesday, March 11, 2003 11:23 AM<BR>
      <DD>To:</B> Sharon Boeyen; [e-mail]<BR>
      <DD>Subject:</B> RE: QC Declaration<BR><BR></FONT>
      <DD>Hi Sharon,<BR><BR>
      <DD>My interpretation of criticality does not really match yours.<BR><BR>
      <DD>The only guidance on the meaning of criticality in RFC 3280 (section 
      4.2) that I can find is:<BR><BR><BR>
      <DD><PRE>&nbsp; "A certificate using system MUST reject the
certificate

<DD>if it encounters a critical extension it does not recognize"

</DD></PRE><FONT face="Courier New, Courier"></FONT>
      <DD>My interpretation is that it is OK to accept a certificate if you 
      recognize the extension as such. You don't need to understand ALL 
      information that the extension contains.<BR><BR>
      <DD>It seam vital to agree on this issue before we can make any conclusion 
      on QCStatament criticality.<BR><BR>
      <DD>/Stefan<BR><BR><BR>
      <DD>At 10:56 2003-03-11 -0500, Sharon Boeyen wrote:<BR>
      <BLOCKQUOTE class=cite cite type="cite">
        <DD>Hi Stefan,<BR><BR>
        <DD>While I believe that in the longer term certificate policies will be 
        the<BR>
        <DD>optimum <BR>
        <DD>way to convey the necessary information, I acknowledge that QC 
        Statements is<BR>
        <DD>the <BR>
        <DD>more popular scheme at present. Therefore I wouldn't have any 
        problem should<BR>
        <DD>this <BR>
        <DD>extension be mandated in RFC 3039. <BR><BR>
        <DD>However, forcing its criticality is going too far I believe. There 
        is an<BR>
        <DD>important <BR>
        <DD>difference between critical and non-critical extensions that we need 
        to keep<BR>
        <DD>in <BR>
        <DD>mind from the relying party's perspective. If there is a 
        non-critical<BR>
        <DD>extension that <BR>
        <DD>the RP understands, but that extension includes some elements that 
        it does<BR>
        <DD>not, then <BR>
        <DD>the RP is free to process the parts it does understand and ignore 
        others. If<BR>
        <DD>an extension <BR>
        <DD>is critical however, the RP is required to understand ALL elements 
        within<BR>
        <DD>the extension.<BR><BR>
        <DD>Where I think this can become a problem is the content of the QC 
        Statements<BR>
        <DD>extension. Note <BR>
        <DD>that RFC 3039 and the ETSI profile define DIFFERENT statements for 
        inclusion<BR>
        <DD>in the extension. <BR>
        <DD>Also additional profiles may add their own local statements and 
        even<BR>
        <DD>narrower statements can <BR>
        <DD>get added in specific deployment environments. While the cert issuer 
        may<BR>
        <DD>want to include many <BR>
        <DD>of these statements to enable the cert to be used in various 
        environments,<BR>
        <DD>the RP should only <BR>
        <DD>be required to understand and process the statements that are 
        appropriate to<BR>
        <DD>its own <BR>
        <DD>operating environment as dictated by its local security policy 
        (which could<BR>
        <DD>be different than <BR>
        <DD>that under which the CA operated). Therefore I think requiring it to 
        be<BR>
        <DD>critical is risky. <BR>
        <DD>Also requiring that it always be critical would have 
        interop/backward<BR>
        <DD>compatibility issues.<BR><BR>
        <DD>Cheers,<BR>
        <DD>Sharon<BR><BR>
        <DD><BR><BR><BR>&nbsp;
        <DD>-----Original Message-----<BR>
        <DD>From: Stefan Santesson [<A href="mailto:[e-mail]" 
        eudora="autourl">mailto:[e-mail]</A>]<BR>
        <DD>Sent: Tuesday, March 11, 2003 8:27 AM<BR>
        <DD>To: [e-mail]<BR>
        <DD>Subject: QC Declaration<BR><BR><BR><BR>
        <DD>The EU directive introduced a requirement on each CA, issuing QC 
        (Qualified <BR>
        <DD>Certificates), to clearly indicate in these certificate that they 
        are <BR>
        <DD>issued as QC.<BR><BR>
        <DD>ETSI implemented RFC 3039 in relation to the European electronic 
        signature <BR>
        <DD>directive through their Technical Standard (TS 101862)<BR><BR>
        <DD>TS 101862 specified 2 alternative ways to declare a certificate as 
        QC.<BR><BR>
        <DD>1) By inclusion of a QCStatements extension<BR>
        <DD>2) By including a certificate policy identifying this 
        property<BR><BR>
        <DD>Even though solution number 1) is far easier to handle by 
        applications, <BR>
        <DD>since they don't need to recognize specific QC Policies, ETSI didn't 
        make <BR>
        <DD>solution 1) mandatory or even consider making it critical, due to 
        lack of <BR>
        <DD>confidence that clients would widely deploy this solution. ETSI 
        needed to <BR>
        <DD>define a solution that could work even if no one choose to implement 
        the <BR>
        <DD>new extensions provided by RFC 3039.<BR><BR>
        <DD>However, It is not feasible to keep clients updated over time with 
        <BR>
        <DD>different QC policies and even those policies that are regarded <BR>
        <DD>standardized may be updated with change of OID as a result. It would 
        be <BR>
        <DD>devastating if we can't update a QCP because that would force an OID 
        update <BR>
        <DD>and that would render certificates useless because clients learned 
        to <BR>
        <DD>recognize only the old OID. This would be to build in a new root 
<BR>
        <DD>certificate problem into the platforms.<BR><BR>
        <DD>My observations is that times have changed. I have seen clear 
        indications <BR>
        <DD>that market players want, and even require for interoperability 
        reasons, <BR>
        <DD>that use QCStatements solution is made mandatory and maybe even 
        critical <BR>
        <DD>for QC.<BR><BR>
        <DD>Since both RFC 3039, and TS 101862 are up for revision, it is time 
        to <BR>
        <DD>revisit this issue.<BR><BR>
        <DD>I have some questions and proposals:<BR><BR>
        <DD>- Is there any experiences of this issue outside of Europe. I.e. are 
        there <BR>
        <DD>other legal systems that make use of the same declaration logic as 
        the EU <BR>
        <DD>directive, where the RFC 3039 profile is used fully or partly as a 
        solution <BR>
        <DD>to this issue?<BR><BR>
        <DD>- I would suggest that the QCStatement mechanism is ought to be a 
        mandatory <BR>
        <DD>tool to communicate a Qualified Status. The question is:<BR>
        <DD>&nbsp;&nbsp;&nbsp; 1) whether this will have enough implementation 
        support to succeed?<BR>
        <DD>&nbsp;&nbsp;&nbsp; 2) whether is best specified in RFC 3039 or in 
        local profiles (such as <BR>
        <DD>TS 101862)?<BR>
        <DD>&nbsp;&nbsp;&nbsp; 3) If there could be a clear context defined 
        where criticality could be <BR>
        <DD>allowed or even required?<BR><BR>
        <DD>I would really like feedback from practical experiences from this 
        issue, as <BR>
        <DD>well as constructive proposals.<BR><BR>
        <DD>/Stefan<BR><BR><BR><BR><BR>
        <DD>/Stefan<BR><BR><BR><BR>
        <DD>_____________________________<BR>
        <DD>Stefan Santesson,&nbsp; Retrospekt AB<BR>
        <DD><A href="http://www.retrospekt.com/" 
        eudora="autourl">http://www.retrospekt.com</A><BR>
        <DD>[phone] </DD></BLOCKQUOTE><BR>
      <DD>_____________________________<BR>
      <DD>Stefan Santesson,&nbsp; Retrospekt AB<BR>
      <DD><A href="http://www.retrospekt.com/" 
      eudora="autourl">http://www.retrospekt.com</A><BR>
      <DD>[phone] <BR></DD></DL></BLOCKQUOTE><X-SIGSEP>
  <P></X-SIGSEP>
  <DL></DL>_____________________________<BR>Stefan Santesson,&nbsp; Retrospekt 
  AB<BR><A href="http://www.retrospekt.com/" 
  eudora="autourl">http://www.retrospekt.com</A><BR>[phone] 
</BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C2E815.619F1CD0--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BL6LZ08444 for ietf-pkix-bks; Tue, 11 Mar 2003 13:06:21 -0800 (PST)
Received: from vmmr8.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BL6J308434 for <[e-mail]>; Tue, 11 Mar 2003 13:06:19 -0800 (PST)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr8.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id AIG47993; Tue, 11 Mar 2003 16:06:16 -0500 (EST)
Received: from laptop-cpq.retrospekt.com (2Cust95.tnt8.stk3.swe.da.uu.net [213.116.241.95]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ABU87010; Tue, 11 Mar 2003 16:06:11 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 11 Mar 2003 22:05:31 +0100
To: Sharon Boeyen <[e-mail]>, Sharon Boeyen <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: RE: QC Declaration
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_299841419==.ALT"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Sharon,
Thanks for the clarification.

"Elements of the syntax" really clarifies things.

So it is OK to accept an certificate with a critical policy extension 
containing an policy OID that I don't recognize, because it doesn't define 
any further syntax of the extension.
The same goes with Extended key usage OIDs.

However. It would not be OK with a critical subjectAltName containing an 
unknown other name OID, since this OID would define further syntax.
By the same reason I would need to understand all present QCStatements 
OIDs, because they do the same (define further syntax).


Let me clarify that I never proposed that the QCStatement must be critical 
in all certificates.
I'm just recognizing that it might be a valuable practice within certain 
contexts and the fact that some implementers actually ask for it.
The question is whether any of those contexts can be identified within RFC 
3039, or if they are better placed in local sub-profiles (Such as ETSI TS 
101862), or if they don't exist in a way that can be standardized in a 
meaningful way.


/Stefan


At 11:37 2003-03-11 -0500, Sharon Boeyen wrote:
>Hi Stefan,
>
>Remember first that RFC 3280 is a "profile" of X.509 and it does not 
>replace the requirements of 509, but rather profiles them to a subset.
>
>X.509 in clause 7 allows unknown elements in non-critical extensions only 
>to be ignored. However, that is more with respect to the elements in the 
>syntax
>itself (for example in the IDP extension no RP is allowed to ignore the 
>"onlySomeReasons" element if it is present in the extension because the 
>extension
>can only be critical. The behaviour of RPs will differ however depending 
>on their specific capability with respect to that element (some will use 
>the CRL for
>the specified reasons and others will seek a different CRL that covers all 
>reasons), however, no RP is permitted to simply ignore the flag. Note also 
>that in that
>same clause, for extensions that can be marked critical or non-critical, a 
>system that understands the extension is required to process it regardless 
>of the
>value of the criticality flag. It is ONLY systems that do not understand 
>an extension that can ignore it completely if it is marked non-critical.
>
>For the QC Statements extension, RFC 3039 says "This extension may be 
>critical or non-critical.  If the extension is critical, this means that 
>all statements
>included in the extension are regarded as critical. "
>
>Because of the semantics defined for the extension in RFC 3039, marking it 
>critical would result in the problems I raised.
>
>-----Original Message-----
>From: Stefan Santesson [mailto:[e-mail]]
>Sent: Tuesday, March 11, 2003 11:23 AM
>To: Sharon Boeyen; [e-mail]
>Subject: RE: QC Declaration
>
>Hi Sharon,
>
>My interpretation of criticality does not really match yours.
>
>The only guidance on the meaning of criticality in RFC 3280 (section 4.2) 
>that I can find is:
>
>
>   "A certificate using system MUST reject the certificate
>
>if it encounters a critical extension it does not recognize"
>
>My interpretation is that it is OK to accept a certificate if you 
>recognize the extension as such. You don't need to understand ALL 
>information that the extension contains.
>
>It seam vital to agree on this issue before we can make any conclusion on 
>QCStatament criticality.
>
>/Stefan
>
>
>At 10:56 2003-03-11 -0500, Sharon Boeyen wrote:
>>Hi Stefan,
>>
>>While I believe that in the longer term certificate policies will be the
>>optimum
>>way to convey the necessary information, I acknowledge that QC Statements is
>>the
>>more popular scheme at present. Therefore I wouldn't have any problem should
>>this
>>extension be mandated in RFC 3039.
>>
>>However, forcing its criticality is going too far I believe. There is an
>>important
>>difference between critical and non-critical extensions that we need to keep
>>in
>>mind from the relying party's perspective. If there is a non-critical
>>extension that
>>the RP understands, but that extension includes some elements that it does
>>not, then
>>the RP is free to process the parts it does understand and ignore others. If
>>an extension
>>is critical however, the RP is required to understand ALL elements within
>>the extension.
>>
>>Where I think this can become a problem is the content of the QC Statements
>>extension. Note
>>that RFC 3039 and the ETSI profile define DIFFERENT statements for inclusion
>>in the extension.
>>Also additional profiles may add their own local statements and even
>>narrower statements can
>>get added in specific deployment environments. While the cert issuer may
>>want to include many
>>of these statements to enable the cert to be used in various environments,
>>the RP should only
>>be required to understand and process the statements that are appropriate to
>>its own
>>operating environment as dictated by its local security policy (which could
>>be different than
>>that under which the CA operated). Therefore I think requiring it to be
>>critical is risky.
>>Also requiring that it always be critical would have interop/backward
>>compatibility issues.
>>
>>Cheers,
>>Sharon
>>
>>
>>
>>
>>-----Original Message-----
>>From: Stefan Santesson [mailto:[e-mail]]
>>Sent: Tuesday, March 11, 2003 8:27 AM
>>To: [e-mail]
>>Subject: QC Declaration
>>
>>
>>
>>The EU directive introduced a requirement on each CA, issuing QC (Qualified
>>Certificates), to clearly indicate in these certificate that they are
>>issued as QC.
>>
>>ETSI implemented RFC 3039 in relation to the European electronic signature
>>directive through their Technical Standard (TS 101862)
>>
>>TS 101862 specified 2 alternative ways to declare a certificate as QC.
>>
>>1) By inclusion of a QCStatements extension
>>2) By including a certificate policy identifying this property
>>
>>Even though solution number 1) is far easier to handle by applications,
>>since they don't need to recognize specific QC Policies, ETSI didn't make
>>solution 1) mandatory or even consider making it critical, due to lack of
>>confidence that clients would widely deploy this solution. ETSI needed to
>>define a solution that could work even if no one choose to implement the
>>new extensions provided by RFC 3039.
>>
>>However, It is not feasible to keep clients updated over time with
>>different QC policies and even those policies that are regarded
>>standardized may be updated with change of OID as a result. It would be
>>devastating if we can't update a QCP because that would force an OID update
>>and that would render certificates useless because clients learned to
>>recognize only the old OID. This would be to build in a new root
>>certificate problem into the platforms.
>>
>>My observations is that times have changed. I have seen clear indications
>>that market players want, and even require for interoperability reasons,
>>that use QCStatements solution is made mandatory and maybe even critical
>>for QC.
>>
>>Since both RFC 3039, and TS 101862 are up for revision, it is time to
>>revisit this issue.
>>
>>I have some questions and proposals:
>>
>>- Is there any experiences of this issue outside of Europe. I.e. are there
>>other legal systems that make use of the same declaration logic as the EU
>>directive, where the RFC 3039 profile is used fully or partly as a solution
>>to this issue?
>>
>>- I would suggest that the QCStatement mechanism is ought to be a mandatory
>>tool to communicate a Qualified Status. The question is:
>>     1) whether this will have enough implementation support to succeed?
>>     2) whether is best specified in RFC 3039 or in local profiles (such as
>>TS 101862)?
>>     3) If there could be a clear context defined where criticality could be
>>allowed or even required?
>>
>>I would really like feedback from practical experiences from this issue, as
>>well as constructive proposals.
>>
>>/Stefan
>>
>>
>>
>>
>>/Stefan
>>
>>
>>
>>_____________________________
>>Stefan Santesson,  Retrospekt AB
>>http://www.retrospekt.com
>>[phone]
>
>_____________________________
>Stefan Santesson,  Retrospekt AB
>http://www.retrospekt.com
>[phone]

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone] 
--=====================_299841419==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Sharon,<br>
Thanks for the clarification.<br><br>
&quot;Elements of the syntax&quot; really clarifies things.<br><br>
So it is OK to accept an certificate with a critical policy extension
containing an policy OID that I don't recognize, because it doesn't
define any further syntax of the extension.<br>
The same goes with Extended key usage OIDs.<br><br>
However. It would not be OK with a critical subjectAltName containing an
unknown other name OID, since this OID would define further syntax.<br>
By the same reason I would need to understand all present QCStatements
OIDs, because they do the same (define further syntax).<br><br>
<br>
Let me clarify that I never proposed that the QCStatement must be
critical in all certificates.<br>
I'm just recognizing that it might be a valuable practice within certain
contexts and the fact that some implementers actually ask for it.<br>
The question is whether any of those contexts can be identified within
RFC 3039, or if they are better placed in local sub-profiles (Such as
ETSI TS 101862), or if they don't exist in a way that can be standardized
in a meaningful way.<br><br>
<br>
/Stefan<br><br>
<br>
At 11:37 2003-03-11 -0500, Sharon Boeyen wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2 color="#0000FF">Hi
Stefan,</font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Remember first that RFC 3280 is
a &quot;profile&quot; of X.509 and it does not replace the requirements
of 509, but rather profiles them to a subset. </font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">X.509 in clause 7 allows
unknown elements in non-critical extensions only to be ignored. However,
that is more with respect to the elements in the syntax </font><br>
<font face="arial" size=2 color="#0000FF">itself (for example in the IDP
extension no RP is allowed to ignore the &quot;onlySomeReasons&quot;
element if it is present in the extension because the extension
</font><br>
<font face="arial" size=2 color="#0000FF">can only be critical. The
behaviour of RPs will differ however depending on their specific
capability with respect to that element (some will use the CRL for
</font><br>
<font face="arial" size=2 color="#0000FF">the specified reasons and
others will seek a different CRL that covers all reasons), however, no RP
is permitted to simply ignore the flag. Note also that in
that</font><br>
<font face="arial" size=2 color="#0000FF">same clause, for extensions
that can be marked critical or non-critical, a system that understands
the extension is required to process it regardless of the </font><br>
<font face="arial" size=2 color="#0000FF">value of the criticality flag.
It is ONLY systems that do not understand an extension that can ignore it
completely if it is marked non-critical. </font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">For the QC Statements
extension, RFC 3039 says &quot;This extension may be critical or
non-critical.&nbsp; If the extension is critical, this means that all
statements </font><br>
<font face="arial" size=2 color="#0000FF">included in the extension are
regarded as
critical.</font><font face="Times New Roman, Times" size=2 color="#0000FF">
</font><font face="arial" size=2 color="#0000FF">&quot; </font><br>
&nbsp;<br>
<font face="arial" size=2 color="#0000FF">Because of the semantics
defined for the extension in RFC 3039, marking it critical would result
in the problems I raised.
</font><font face="Times New Roman, Times" size=2 color="#0000FF"><br><br>
</font>
<dl>
<dd><font face="tahoma" size=2>-----Original Message-----<br>

<dd>From:</b> Stefan Santesson
[<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>]<br>

<dd>Sent:</b> Tuesday, March 11, 2003 11:23 AM<br>

<dd>To:</b> Sharon Boeyen; [e-mail]<br>

<dd>Subject:</b> RE: QC Declaration<br><br>
</font>
<dd>Hi Sharon,<br><br>

<dd>My interpretation of criticality does not really match
yours.<br><br>

<dd>The only guidance on the meaning of criticality in RFC 3280 (section
4.2) that I can find is:<br><br>
<br>

<dd><pre>&nbsp; &quot;A certificate using system MUST reject the
certificate

<dd>if it encounters a critical extension it does not recognize&quot;

</pre><font face="Courier New, Courier"></font>
<dd>My interpretation is that it is OK to accept a certificate if you
recognize the extension as such. You don't need to understand ALL
information that the extension contains.<br><br>

<dd>It seam vital to agree on this issue before we can make any
conclusion on QCStatament criticality.<br><br>

<dd>/Stefan<br><br>
<br>

<dd>At 10:56 2003-03-11 -0500, Sharon Boeyen wrote:<br>
<blockquote type=cite class=cite cite>
<dd>Hi Stefan,<br><br>

<dd>While I believe that in the longer term certificate policies will be
the<br>

<dd>optimum <br>

<dd>way to convey the necessary information, I acknowledge that QC
Statements is<br>

<dd>the <br>

<dd>more popular scheme at present. Therefore I wouldn't have any problem
should<br>

<dd>this <br>

<dd>extension be mandated in RFC 3039. <br><br>

<dd>However, forcing its criticality is going too far I believe. There is
an<br>

<dd>important <br>

<dd>difference between critical and non-critical extensions that we need
to keep<br>

<dd>in <br>

<dd>mind from the relying party's perspective. If there is a
non-critical<br>

<dd>extension that <br>

<dd>the RP understands, but that extension includes some elements that it
does<br>

<dd>not, then <br>

<dd>the RP is free to process the parts it does understand and ignore
others. If<br>

<dd>an extension <br>

<dd>is critical however, the RP is required to understand ALL elements
within<br>

<dd>the extension.<br>
<br>

<dd>Where I think this can become a problem is the content of the QC
Statements<br>

<dd>extension. Note <br>

<dd>that RFC 3039 and the ETSI profile define DIFFERENT statements for
inclusion<br>

<dd>in the extension. <br>

<dd>Also additional profiles may add their own local statements and
even<br>

<dd>narrower statements can <br>

<dd>get added in specific deployment environments. While the cert issuer
may<br>

<dd>want to include many <br>

<dd>of these statements to enable the cert to be used in various
environments,<br>

<dd>the RP should only <br>

<dd>be required to understand and process the statements that are
appropriate to<br>

<dd>its own <br>

<dd>operating environment as dictated by its local security policy (which
could<br>

<dd>be different than <br>

<dd>that under which the CA operated). Therefore I think requiring it to
be<br>

<dd>critical is risky. <br>

<dd>Also requiring that it always be critical would have
interop/backward<br>

<dd>compatibility issues.<br><br>

<dd>Cheers,<br>

<dd>Sharon<br><br>

<dd>&nbsp;<br><br>
<br>

<dd>-----Original Message-----<br>

<dd>From: Stefan Santesson
[<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>]<br>

<dd>Sent: Tuesday, March 11, 2003 8:27 AM<br>

<dd>To: [e-mail]<br>

<dd>Subject: QC Declaration<br><br>
<br><br>

<dd>The EU directive introduced a requirement on each CA, issuing QC
(Qualified <br>

<dd>Certificates), to clearly indicate in these certificate that they are
<br>

<dd>issued as QC.<br><br>

<dd>ETSI implemented RFC 3039 in relation to the European electronic
signature <br>

<dd>directive through their Technical Standard (TS 101862)<br><br>

<dd>TS 101862 specified 2 alternative ways to declare a certificate as
QC.<br><br>

<dd>1) By inclusion of a QCStatements extension<br>

<dd>2) By including a certificate policy identifying this
property<br><br>

<dd>Even though solution number 1) is far easier to handle by
applications, <br>

<dd>since they don't need to recognize specific QC Policies, ETSI didn't
make <br>

<dd>solution 1) mandatory or even consider making it critical, due to
lack of <br>

<dd>confidence that clients would widely deploy this solution. ETSI
needed to <br>

<dd>define a solution that could work even if no one choose to implement
the <br>

<dd>new extensions provided by RFC 3039.<br><br>

<dd>However, It is not feasible to keep clients updated over time with
<br>

<dd>different QC policies and even those policies that are regarded 
<br>

<dd>standardized may be updated with change of OID as a result. It would
be <br>

<dd>devastating if we can't update a QCP because that would force an OID
update <br>

<dd>and that would render certificates useless because clients learned to
<br>

<dd>recognize only the old OID. This would be to build in a new root
<br>

<dd>certificate problem into the platforms.<br><br>

<dd>My observations is that times have changed. I have seen clear
indications <br>

<dd>that market players want, and even require for interoperability
reasons, <br>

<dd>that use QCStatements solution is made mandatory and maybe even
critical <br>

<dd>for QC.<br><br>

<dd>Since both RFC 3039, and TS 101862 are up for revision, it is time to
<br>

<dd>revisit this issue.<br><br>

<dd>I have some questions and proposals:<br><br>

<dd>- Is there any experiences of this issue outside of Europe. I.e. are
there <br>

<dd>other legal systems that make use of the same declaration logic as
the EU <br>

<dd>directive, where the RFC 3039 profile is used fully or partly as a
solution <br>

<dd>to this issue?<br><br>

<dd>- I would suggest that the QCStatement mechanism is ought to be a
mandatory <br>

<dd>tool to communicate a Qualified Status. The question is:<br>

<dd>&nbsp;&nbsp;&nbsp; 1) whether this will have enough implementation
support to succeed?<br>

<dd>&nbsp;&nbsp;&nbsp; 2) whether is best specified in RFC 3039 or in
local profiles (such as <br>

<dd>TS 101862)?<br>

<dd>&nbsp;&nbsp;&nbsp; 3) If there could be a clear context defined where
criticality could be <br>

<dd>allowed or even required?<br><br>

<dd>I would really like feedback from practical experiences from this
issue, as <br>

<dd>well as constructive proposals.<br><br>

<dd>/Stefan<br><br>
<br><br>
<br>

<dd>/Stefan<br><br>
<br><br>

<dd>_____________________________<br>

<dd>Stefan Santesson,&nbsp; Retrospekt AB<br>

<dd><a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a><br>

<dd>[phone] </blockquote><br>

<dd>_____________________________<br>

<dd>Stefan Santesson,&nbsp; Retrospekt AB<br>

<dd><a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a><br>

<dd>[phone] <br>
</blockquote>
<x-sigsep><p></x-sigsep>

</dl>_____________________________<br>
Stefan Santesson,&nbsp; Retrospekt AB<br>
<a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a><br>
[phone]</body>
</html>

--=====================_299841419==.ALT--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BKtUI07259 for ietf-pkix-bks; Tue, 11 Mar 2003 12:55:30 -0800 (PST)
Received: from cmailg4.svr.pol.co.uk (cmailg4.svr.pol.co.uk [195.92.195.174]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BKtS307252 for <[e-mail]>; Tue, 11 Mar 2003 12:55:28 -0800 (PST)
Received: from modem-2829.llama.dialup.pol.co.uk ([217.135.187.13] helo=PEDIGREE) by cmailg4.svr.pol.co.uk with smtp (Exim 3.35 #1) id 18sqmQ-00011Z-00 for [e-mail]; Tue, 11 Mar 2003 20:55:22 +0000
From: "Dean Adams" <[e-mail]>
To: <[e-mail]>
Subject: RE: QC Declaration
Date: Tue, 11 Mar 2003 20:55:08 -0000
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi David,
	Seems to me that your statement could be said to be the wrong way around?
"Standardise to establish wide adoption of qualified certifcates in
applications".  This seems like an effort to grow a market from a standards
led approach, something that OSI tried and failed.  I'm not at all sure that
QCs have not taken off because of the lack of standards in the area under
discussion here.  Probably much more (in Europe) to do with the legal and
financial liabilities that have to be taken on by QC providers, and by the
fact that as yet there are not the tools and standards that reflect what
happens in the real world with respect to signing (for example, proxy
signing of documents, emails, etc., e.g. by an assistant or other delegated
person).  We have a draft proxy certificate spec for identity
authentication, but not for the more useful (in my opinion)
email/doc/transaction signing.

Don't get me wrong.  I think the whole QC effort (including suggestions like
yours) are laudable, but I'm just not sure if the real blocking issues are
being tackled by standards.  This opens the way for a variety of competing
proprietary approaches and consequent market fragmentation.

As a technical community, we seem to love adding ever more stuff into our
certificates in the belief that this will unlock the market, or we create
more new standards that can or must be complied with, all without facing the
continuing differences between what is in the standards and what is
happening in real life, c.f. the recent discusions on Basic Constraints and
NR (again).

With respect to the particular extension being discussed here
(QCStatatement).  How far are you prepared to go to ensure that an
application can tell if it really is delaing with a QC?  If you will only
check for existence of the extension and whether it is critical, then that
is not enough.  I can issue a certificate with a QCStatatement that
specifies any conditions I want, thus rendering the apparent consistency
useless.  Will the standard also require applications to check for some
exact specification of wording (as is specified in Europe)?   Will
whitespace and/or case be significant?  Can additional statements be tacked
on? etc.

	I wish you luck in your endeavors.
	Dean
____________________________________________________________
Dean Adams               mobile:         [phone]
Trustis Limited          Direct Tel/Fax: [phone]
49 Whitehall             Office Tel:     [phone]
London SW1A 2BX          Office Fax:     [phone]
email: [e-mail]    Web: http://www.trustis.com
____________________________________________________________

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of David Cross
Sent: 11 March 2003 16:05
To: Stefan Santesson; [e-mail]
Subject: RE: QC Declaration



Stefan:

I agree with your proposal to make QCStatatement a mandatory extension
and also mark as critical.  I believe this is necessary requirement to
see wide adoption of qualified certifcates in applications.  Otherwise,
it is extremely difficult for generic applications to authoritatively
determine if a signature corresponds to a qualified certificate.


David B. Cross



-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]
Sent: Tuesday, March 11, 2003 5:27 AM
To: [e-mail]


The EU directive introduced a requirement on each CA, issuing QC
(Qualified Certificates), to clearly indicate in these certificate that
they are issued as QC.

ETSI implemented RFC 3039 in relation to the European electronic
signature directive through their Technical Standard (TS 101862)

TS 101862 specified 2 alternative ways to declare a certificate as QC.

1) By inclusion of a QCStatements extension
2) By including a certificate policy identifying this property

Even though solution number 1) is far easier to handle by applications,
since they don't need to recognize specific QC Policies, ETSI didn't
make solution 1) mandatory or even consider making it critical, due to
lack of confidence that clients would widely deploy this solution. ETSI
needed to define a solution that could work even if no one choose to
implement the new extensions provided by RFC 3039.

However, It is not feasible to keep clients updated over time with
different QC policies and even those policies that are regarded
standardized may be updated with change of OID as a result. It would be
devastating if we can't update a QCP because that would force an OID
update and that would render certificates useless because clients
learned to recognize only the old OID. This would be to build in a new
root certificate problem into the platforms.

My observations is that times have changed. I have seen clear
indications that market players want, and even require for
interoperability reasons, that use QCStatements solution is made
mandatory and maybe even critical for QC.

Since both RFC 3039, and TS 101862 are up for revision, it is time to
revisit this issue.

I have some questions and proposals:

- Is there any experiences of this issue outside of Europe. I.e. are
there other legal systems that make use of the same declaration logic as
the EU directive, where the RFC 3039 profile is used fully or partly as
a solution to this issue?

- I would suggest that the QCStatement mechanism is ought to be a
mandatory tool to communicate a Qualified Status. The question is:
    1) whether this will have enough implementation support to succeed?
    2) whether is best specified in RFC 3039 or in local profiles (such
as TS 101862)?
    3) If there could be a clear context defined where criticality could
be allowed or even required?

I would really like feedback from practical experiences from this issue,
as well as constructive proposals.

/Stefan




/Stefan



_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone]






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BKbsp06201 for ietf-pkix-bks; Tue, 11 Mar 2003 12:37:54 -0800 (PST)
Received: from vmmr7.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BKbr306197 for <[e-mail]>; Tue, 11 Mar 2003 12:37:53 -0800 (PST)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id OSR46541; Tue, 11 Mar 2003 15:37:54 -0500 (EST)
Received: from laptop-cpq.retrospekt.com (2Cust95.tnt8.stk3.swe.da.uu.net [213.116.241.95]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ABU81359; Tue, 11 Mar 2003 15:37:51 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 11 Mar 2003 21:37:11 +0100
To: Denis Pinkas <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]> <[e-mail]> <[e-mail]> <004401c2e72f$b4c03610$0500a8c0@arport>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 17:57 2003-03-11 +0100, Denis Pinkas wrote:
 >I do kown that in fact 676767666767 would allow to uniquely identify the 
individual, but this is not the semantics of that attribute.

Denis,

Where is the semantics broken?

Who says that a serial number need to start with 1 and be sequential with 
increment = 1

You have only to look at most software products, TV sets or similar to see 
another truth.
676767666767 is a perfectly fine serial number to me.

/Stefan




_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone] 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BJoI103027 for ietf-pkix-bks; Tue, 11 Mar 2003 11:50:18 -0800 (PST)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BJoG303018 for <[e-mail]>; Tue, 11 Mar 2003 11:50:16 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maild.telia.com (8.12.8/8.12.8) with SMTP id h2BJoH6o002329; Tue, 11 Mar 2003 20:50:17 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <00cc01c2e805$f15400d0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>, "Stefan Santesson" <[e-mail]>
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]> <[e-mail]> <[e-mail]> <004401c2e72f$b4c03610$0500a8c0@arport> <[e-mail]>
Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
Date: Tue, 11 Mar 2003 20:39:33 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

A crux with your suggestion is that it is correct but "looks" strange
and leads to confusion.   To use a nonsense disambiguer like "3"
("why do you call me John Doe the 3:rd?") when there already is a 
known and meaningful "676767666767" leads to the effective
duplication of this information in most real PI-cases.

This means that CAs have little motives for ever dropping their
RFC3039-variant of "PI".  And new CAs will likely also follow
RFC3039 due to the same issue.

Since most of these permanent-identifier-using CAs only support
a single name-space (given the non-utility of policy-extensions in
real-world software), the motives for adding the other part of
the PI-information also becomes limited.  Particularly as RPs
are equally singular in most cases.

And how are RPs supposed to know when they can drop support
for the RFC3039 way of doing things?

That's why I rather early, suggested that we together, should bring
out another scheme, where high-level PKI objects as constituted by
CA/EE, would be made conformant to the schemes used in most other
parts of the IT-industry, i.e. self-describing to some extent.  

Such a scheme would be a true companion to RFC3039 instead of a
"competitor" regarding "where to stuff identify information".

====================================================
    If the Internet had reached the same technical maturity level as PKI
    as represented by RFC3280, we would still not have had DNS,
    but rather be fully occupied tweaking "hosts" files.
====================================================

>Using such a large number is allowed but not strictly needed, since if there 
>are four people with the attributes DN: CN=John Doe, C=SE then using serial 
>numbers from 1 to 4 would be sufficient. I do kown that in fact 676767666767 
>would allow to uniquely identify the individual, but this is not the 
>semantics of that attribute.

This is though specified as an option in RFC3039 (although the text is
not that well written). 

Anders

----- Original Message ----- 
From: "Denis Pinkas" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Cc: <[e-mail]>; "Stefan Santesson" <[e-mail]>
Sent: Tuesday, March 11, 2003 17:57
Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda


Anders,

Since you asked, here is a short TECHNICAL reply.

> Stefan,
> 
>>The conclusion is that in your opinion there is no problem with
>>RFC 3039 with regard to this.
> 
>>Personally I have had a hard time see the problem with this.
>>This was sorted out many years ago and X.520 as even updated to
>>clarify that it was appropriate to accommodate this use, i.e. assigning
>>identifiers to humans. (X.520: "The Serial Number attribute
>>type specifies an identifier, the serial number of an object. ")
> 
> I know this but based on private mails the PI advocates still
> think this a bad use of serialNumber.   As you probably don't care
> about PI you have nothing to worry about.
> 
> In case you DO care about PI, please show me how YOU would
> apply PI to the following RFC3039 compliant "Swedish" certificate:
> 
> DN: CN=John Doe, serialNumber=676767666767, C=SE

serialNumber=676767666767 is used to make the difference between two 
entities that otherwise would have the same name, i.e. DN: CN=John Doe, C=SE.

Using such a large number is allowed but not strictly needed, since if there 
are four people with the attributes DN: CN=John Doe, C=SE then using serial 
numbers from 1 to 4 would be sufficient. I do kown that in fact 676767666767 
would allow to uniquely identify the individual, but this is not the 
semantics of that attribute.

However placing 676767666767 is the PI (with a Assigner Authority like 
"Swedish XXX" defined using an OID) does allow to uniquely identify the 
individual, irrespective of its DN.

So there is no contradiction.

Denis







> Anders
> 
> 






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BJo7d02997 for ietf-pkix-bks; Tue, 11 Mar 2003 11:50:07 -0800 (PST)
Received: from smtp23.kolumbus.fi (smtp23.kolumbus.fi [193.229.0.81]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BJo5302989; Tue, 11 Mar 2003 11:50:05 -0800 (PST)
Received: from dom1-cn1-hki.dom1.epnet (dom1-cn1-hki.dom1.epnet [172.21.176.70]) by smtp23.kolumbus.fi (8.12.8/8.12.4) with ESMTP id h2BJo09b016791; Tue, 11 Mar 2003 21:50:00 +0200 (EET)
Received: from dom1-mb1-hki.dom1.epnet ([172.21.176.65]) by dom1-cn1-hki.dom1.epnet with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 21:49:59 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Recommendation on subject matching rules needed..
Date: Tue, 11 Mar 2003 21:49:59 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Recommendation on subject matching rules needed..
Thread-Index: AcLn9wuEAL4OU7sYQx2FtTZ0MwCK1gABB7WA
From: "Vainikainen Saku EINT" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 11 Mar 2003 19:49:59.0705 (UTC) FILETIME=[66366090:01C2E807]
X-MailScanner: Found to be clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2BJo6402992
Sender: [e-mail]
Precedence: 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 why do you need to store all this cruft?  If it's a 
> legacy/superseded decryption key, all you need is the 
> private-key components for decryption (usually stored in a 
> highly compact card-specific format) and the 
> issuerAndSerialNumberHash so you can locate it (in fact for 
> any decryption key, even a currently active one, you don't 
> actually need to store the cert). The overhead for the non- 
> private-key components would probably be 50-100 bytes, 
> depending on how much other stuff your PKCS #15 
> implementation stores alongside it.  So your card contains 
> the current decryption key and its cert, and one (or possibly 
> more, although you probably need to ask why the user is 
> losing that many keys) decryption keys and the index info 
> needed to find them. The indexing overhead for half a dozen 
> decryption keys is going to be less than that for a single 
> certificate.

Sounds good, but I suppose we still need to select the keys somehow
(using the certs) through the CryptoAPI CSP and RSA CrypTokI interface,
so that the applications are satisfied.

I assume PKCS#11 is not that a big problem in terms of key
types/parameters since it recognises keys with key usage bits and relays
key parameters from the PKCS#15 structure, but if I don't remember
incorrectly, MSoft CSP is a problem since it only recognises two types
of keys (AT_KEYEXCHANGE and AT_SIGNATURE) and thus it has no clue about
the key usage bits. And both interfaces can do the mapping between
public keys and corresponding private keys.

But I don't recall if there is an attribute that could store
issuerAndSerialNumber in either PKCS#11 or CSP specifications. So could
we really relay this info to apps ?

This implies more or less that the applications have to locate the
decryption key (private key) based on certificate comparison (or public
key comparison) to locate the related public key. And when using
certificates, comparing issuerAndSerialNumber is not good enough since
it only recognises the certificate, not the entity nor the key pair
described in the cert.

If we compare the subject and issuer data (key ids, subject and issuer
names, subject and issuer unique ids), we recognise the entity
identified by the certificate, not the certificate itself - and in my
opinion, this is what we are after when we are using certificates. Eg.
in S/MIME, we figure out if the encrypted mail is really intended to the
entity trying to open it rather than figuring out if the certificate
linked to the recipient's private key he/she is trying to use in
decrypting the mail, is the same certificate that was used to encrypt
the mail.

Saku.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BJ1KQ29109 for ietf-pkix-bks; Tue, 11 Mar 2003 11:01:20 -0800 (PST)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BJ1J329105 for <[e-mail]>; Tue, 11 Mar 2003 11:01:19 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maild.telia.com (8.12.8/8.12.8) with SMTP id h2BJ1F6o003961; Tue, 11 Mar 2003 20:01:15 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <00b401c2e7ff$183fb420$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Steve Hanna" <[e-mail]>, "Santosh Chokhani" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <007f01c2e75f$4b93ec10$2d00a8c0@Chokhani> <[e-mail]>
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)
Date: Tue, 11 Mar 2003 19:50:32 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve,

We apparently do not agree on the value of policy extensions
in certificates.  I have some additional comment and questions.

>If we refuse to work on anything that's not already
>widely deployed, we'll have to stop all innovation.

Even if the method described in my previous message already is
deployed, pretty universal, and works with all existing software?

X.509 Attribute certificates have also been touted as an
important addition to PKI technology.  I don't think even the
authors believe that anymore.  At least not in private.  

>Instead, we must continue to address real problems with
>real solutions. If customers see value in these solutions,
>they will be implemented by vendors.

But how are they going to rollout this particular stuff?
StarOffice will add such settings?  It seems to me to be
yet an additional way to fail with PKI.

>Certificate policies have definite utility. Several communities 
>are piloting their use, such as the U.S. Government. 

See question above.

Although government PKIs like to position themselves as being
in the forefront technically, I believe they are only in the forefront
in terms of complexity and costs.  If they had considered using high-
level PKI models, they would never have had to use bridge CAs either.  

<snip>

Anders





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BHqsA25683 for ietf-pkix-bks; Tue, 11 Mar 2003 09:52:54 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BHqq325678; Tue, 11 Mar 2003 09:52:52 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.8/8.12.8) with ESMTP id h2BHqeZF006657; Wed, 12 Mar 2003 06:52:40 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h2BHqeY06408; Wed, 12 Mar 2003 06:52:40 +1300
Date: Wed, 12 Mar 2003 06:52:40 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Recommendation on subject matching rules needed..
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Vainikainen Saku EINT" <[e-mail]> writes:

>Yes, but then we need to store encryption key and certificate chains. Our
>smartcard has only limited space available, so we would need to recover the
>old encryption keys and certificates to PKCS#12 files or other software
>tokens. 

But why do you need to store all this cruft?  If it's a legacy/superseded
decryption key, all you need is the private-key components for decryption
(usually stored in a highly compact card-specific format) and the
issuerAndSerialNumberHash so you can locate it (in fact for any decryption
key, even a currently active one, you don't actually need to store the cert).
The overhead for the non- private-key components would probably be 50-100
bytes, depending on how much other stuff your PKCS #15 implementation stores
alongside it.  So your card contains the current decryption key and its cert,
and one (or possibly more, although you probably need to ask why the user is
losing that many keys) decryption keys and the index info needed to find them.
The indexing overhead for half a dozen decryption keys is going to be less
than that for a single certificate.

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BHqPW25672 for ietf-pkix-bks; Tue, 11 Mar 2003 09:52:25 -0800 (PST)
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BHqO325668 for <[e-mail]>; Tue, 11 Mar 2003 09:52:24 -0800 (PST)
Received: from SOTTMXS01.entrust.com (sottmxs01.entrust.com [10.4.61.7]) by sottmxssm.entrust.com (Switch-2.2.5/Switch-2.2.4) with ESMTP id V2BH3D3909550; Tue, 11 Mar 2003 12:49:39 -0500
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <GXR5NB4M>; Tue, 11 Mar 2003 12:52:17 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], Sharon Boeyen <[e-mail]>, [e-mail]
Subject: RE: QC Declaration
Date: Tue, 11 Mar 2003 12:52:16 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
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>

Actually its a of both isn't it :-)

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Tuesday, March 11, 2003 12:45 PM
To: [e-mail]; [e-mail]; [e-mail]
Subject: RE: QC Declaration


Sharon Boeyen <[e-mail]> writes:

>Remember first that RFC 3280 is a "profile" of X.509 and it does not
replace
>the requirements of 509, but rather profiles them to a subset.
                                                        ^^^^^^
You misspelled "superset".

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BHihg25252 for ietf-pkix-bks; Tue, 11 Mar 2003 09:44:43 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BHif325245 for <[e-mail]>; Tue, 11 Mar 2003 09:44:41 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.8/8.12.8) with ESMTP id h2BHiYZF006536; Wed, 12 Mar 2003 06:44:34 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h2BHiXK06392; Wed, 12 Mar 2003 06:44:33 +1300
Date: Wed, 12 Mar 2003 06:44:33 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: QC Declaration
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Sharon Boeyen <[e-mail]> writes:

>Remember first that RFC 3280 is a "profile" of X.509 and it does not replace
>the requirements of 509, but rather profiles them to a subset.
                                                        ^^^^^^
You misspelled "superset".

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BGwSJ20444 for ietf-pkix-bks; Tue, 11 Mar 2003 08:58:28 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BGwR320438 for <[e-mail]>; Tue, 11 Mar 2003 08:58:27 -0800 (PST)
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA46668; Tue, 11 Mar 2003 17:59:45 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id QAA26373; Tue, 11 Mar 2003 16:53:22 +0100
Message-ID: <[e-mail]>
Date: Tue, 11 Mar 2003 17:57:07 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail], Stefan Santesson <[e-mail]>
Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]> <[e-mail]> <[e-mail]> <004401c2e72f$b4c03610$0500a8c0@arport>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

Since you asked, here is a short TECHNICAL reply.

> Stefan,
> 
>>The conclusion is that in your opinion there is no problem with
>>RFC 3039 with regard to this.
> 
>>Personally I have had a hard time see the problem with this.
>>This was sorted out many years ago and X.520 as even updated to
>>clarify that it was appropriate to accommodate this use, i.e. assigning
>>identifiers to humans. (X.520: "The Serial Number attribute
>>type specifies an identifier, the serial number of an object. ")
> 
> I know this but based on private mails the PI advocates still
> think this a bad use of serialNumber.   As you probably don't care
> about PI you have nothing to worry about.
> 
> In case you DO care about PI, please show me how YOU would
> apply PI to the following RFC3039 compliant "Swedish" certificate:
> 
> DN: CN=John Doe, serialNumber=676767666767, C=SE

serialNumber=676767666767 is used to make the difference between two 
entities that otherwise would have the same name, i.e. DN: CN=John Doe, C=SE.

Using such a large number is allowed but not strictly needed, since if there 
are four people with the attributes DN: CN=John Doe, C=SE then using serial 
numbers from 1 to 4 would be sufficient. I do kown that in fact 676767666767 
would allow to uniquely identify the individual, but this is not the 
semantics of that attribute.

However placing 676767666767 is the PI (with a Assigner Authority like 
"Swedish XXX" defined using an OID) does allow to uniquely identify the 
individual, irrespective of its DN.

So there is no contradiction.

Denis







> Anders
> 
> 




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BGfKD17943 for ietf-pkix-bks; Tue, 11 Mar 2003 08:41:20 -0800 (PST)
Received: from smtp22.kolumbus.fi (smtp22.kolumbus.fi [193.229.0.82]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BGfD317938; Tue, 11 Mar 2003 08:41:13 -0800 (PST)
Received: from dom1-cn1-hki.dom1.epnet (dom1-cn1-hki.dom1.epnet [172.21.176.70]) by smtp22.kolumbus.fi (8.12.8/8.12.4) with ESMTP id h2BGf6I3027541; Tue, 11 Mar 2003 18:41:06 +0200 (EET)
Received: from dom1-mb1-hki.dom1.epnet ([172.21.176.65]) by dom1-cn1-hki.dom1.epnet with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 18:41:04 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Recommendation on subject matching rules needed..
Date: Tue, 11 Mar 2003 18:41:03 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Recommendation on subject matching rules needed..
Thread-Index: AcLn5/tgp/18ImZSRGi4oKijztq7gQAAJNeA
From: "Vainikainen Saku EINT" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 11 Mar 2003 16:41:04.0321 (UTC) FILETIME=[01CC0B10:01C2E7ED]
X-MailScanner: Found to be clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2BGfJ417940
Sender: [e-mail]
Precedence: 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 how we do it. And this is why the decryption does not work 
> >since the new enc cert gets a new serial number, ie. the encryption 
> >cert gets reissued, ie. the encryption key pair gets 
> recertified, ie. 
> >cert hash changes. One cannot change the contents of a certificate 
> >without generating a new certificate serial number, ie. issue a new 
> >certificate.
> 
> But why is this a problem?  If you get something addressed to 
> the old cert, you use the old key to decrypt.  If it's for 
> the new cert, you use the new key.  In fact there isn't even 
> any need to keep the old cert around if it's decrypt-only, 
> you mention PKCS #15, well that stores all the index info you 
> need with the key, so you don't need the cert at all.

Yes, but then we need to store encryption key and certificate chains.
Our smartcard has only limited space available, so we would need to
recover the old encryption keys and certificates to PKCS#12 files or
other software tokens. Then again the software tokens tend to be a bit
difficult since you have to store them somewhere (disk/cd-rom/whatever,
preferrably a read-only media) to deliver them to the user.

Then in order to use the keys, the user has to import them to his/her
user profile or disk to have them available. And since roaming profiles
are not so common (at least in our environment) copies of the keys
(along with automatic password managers memorizing the passphrases) lay
around in multiple workstations, which is not good in sense of privacy.

Unfortunately most of the software we are using uses Microsoft
CryptoAPI, which hides all PKCS#15 info quite efficiently, thus forcing
the software to use the key usage info stored in the certs.
 
> >Our card has following PKCS#15 key usages on the private keys:
> 
> Have you actually tested all the combinations with your 
> software?  That is, added two certs that differ only in 
> encryption vs.signature usage and then see what the app does 
> if asked for a signature or encryption cert?  Some of the 
> people I pointed out problems to were surprised at the 
> problems, since things seemed to work OK (meaning that the 
> app just grabbed the first key it found and used that, so 
> everything appeared to work fine).

No - since we issue only one cert per key at a time, and we don't issue
multiple certificates with identical serial numbers. And the apps we are
using allow us to choose the certificate (=key) to be used, although
they do some filtering based on key usage information found in the
certificates.

Saku.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BGbHb17669 for ietf-pkix-bks; Tue, 11 Mar 2003 08:37:17 -0800 (PST)
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BGbF317663 for <[e-mail]>; Tue, 11 Mar 2003 08:37:15 -0800 (PST)
Received: from SOTTMXS01.entrust.com (sottmxs01.entrust.com [10.4.61.7]) by sottmxssm.entrust.com (Switch-2.2.5/Switch-2.2.4) with ESMTP id V2BG0YQ901108; Tue, 11 Mar 2003 11:34:26 -0500
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <GXR5M05C>; Tue, 11 Mar 2003 11:37:03 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, Sharon Boeyen <[e-mail]>, [e-mail]
Subject: RE: QC Declaration
Date: Tue, 11 Mar 2003 11:37:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E7EC.7204CAD0"
Sender: [e-mail]
Precedence: 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_01C2E7EC.7204CAD0
Content-Type: text/plain

Hi Stefan,
 
Remember first that RFC 3280 is a "profile" of X.509 and it does not replace
the requirements of 509, but rather profiles them to a subset. 
 
X.509 in clause 7 allows unknown elements in non-critical extensions only to
be ignored. However, that is more with respect to the elements in the syntax

itself (for example in the IDP extension no RP is allowed to ignore the
"onlySomeReasons" element if it is present in the extension because the
extension 
can only be critical. The behaviour of RPs will differ however depending on
their specific capability with respect to that element (some will use the
CRL for 
the specified reasons and others will seek a different CRL that covers all
reasons), however, no RP is permitted to simply ignore the flag. Note also
that in that
same clause, for extensions that can be marked critical or non-critical, a
system that understands the extension is required to process it regardless
of the 
value of the criticality flag. It is ONLY systems that do not understand an
extension that can ignore it completely if it is marked non-critical. 
 
For the QC Statements extension, RFC 3039 says "This extension may be
critical or non-critical.  If the extension is critical, this means that all
statements 
included in the extension are regarded as critical. " 
 
Because of the semantics defined for the extension in RFC 3039, marking it
critical would result in the problems I raised. 


-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]
Sent: Tuesday, March 11, 2003 11:23 AM
To: Sharon Boeyen; [e-mail]
Subject: RE: QC Declaration


Hi Sharon,

My interpretation of criticality does not really match yours.

The only guidance on the meaning of criticality in RFC 3280 (section 4.2)
that I can find is:


  "A certificate using system MUST reject the certificate

if it encounters a critical extension it does not recognize"


My interpretation is that it is OK to accept a certificate if you recognize
the extension as such. You don't need to understand ALL information that the
extension contains.

It seam vital to agree on this issue before we can make any conclusion on
QCStatament criticality.

/Stefan


At 10:56 2003-03-11 -0500, Sharon Boeyen wrote:


Hi Stefan,

While I believe that in the longer term certificate policies will be the
optimum 
way to convey the necessary information, I acknowledge that QC Statements is
the 
more popular scheme at present. Therefore I wouldn't have any problem should
this 
extension be mandated in RFC 3039. 

However, forcing its criticality is going too far I believe. There is an
important 
difference between critical and non-critical extensions that we need to keep
in 
mind from the relying party's perspective. If there is a non-critical
extension that 
the RP understands, but that extension includes some elements that it does
not, then 
the RP is free to process the parts it does understand and ignore others. If
an extension 
is critical however, the RP is required to understand ALL elements within
the extension.

Where I think this can become a problem is the content of the QC Statements
extension. Note 
that RFC 3039 and the ETSI profile define DIFFERENT statements for inclusion
in the extension. 
Also additional profiles may add their own local statements and even
narrower statements can 
get added in specific deployment environments. While the cert issuer may
want to include many 
of these statements to enable the cert to be used in various environments,
the RP should only 
be required to understand and process the statements that are appropriate to
its own 
operating environment as dictated by its local security policy (which could
be different than 
that under which the CA operated). Therefore I think requiring it to be
critical is risky. 
Also requiring that it always be critical would have interop/backward
compatibility issues.

Cheers,
Sharon

 


-----Original Message-----
From: Stefan Santesson [ mailto:[e-mail]
<mailto:[e-mail]> ]
Sent: Tuesday, March 11, 2003 8:27 AM
To: [e-mail]
Subject: QC Declaration



The EU directive introduced a requirement on each CA, issuing QC (Qualified 
Certificates), to clearly indicate in these certificate that they are 
issued as QC.

ETSI implemented RFC 3039 in relation to the European electronic signature 
directive through their Technical Standard (TS 101862)

TS 101862 specified 2 alternative ways to declare a certificate as QC.

1) By inclusion of a QCStatements extension
2) By including a certificate policy identifying this property

Even though solution number 1) is far easier to handle by applications, 
since they don't need to recognize specific QC Policies, ETSI didn't make 
solution 1) mandatory or even consider making it critical, due to lack of 
confidence that clients would widely deploy this solution. ETSI needed to 
define a solution that could work even if no one choose to implement the 
new extensions provided by RFC 3039.

However, It is not feasible to keep clients updated over time with 
different QC policies and even those policies that are regarded 
standardized may be updated with change of OID as a result. It would be 
devastating if we can't update a QCP because that would force an OID update 
and that would render certificates useless because clients learned to 
recognize only the old OID. This would be to build in a new root 
certificate problem into the platforms.

My observations is that times have changed. I have seen clear indications 
that market players want, and even require for interoperability reasons, 
that use QCStatements solution is made mandatory and maybe even critical 
for QC.

Since both RFC 3039, and TS 101862 are up for revision, it is time to 
revisit this issue.

I have some questions and proposals:

- Is there any experiences of this issue outside of Europe. I.e. are there 
other legal systems that make use of the same declaration logic as the EU 
directive, where the RFC 3039 profile is used fully or partly as a solution 
to this issue?

- I would suggest that the QCStatement mechanism is ought to be a mandatory 
tool to communicate a Qualified Status. The question is:
    1) whether this will have enough implementation support to succeed?
    2) whether is best specified in RFC 3039 or in local profiles (such as 
TS 101862)?
    3) If there could be a clear context defined where criticality could be 
allowed or even required?

I would really like feedback from practical experiences from this issue, as 
well as constructive proposals.

/Stefan




/Stefan



_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com <http://www.retrospekt.com/> 
[phone] 

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com <http://www.retrospekt.com/> 
[phone] 


------_=_NextPart_001_01C2E7EC.7204CAD0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">


<META content="MSHTML 5.50.4922.900" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=596162916-11032003><FONT face=Arial color=#0000ff size=2>Hi 
Stefan,</FONT></SPAN></DIV>
<DIV><SPAN class=596162916-11032003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=596162916-11032003><FONT face=Arial color=#0000ff 
size=2>Remember first that RFC 3280 is a "profile" of X.509 and it does not 
replace the requirements of 509, but rather profiles them to a subset. 
</FONT></SPAN></DIV>
<DIV><SPAN class=596162916-11032003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=596162916-11032003><FONT face=Arial color=#0000ff size=2>X.509 
in clause 7 allows unknown elements in non-critical extensions only to be 
ignored. However, that is more with respect to the elements in the syntax 
</FONT></SPAN></DIV>
<DIV><SPAN class=596162916-11032003><FONT face=Arial color=#0000ff size=2>itself 
(for example in the IDP extension no RP is allowed to ignore the 
"onlySomeReasons" element if it is present in the extension because the 
extension </FONT></SPAN></DIV>
<DIV><SPAN class=596162916-11032003><FONT face=Arial color=#0000ff size=2>can 
only be critical. The behaviour of RPs will differ however depending on their 
specific capability with respect to that element (some will use the CRL for 
</FONT></SPAN></DIV>
<DIV><SPAN class=596162916-11032003><FONT face=Arial color=#0000ff size=2>the 
specified reasons and others will seek a different CRL that covers all reasons), 
however, no RP is permitted to simply ignore the flag. Note also that in 
that</FONT></SPAN></DIV>
<DIV><SPAN class=596162916-11032003><FONT face=Arial color=#0000ff size=2>same 
clause, for extensions that can be marked critical or non-critical, a system 
that understands the extension is required to process it regardless of the 
</FONT></SPAN></DIV>
<DIV><SPAN class=596162916-11032003><FONT face=Arial color=#0000ff size=2>value 
of the criticality flag. It is ONLY systems that do not understand an extension 
that can ignore it completely if it is marked non-critical. </FONT></SPAN></DIV>
<DIV><SPAN class=596162916-11032003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=596162916-11032003><FONT face=Arial><FONT color=#0000ff 
size=2>For the QC Statements extension, RFC 3039 says "</FONT><FONT 
face="Times New Roman" size=2><FONT color=#0000ff><FONT face=Arial>This 
extension may be critical or non-critical.&nbsp; If the extension is critical, 
this means that all statements </FONT></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=596162916-11032003><FONT face=Arial><FONT 
face="Times New Roman" size=2><FONT color=#0000ff><FONT face=Arial>included in 
the extension are regarded as critical.</FONT> <FONT face=Arial>" 
</FONT></FONT></FONT></FONT></SPAN></DIV>
<DIV><SPAN class=596162916-11032003><FONT face=Arial><FONT 
face="Times New Roman" size=2><FONT color=#0000ff><FONT 
face=Arial></FONT></FONT></FONT></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=596162916-11032003><FONT face=Arial><FONT 
face="Times New Roman" size=2><FONT color=#0000ff><FONT face=Arial>Because of 
the semantics defined for the extension in RFC 3039, marking it critical would 
result in the problems I raised. </FONT></DIV>
<DIV><BR></DIV></FONT></FONT></FONT></SPAN>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Stefan Santesson 
  [mailto:[e-mail]]<BR><B>Sent:</B> Tuesday, March 11, 2003 11:23 
  AM<BR><B>To:</B> Sharon Boeyen; [e-mail]<BR><B>Subject:</B> RE: QC 
  Declaration<BR><BR></FONT></DIV>Hi Sharon,<BR><BR>My interpretation of 
  criticality does not really match yours.<BR><BR>The only guidance on the 
  meaning of criticality in RFC 3280 (section 4.2) that I can find is:<BR><BR><PRE>&nbsp; "A certificate using system MUST reject the certificate
if it encounters a critical extension it does not recognize"

</PRE>My interpretation is that it is OK to accept a certificate if you 
  recognize the extension as such. You don't need to understand ALL information 
  that the extension contains.<BR><BR>It seam vital to agree on this issue 
  before we can make any conclusion on QCStatament 
  criticality.<BR><BR>/Stefan<BR><BR><BR>At 10:56 2003-03-11 -0500, Sharon 
  Boeyen wrote:<BR>
  <BLOCKQUOTE class=cite cite type="cite">Hi Stefan,<BR><BR>While I believe 
    that in the longer term certificate policies will be the<BR>optimum <BR>way 
    to convey the necessary information, I acknowledge that QC Statements 
    is<BR>the <BR>more popular scheme at present. Therefore I wouldn't have any 
    problem should<BR>this <BR>extension be mandated in RFC 3039. 
    <BR><BR>However, forcing its criticality is going too far I believe. There 
    is an<BR>important <BR>difference between critical and non-critical 
    extensions that we need to keep<BR>in <BR>mind from the relying party's 
    perspective. If there is a non-critical<BR>extension that <BR>the RP 
    understands, but that extension includes some elements that it does<BR>not, 
    then <BR>the RP is free to process the parts it does understand and ignore 
    others. If<BR>an extension <BR>is critical however, the RP is required to 
    understand ALL elements within<BR>the extension.<BR><BR>Where I think this 
    can become a problem is the content of the QC Statements<BR>extension. Note 
    <BR>that RFC 3039 and the ETSI profile define DIFFERENT statements for 
    inclusion<BR>in the extension. <BR>Also additional profiles may add their 
    own local statements and even<BR>narrower statements can <BR>get added in 
    specific deployment environments. While the cert issuer may<BR>want to 
    include many <BR>of these statements to enable the cert to be used in 
    various environments,<BR>the RP should only <BR>be required to understand 
    and process the statements that are appropriate to<BR>its own <BR>operating 
    environment as dictated by its local security policy (which could<BR>be 
    different than <BR>that under which the CA operated). Therefore I think 
    requiring it to be<BR>critical is risky. <BR>Also requiring that it always 
    be critical would have interop/backward<BR>compatibility 
    issues.<BR><BR>Cheers,<BR>Sharon<BR><BR>&nbsp;<BR><BR><BR>-----Original 
    Message-----<BR>From: Stefan Santesson [<A 
    href="mailto:[e-mail]" 
    eudora="autourl">mailto:[e-mail]</A>]<BR>Sent: Tuesday, March 
    11, 2003 8:27 AM<BR>To: [e-mail]<BR>Subject: QC 
    Declaration<BR><BR><BR><BR>The EU directive introduced a requirement on each 
    CA, issuing QC (Qualified <BR>Certificates), to clearly indicate in these 
    certificate that they are <BR>issued as QC.<BR><BR>ETSI implemented RFC 3039 
    in relation to the European electronic signature <BR>directive through their 
    Technical Standard (TS 101862)<BR><BR>TS 101862 specified 2 alternative ways 
    to declare a certificate as QC.<BR><BR>1) By inclusion of a QCStatements 
    extension<BR>2) By including a certificate policy identifying this 
    property<BR><BR>Even though solution number 1) is far easier to handle by 
    applications, <BR>since they don't need to recognize specific QC Policies, 
    ETSI didn't make <BR>solution 1) mandatory or even consider making it 
    critical, due to lack of <BR>confidence that clients would widely deploy 
    this solution. ETSI needed to <BR>define a solution that could work even if 
    no one choose to implement the <BR>new extensions provided by RFC 
    3039.<BR><BR>However, It is not feasible to keep clients updated over time 
    with <BR>different QC policies and even those policies that are regarded 
    <BR>standardized may be updated with change of OID as a result. It would be 
    <BR>devastating if we can't update a QCP because that would force an OID 
    update <BR>and that would render certificates useless because clients 
    learned to <BR>recognize only the old OID. This would be to build in a new 
    root <BR>certificate problem into the platforms.<BR><BR>My observations is 
    that times have changed. I have seen clear indications <BR>that market 
    players want, and even require for interoperability reasons, <BR>that use 
    QCStatements solution is made mandatory and maybe even critical <BR>for 
    QC.<BR><BR>Since both RFC 3039, and TS 101862 are up for revision, it is 
    time to <BR>revisit this issue.<BR><BR>I have some questions and 
    proposals:<BR><BR>- Is there any experiences of this issue outside of 
    Europe. I.e. are there <BR>other legal systems that make use of the same 
    declaration logic as the EU <BR>directive, where the RFC 3039 profile is 
    used fully or partly as a solution <BR>to this issue?<BR><BR>- I would 
    suggest that the QCStatement mechanism is ought to be a mandatory <BR>tool 
    to communicate a Qualified Status. The question is:<BR>&nbsp;&nbsp;&nbsp; 1) 
    whether this will have enough implementation support to 
    succeed?<BR>&nbsp;&nbsp;&nbsp; 2) whether is best specified in RFC 3039 or 
    in local profiles (such as <BR>TS 101862)?<BR>&nbsp;&nbsp;&nbsp; 3) If there 
    could be a clear context defined where criticality could be <BR>allowed or 
    even required?<BR><BR>I would really like feedback from practical 
    experiences from this issue, as <BR>well as constructive 
    proposals.<BR><BR>/Stefan<BR><BR><BR><BR><BR>/Stefan<BR><BR><BR><BR>_____________________________<BR>Stefan 
    Santesson,&nbsp; Retrospekt AB<BR><A href="http://www.retrospekt.com/" 
    eudora="autourl">http://www.retrospekt.com</A><BR>[phone] 
  </BLOCKQUOTE><X-SIGSEP>
  <P></X-SIGSEP>_____________________________<BR>Stefan Santesson,&nbsp; 
  Retrospekt AB<BR><A href="http://www.retrospekt.com/" 
  eudora="autourl">http://www.retrospekt.com</A><BR>[phone] 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C2E7EC.7204CAD0--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BGNUg16951 for ietf-pkix-bks; Tue, 11 Mar 2003 08:23:30 -0800 (PST)
Received: from vmmr9.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BGNS316947 for <[e-mail]>; Tue, 11 Mar 2003 08:23:29 -0800 (PST)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr9.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id PCF04425; Tue, 11 Mar 2003 11:23:29 -0500 (EST)
Received: from laptop-cpq.retrospekt.com (1Cust120.tnt15.stk3.swe.da.uu.net [213.116.222.120]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ABU33653; Tue, 11 Mar 2003 11:23:25 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 11 Mar 2003 17:22:46 +0100
To: Sharon Boeyen <[e-mail]>, [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: RE: QC Declaration
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_282876194==.ALT"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Hi Sharon,

My interpretation of criticality does not really match yours.

The only guidance on the meaning of criticality in RFC 3280 (section 4.2) 
that I can find is:

   "A certificate using system MUST reject the certificate if it encounters 
a critical extension it does not recognize"

My interpretation is that it is OK to accept a certificate if you recognize 
the extension as such. You don't need to understand ALL information that 
the extension contains.

It seam vital to agree on this issue before we can make any conclusion on 
QCStatament criticality.

/Stefan


At 10:56 2003-03-11 -0500, Sharon Boeyen wrote:
>Hi Stefan,
>
>While I believe that in the longer term certificate policies will be the
>optimum
>way to convey the necessary information, I acknowledge that QC Statements is
>the
>more popular scheme at present. Therefore I wouldn't have any problem should
>this
>extension be mandated in RFC 3039.
>
>However, forcing its criticality is going too far I believe. There is an
>important
>difference between critical and non-critical extensions that we need to keep
>in
>mind from the relying party's perspective. If there is a non-critical
>extension that
>the RP understands, but that extension includes some elements that it does
>not, then
>the RP is free to process the parts it does understand and ignore others. If
>an extension
>is critical however, the RP is required to understand ALL elements within
>the extension.
>
>Where I think this can become a problem is the content of the QC Statements
>extension. Note
>that RFC 3039 and the ETSI profile define DIFFERENT statements for inclusion
>in the extension.
>Also additional profiles may add their own local statements and even
>narrower statements can
>get added in specific deployment environments. While the cert issuer may
>want to include many
>of these statements to enable the cert to be used in various environments,
>the RP should only
>be required to understand and process the statements that are appropriate to
>its own
>operating environment as dictated by its local security policy (which could
>be different than
>that under which the CA operated). Therefore I think requiring it to be
>critical is risky.
>Also requiring that it always be critical would have interop/backward
>compatibility issues.
>
>Cheers,
>Sharon
>
>
>
>
>-----Original Message-----
>From: Stefan Santesson [mailto:[e-mail]]
>Sent: Tuesday, March 11, 2003 8:27 AM
>To: [e-mail]
>Subject: QC Declaration
>
>
>
>The EU directive introduced a requirement on each CA, issuing QC (Qualified
>Certificates), to clearly indicate in these certificate that they are
>issued as QC.
>
>ETSI implemented RFC 3039 in relation to the European electronic signature
>directive through their Technical Standard (TS 101862)
>
>TS 101862 specified 2 alternative ways to declare a certificate as QC.
>
>1) By inclusion of a QCStatements extension
>2) By including a certificate policy identifying this property
>
>Even though solution number 1) is far easier to handle by applications,
>since they don't need to recognize specific QC Policies, ETSI didn't make
>solution 1) mandatory or even consider making it critical, due to lack of
>confidence that clients would widely deploy this solution. ETSI needed to
>define a solution that could work even if no one choose to implement the
>new extensions provided by RFC 3039.
>
>However, It is not feasible to keep clients updated over time with
>different QC policies and even those policies that are regarded
>standardized may be updated with change of OID as a result. It would be
>devastating if we can't update a QCP because that would force an OID update
>and that would render certificates useless because clients learned to
>recognize only the old OID. This would be to build in a new root
>certificate problem into the platforms.
>
>My observations is that times have changed. I have seen clear indications
>that market players want, and even require for interoperability reasons,
>that use QCStatements solution is made mandatory and maybe even critical
>for QC.
>
>Since both RFC 3039, and TS 101862 are up for revision, it is time to
>revisit this issue.
>
>I have some questions and proposals:
>
>- Is there any experiences of this issue outside of Europe. I.e. are there
>other legal systems that make use of the same declaration logic as the EU
>directive, where the RFC 3039 profile is used fully or partly as a solution
>to this issue?
>
>- I would suggest that the QCStatement mechanism is ought to be a mandatory
>tool to communicate a Qualified Status. The question is:
>     1) whether this will have enough implementation support to succeed?
>     2) whether is best specified in RFC 3039 or in local profiles (such as
>TS 101862)?
>     3) If there could be a clear context defined where criticality could be
>allowed or even required?
>
>I would really like feedback from practical experiences from this issue, as
>well as constructive proposals.
>
>/Stefan
>
>
>
>
>/Stefan
>
>
>
>_____________________________
>Stefan Santesson,  Retrospekt AB
>http://www.retrospekt.com
>[phone]

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone] 
--=====================_282876194==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Hi Sharon,<br><br>
My interpretation of criticality does not really match yours.<br><br>
The only guidance on the meaning of criticality in RFC 3280 (section 4.2)
that I can find is:<br><br>
<pre>&nbsp; &quot;A certificate using system MUST reject the certificate
if it encounters a critical extension it does not recognize&quot;

</pre>My interpretation is that it is OK to accept a certificate if you
recognize the extension as such. You don't need to understand ALL
information that the extension contains.<br><br>
It seam vital to agree on this issue before we can make any conclusion on
QCStatament criticality.<br><br>
/Stefan<br><br>
<br>
At 10:56 2003-03-11 -0500, Sharon Boeyen wrote:<br>
<blockquote type=cite class=cite cite>Hi Stefan,<br><br>
While I believe that in the longer term certificate policies will be
the<br>
optimum <br>
way to convey the necessary information, I acknowledge that QC Statements
is<br>
the <br>
more popular scheme at present. Therefore I wouldn't have any problem
should<br>
this <br>
extension be mandated in RFC 3039. <br><br>
However, forcing its criticality is going too far I believe. There is
an<br>
important <br>
difference between critical and non-critical extensions that we need to
keep<br>
in <br>
mind from the relying party's perspective. If there is a
non-critical<br>
extension that <br>
the RP understands, but that extension includes some elements that it
does<br>
not, then <br>
the RP is free to process the parts it does understand and ignore others.
If<br>
an extension <br>
is critical however, the RP is required to understand ALL elements
within<br>
the extension.<br><br>
Where I think this can become a problem is the content of the QC
Statements<br>
extension. Note <br>
that RFC 3039 and the ETSI profile define DIFFERENT statements for
inclusion<br>
in the extension. <br>
Also additional profiles may add their own local statements and 
even<br>
narrower statements can <br>
get added in specific deployment environments. While the cert issuer
may<br>
want to include many <br>
of these statements to enable the cert to be used in various
environments,<br>
the RP should only <br>
be required to understand and process the statements that are appropriate
to<br>
its own <br>
operating environment as dictated by its local security policy (which
could<br>
be different than <br>
that under which the CA operated). Therefore I think requiring it to
be<br>
critical is risky. <br>
Also requiring that it always be critical would have
interop/backward<br>
compatibility issues.<br><br>
Cheers,<br>
Sharon<br><br>
&nbsp;<br><br>
<br>
-----Original Message-----<br>
From: Stefan Santesson
[<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>]<br>
Sent: Tuesday, March 11, 2003 8:27 AM<br>
To: [e-mail]<br>
Subject: QC Declaration<br><br>
<br><br>
The EU directive introduced a requirement on each CA, issuing QC
(Qualified <br>
Certificates), to clearly indicate in these certificate that they are
<br>
issued as QC.<br><br>
ETSI implemented RFC 3039 in relation to the European electronic
signature <br>
directive through their Technical Standard (TS 101862)<br><br>
TS 101862 specified 2 alternative ways to declare a certificate as
QC.<br><br>
1) By inclusion of a QCStatements extension<br>
2) By including a certificate policy identifying this property<br><br>
Even though solution number 1) is far easier to handle by applications,
<br>
since they don't need to recognize specific QC Policies, ETSI didn't make
<br>
solution 1) mandatory or even consider making it critical, due to lack of
<br>
confidence that clients would widely deploy this solution. ETSI needed to
<br>
define a solution that could work even if no one choose to implement the
<br>
new extensions provided by RFC 3039.<br><br>
However, It is not feasible to keep clients updated over time with <br>
different QC policies and even those policies that are regarded <br>
standardized may be updated with change of OID as a result. It would be
<br>
devastating if we can't update a QCP because that would force an OID
update <br>
and that would render certificates useless because clients learned to
<br>
recognize only the old OID. This would be to build in a new root <br>
certificate problem into the platforms.<br><br>
My observations is that times have changed. I have seen clear indications
<br>
that market players want, and even require for interoperability reasons,
<br>
that use QCStatements solution is made mandatory and maybe even critical
<br>
for QC.<br><br>
Since both RFC 3039, and TS 101862 are up for revision, it is time to
<br>
revisit this issue.<br><br>
I have some questions and proposals:<br><br>
- Is there any experiences of this issue outside of Europe. I.e. are
there <br>
other legal systems that make use of the same declaration logic as the EU
<br>
directive, where the RFC 3039 profile is used fully or partly as a
solution <br>
to this issue?<br><br>
- I would suggest that the QCStatement mechanism is ought to be a
mandatory <br>
tool to communicate a Qualified Status. The question is:<br>
&nbsp;&nbsp;&nbsp; 1) whether this will have enough implementation
support to succeed?<br>
&nbsp;&nbsp;&nbsp; 2) whether is best specified in RFC 3039 or in local
profiles (such as <br>
TS 101862)?<br>
&nbsp;&nbsp;&nbsp; 3) If there could be a clear context defined where
criticality could be <br>
allowed or even required?<br><br>
I would really like feedback from practical experiences from this issue,
as <br>
well as constructive proposals.<br><br>
/Stefan<br><br>
<br><br>
<br>
/Stefan<br><br>
<br><br>
_____________________________<br>
Stefan Santesson,&nbsp; Retrospekt AB<br>
<a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a><br>
[phone] </blockquote>
<x-sigsep><p></x-sigsep>
_____________________________<br>
Stefan Santesson,&nbsp; Retrospekt AB<br>
<a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a><br>
[phone]</body>
</html>

--=====================_282876194==.ALT--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BG55115943 for ietf-pkix-bks; Tue, 11 Mar 2003 08:05:05 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BG53315936; Tue, 11 Mar 2003 08:05:04 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.8/8.12.8) with ESMTP id h2BG4rZF005191; Wed, 12 Mar 2003 05:04:53 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h2BG4qQ06135; Wed, 12 Mar 2003 05:04:52 +1300
Date: Wed, 12 Mar 2003 05:04:52 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Recommendation on subject matching rules needed..
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Vainikainen Saku EINT" <[e-mail]> writes:

>This is how we do it. And this is why the decryption does not work since the
>new enc cert gets a new serial number, ie. the encryption cert gets reissued,
>ie. the encryption key pair gets recertified, ie. cert hash changes. One
>cannot change the contents of a certificate without generating a new
>certificate serial number, ie. issue a new certificate.

But why is this a problem?  If you get something addressed to the old cert,
you use the old key to decrypt.  If it's for the new cert, you use the new
key.  In fact there isn't even any need to keep the old cert around if it's
decrypt-only, you mention PKCS #15, well that stores all the index info you
need with the key, so you don't need the cert at all.

>Our card has following PKCS#15 key usages on the private keys:

Have you actually tested all the combinations with your software?  That is,
added two certs that differ only in encryption vs.signature usage and then see
what the app does if asked for a signature or encryption cert?  Some of the
people I pointed out problems to were surprised at the problems, since things
seemed to work OK (meaning that the app just grabbed the first key it found
and used that, so everything appeared to work fine).

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BG4pt15909 for ietf-pkix-bks; Tue, 11 Mar 2003 08:04:51 -0800 (PST)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BG4n315903 for <[e-mail]>; Tue, 11 Mar 2003 08:04:49 -0800 (PST)
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 11 Mar 2003 08:04:41 -0800
Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 Mar 2003 08:04:45 -0800
Received: from RED-MSG-06.redmond.corp.microsoft.com ([157.54.12.198]) by INET-HUB-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 11 Mar 2003 08:04:47 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: QC Declaration
Date: Tue, 11 Mar 2003 08:04:42 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: QC Declaration
thread-index: AcLn04bBaoNbJNqgQyCiDRXX7eUl2gAFFOAg
From: "David Cross" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 11 Mar 2003 16:04:47.0891 (UTC) FILETIME=[F08B2E30:01C2E7E7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2BG4p315906
Sender: [e-mail]
Precedence: 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:

I agree with your proposal to make QCStatatement a mandatory extension
and also mark as critical.  I believe this is necessary requirement to
see wide adoption of qualified certifcates in applications.  Otherwise,
it is extremely difficult for generic applications to authoritatively
determine if a signature corresponds to a qualified certificate.


David B. Cross



-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Tuesday, March 11, 2003 5:27 AM
To: [e-mail]


The EU directive introduced a requirement on each CA, issuing QC
(Qualified Certificates), to clearly indicate in these certificate that
they are issued as QC.

ETSI implemented RFC 3039 in relation to the European electronic
signature directive through their Technical Standard (TS 101862)

TS 101862 specified 2 alternative ways to declare a certificate as QC.

1) By inclusion of a QCStatements extension
2) By including a certificate policy identifying this property

Even though solution number 1) is far easier to handle by applications,
since they don't need to recognize specific QC Policies, ETSI didn't
make solution 1) mandatory or even consider making it critical, due to
lack of confidence that clients would widely deploy this solution. ETSI
needed to define a solution that could work even if no one choose to
implement the new extensions provided by RFC 3039.

However, It is not feasible to keep clients updated over time with
different QC policies and even those policies that are regarded
standardized may be updated with change of OID as a result. It would be
devastating if we can't update a QCP because that would force an OID
update and that would render certificates useless because clients
learned to recognize only the old OID. This would be to build in a new
root certificate problem into the platforms.

My observations is that times have changed. I have seen clear
indications that market players want, and even require for
interoperability reasons, that use QCStatements solution is made
mandatory and maybe even critical for QC.

Since both RFC 3039, and TS 101862 are up for revision, it is time to
revisit this issue.

I have some questions and proposals:

- Is there any experiences of this issue outside of Europe. I.e. are
there other legal systems that make use of the same declaration logic as
the EU directive, where the RFC 3039 profile is used fully or partly as
a solution to this issue?

- I would suggest that the QCStatement mechanism is ought to be a
mandatory tool to communicate a Qualified Status. The question is:
    1) whether this will have enough implementation support to succeed?
    2) whether is best specified in RFC 3039 or in local profiles (such
as TS 101862)?
    3) If there could be a clear context defined where criticality could
be allowed or even required?

I would really like feedback from practical experiences from this issue,
as well as constructive proposals.

/Stefan




/Stefan



_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone]





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BFuLA14899 for ietf-pkix-bks; Tue, 11 Mar 2003 07:56:21 -0800 (PST)
Received: from sottmxssm.entrust.com (sottmxssm.entrust.com [216.191.252.10]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BFuJ314891 for <[e-mail]>; Tue, 11 Mar 2003 07:56:19 -0800 (PST)
Received: from SOTTMXS01.entrust.com (sottmxs01.entrust.com [10.4.61.7]) by sottmxssm.entrust.com (Switch-2.2.5/Switch-2.2.4) with ESMTP id V2BF2HX929182; Tue, 11 Mar 2003 10:53:33 -0500
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2656.59) id <GXR5M9YQ>; Tue, 11 Mar 2003 10:56:10 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, [e-mail]
Subject: RE: QC Declaration
Date: Tue, 11 Mar 2003 10:56:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Stefan,

While I believe that in the longer term certificate policies will be the
optimum 
way to convey the necessary information, I acknowledge that QC Statements is
the 
more popular scheme at present. Therefore I wouldn't have any problem should
this 
extension be mandated in RFC 3039. 

However, forcing its criticality is going too far I believe. There is an
important 
difference between critical and non-critical extensions that we need to keep
in 
mind from the relying party's perspective. If there is a non-critical
extension that 
the RP understands, but that extension includes some elements that it does
not, then 
the RP is free to process the parts it does understand and ignore others. If
an extension 
is critical however, the RP is required to understand ALL elements within
the extension.

Where I think this can become a problem is the content of the QC Statements
extension. Note 
that RFC 3039 and the ETSI profile define DIFFERENT statements for inclusion
in the extension. 
Also additional profiles may add their own local statements and even
narrower statements can 
get added in specific deployment environments. While the cert issuer may
want to include many 
of these statements to enable the cert to be used in various environments,
the RP should only 
be required to understand and process the statements that are appropriate to
its own 
operating environment as dictated by its local security policy (which could
be different than 
that under which the CA operated). Therefore I think requiring it to be
critical is risky. 
Also requiring that it always be critical would have interop/backward
compatibility issues.

Cheers,
Sharon

 


-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]]
Sent: Tuesday, March 11, 2003 8:27 AM
To: [e-mail]
Subject: QC Declaration



The EU directive introduced a requirement on each CA, issuing QC (Qualified 
Certificates), to clearly indicate in these certificate that they are 
issued as QC.

ETSI implemented RFC 3039 in relation to the European electronic signature 
directive through their Technical Standard (TS 101862)

TS 101862 specified 2 alternative ways to declare a certificate as QC.

1) By inclusion of a QCStatements extension
2) By including a certificate policy identifying this property

Even though solution number 1) is far easier to handle by applications, 
since they don't need to recognize specific QC Policies, ETSI didn't make 
solution 1) mandatory or even consider making it critical, due to lack of 
confidence that clients would widely deploy this solution. ETSI needed to 
define a solution that could work even if no one choose to implement the 
new extensions provided by RFC 3039.

However, It is not feasible to keep clients updated over time with 
different QC policies and even those policies that are regarded 
standardized may be updated with change of OID as a result. It would be 
devastating if we can't update a QCP because that would force an OID update 
and that would render certificates useless because clients learned to 
recognize only the old OID. This would be to build in a new root 
certificate problem into the platforms.

My observations is that times have changed. I have seen clear indications 
that market players want, and even require for interoperability reasons, 
that use QCStatements solution is made mandatory and maybe even critical 
for QC.

Since both RFC 3039, and TS 101862 are up for revision, it is time to 
revisit this issue.

I have some questions and proposals:

- Is there any experiences of this issue outside of Europe. I.e. are there 
other legal systems that make use of the same declaration logic as the EU 
directive, where the RFC 3039 profile is used fully or partly as a solution 
to this issue?

- I would suggest that the QCStatement mechanism is ought to be a mandatory 
tool to communicate a Qualified Status. The question is:
    1) whether this will have enough implementation support to succeed?
    2) whether is best specified in RFC 3039 or in local profiles (such as 
TS 101862)?
    3) If there could be a clear context defined where criticality could be 
allowed or even required?

I would really like feedback from practical experiences from this issue, as 
well as constructive proposals.

/Stefan




/Stefan



_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone] 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BFsXe14595 for ietf-pkix-bks; Tue, 11 Mar 2003 07:54:33 -0800 (PST)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BFsV314588 for <[e-mail]>; Tue, 11 Mar 2003 07:54:31 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2BFsA5w001692; Tue, 11 Mar 2003 10:54:11 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510030aba93b4815eb9@[128.89.88.34]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 11 Mar 2003 10:52:18 -0500
To: "Vainikainen Saku EINT" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Recommendation on subject matching rules needed..
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:22 PM +0200 3/11/03, Vainikainen Saku EINT wrote:
><SNIP>
>
>Certificate contains enough data to compare the subjects and
>the keys instead of the certificates. The comparison should - in
>my opinion - go more or less as follows:
>
>Allow decrypt
>
>1) if Subject Key Identifiers match
>2) if Subject Unique Identifiers match
>3) if Subjects + Subject Alt. Names match
>4) if Issuer Key Identifiers match
>5) if Issuer Unique Identifiers match
>6) if Issuers match
>
>Has anyone run into this problem as well ? Is this
>problem discussed in any existing papers (I haven't yet found
>any) ? I suppose this is going to be quite a problem if not
>addressed properly..

As Marcus points out, if you have the right key, technically you 
should be able to decrypt the data (old messages in this case). I 
assume the problem is that the software in question is trying to 
verify that the key being presented is the right one, by matching 
against a stored cert in the message, and t a cert bound to the 
private key to be employed. One might ask the vendors why they are 
doing this, other than to save the user time if/when the wrong key is 
presented for decryption. Your text said:

>It seems that all the software we have tested (eg. MSoft,
>Utimaco) tend to do somekind of binary comparison (hash
>values I suppose) on the certificate used to encrypt the data
>(which is usually stored with the encrypted data) and on the
>certificate related to the encryption keypair being used to
>decrypt the data.

This is not quite right, in that no CERT was used to encrypt the 
data. It is the PUBLIC KEY from the cert that was used. This suggests 
that the answer to your question is that IF software wants to check 
that the right key is going to be used in an attempt to decrypt a 
message, and IF the means of checking is based on a cert bound to the 
private key and a cert stored with the data to be decrypted,  THEN 
the only appropriate comparison is on the respective public keys, or 
hashes thereof.  Any comparison based on other parts of the certs in 
question is including unnecessary data, which is why you are 
encountering this problem.

BTW, this problem is even more complex is DH was used instead of RSA, 
so one would hope that the vendors have a more through scheme for 
this sort of checking in that case, i.e., assuming they have 
generated algorithm independent code :-)

Steve





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BFlwQ13481 for ietf-pkix-bks; Tue, 11 Mar 2003 07:47:58 -0800 (PST)
Received: from smtp23.kolumbus.fi (smtp23.kolumbus.fi [193.229.0.81]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BFlu313476 for <[e-mail]>; Tue, 11 Mar 2003 07:47:56 -0800 (PST)
Received: from dom1-cn2-hki.dom1.epnet (dom1-cn2-hki.dom1.epnet [172.21.176.74]) by smtp23.kolumbus.fi (8.12.8/8.12.4) with ESMTP id h2BFlq9b011531 for <[e-mail]>; Tue, 11 Mar 2003 17:47:52 +0200 (EET)
Received: from dom1-mb1-hki.dom1.epnet ([172.21.176.65]) by dom1-cn2-hki.dom1.epnet with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 17:47:51 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Recommendation on subject matching rules needed..
Date: Tue, 11 Mar 2003 17:47:50 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Recommendation on subject matching rules needed..
Thread-Index: AcLn4svGu4NtA11ySXuNhQWYjfy8FwAAUdIQ
From: "Vainikainen Saku EINT" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 11 Mar 2003 15:47:51.0055 (UTC) FILETIME=[927651F0:01C2E7E5]
X-MailScanner: Found to be clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2BFlv313477
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > Allow decrypt
> > 
> > 1) if Subject Key Identifiers match
> > 2) if Subject Unique Identifiers match
> > 3) if Subjects + Subject Alt. Names match
> > 4) if Issuer Key Identifiers match
> > 5) if Issuer Unique Identifiers match
> > 6) if Issuers match
> 
> Shouldn't just being in possession of the private key be enough to 
> decrypt previously encrypted data. (what is a certificate 
> needed for in this use case? )
> 
> I can think of a minor reason to have a certificate: to locate the 
> key pair by searching for subject and key usage - however, 
> that should not be the only way by which a software can 
> locate the right key to use, or?

I suppose if the cert is not used to locate the key, then the only way
to find out which key to use would be to decrypt with all available keys
and try to make sense of the decrypted data to figure out which key was
the proper one..

Anyways at least the email clients want to check the e-mail address in
the cert as well as issuer+serno or do some form of binary match on the
certs.

Saku.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BFSWL12349 for ietf-pkix-bks; Tue, 11 Mar 2003 07:28:32 -0800 (PST)
Received: from smtp23.kolumbus.fi (smtp23.kolumbus.fi [193.229.0.81]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BFPg312239; Tue, 11 Mar 2003 07:25:42 -0800 (PST)
Received: from dom1-cn1-hki.dom1.epnet (dom1-cn1-hki.dom1.epnet [172.21.176.70]) by smtp23.kolumbus.fi (8.12.8/8.12.4) with ESMTP id h2BFPa9b010710; Tue, 11 Mar 2003 17:25:36 +0200 (EET)
Received: from dom1-mb1-hki.dom1.epnet ([172.21.176.65]) by dom1-cn1-hki.dom1.epnet with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 17:25:35 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Recommendation on subject matching rules needed..
Date: Tue, 11 Mar 2003 17:25:35 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Recommendation on subject matching rules needed..
Thread-Index: AcLn3noPJeZuBm3aRACxs8mv9nNhdAAADFUQ
From: "Vainikainen Saku EINT" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 11 Mar 2003 15:25:35.0381 (UTC) FILETIME=[7656A450:01C2E7E2]
X-MailScanner: Found to be clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2BFPl312241
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >Our cards (=certs) are valid for three years. If the card 
> has been in 
> >use for 2 years when we reissue it with recovered enc key, 
> we need to 
> >reissue the enc cert also - otherwise the recovered enc key 
> cert could 
> >be usable only for one year whereas the other certs would be 
> usable for 
> >three years.
> 
> Why not just leave the decryption key as is and issue a new 
> 3-year decryption cert?  This in effect is what I do in my 
> code (with the date-based transparent rollover).

This is how we do it. And this is why the decryption does not work since
the new enc cert gets a new serial number, ie. the encryption cert gets
reissued, ie. the encryption key pair gets recertified, ie. cert hash
changes. One cannot change the contents of a certificate without
generating a new certificate serial number, ie. issue a new certificate.

> >Also - if we pile up all the previous enc certs to the card 
> along with 
> >the new cert, we run out of card space as well as introduce new 
> >problems since the apps usually don't iterate though all the 
> certs and 
> >end up using the first cert available.
> 
> Can you fit 4 keys?

Yep - but we don't want to do that because when we take that path we
need to have space for (not infinite but anyways) many keys, since if
start maintaining key chains (generating a new key on every reissue and
attaching it to the chain of old enc keys) there is no end to it..
 
> (On a completely unrelated topic, are you sure the software 
> you're using is  able to make sense of the NR key there?  A 
> lot of software is totally  incapable of distinguishing 
> between signature and NR keys, and just takes the  first one 
> that it finds with {signature,NR} enabled.  For that matter, 
> I've  found a number of card issuers in [looks at sender's 
> country code], uhh,  well, Scandinavia who set PKCS #11 key 
> usage bits incorrectly on cards, so  you get crypto keys 
> marked as signing keys and vice versa, or all keys marked  as 
> crypto or signing keys, or other oddities, and no-one even 
> notices that  they're encrypting with the NR key.  The point 
> is that if your software can't  differentiate between 
> signature and NR (or even all three key types), you  could 
> dump the NR key and add an extra encryption key instead).

Our card has following PKCS#15 key usages on the private keys:

auth: 	sign, sign-recover, unwrap
nonrep:	nonrepudiation
enc:		decrypt, unwrap

Certs go as follows:

auth:		digital signature, key encipherment
nonrep:	nonrepudiation
enc:		key encripherment, data encipherment

Extended key usages on certs:

auth:		Client Authentication (1.3.6.1.5.5.7.3.2)
		Secure Email (1.3.6.1.5.5.7.3.4)
		IP security IKE intermediate (1.3.6.1.5.5.8.2.2)
		Smart Card Logon (1.3.6.1.4.1.311.20.2.2)

nonrep:	-

enc:		Secure Email (1.3.6.1.5.5.7.3.4)
		IP security IKE intermediate (1.3.6.1.5.5.8.2.2)

Authentication key is used in SSL authentication, W2k logon, VPN
authentication and email signing (=authentication).

Nonrepudiation key is not yet used anywhere (lack of document management
software supporting smartcards).

Encryption key is used in e-mail encryption as well as in
disk/folder/file encryption (option to use in VPN connections as well).

Saku.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BFRr612324 for ietf-pkix-bks; Tue, 11 Mar 2003 07:27:53 -0800 (PST)
Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BFRq312319 for <[e-mail]>; Tue, 11 Mar 2003 07:27:52 -0800 (PST)
Received: from zidane.cc.vt.edu (IDENT:[e-mail] [10.1.1.13]) by lennier.cc.vt.edu (8.12.8/8.12.8) with ESMTP id h2BFRpIE008996; Tue, 11 Mar 2003 10:27:51 -0500 (EST)
Received: from voyager (zuni.cs.vt.edu [128.173.54.49]) by zidane.cc.vt.edu (Mirapoint Messaging Server MOS 3.3.2-CR) with ESMTP id BDS07539; Tue, 11 Mar 2003 10:27:50 -0500 (EST)
From: "Markus Lorch" <[e-mail]>
To: "'Vainikainen Saku EINT'" <[e-mail]>, <[e-mail]>
Subject: RE: Recommendation on subject matching rules needed..
Date: Tue, 11 Mar 2003 10:27:39 -0500
Message-ID: <000201c2e7e2$c471e960$b1ae52c6@voyager>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-reply-to: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Certificate contains enough data to compare the subjects and 
> the keys instead of the certificates. The comparison should - in 
> my opinion - go more or less as follows:
> 
> Allow decrypt
> 
> 1) if Subject Key Identifiers match
> 2) if Subject Unique Identifiers match
> 3) if Subjects + Subject Alt. Names match
> 4) if Issuer Key Identifiers match
> 5) if Issuer Unique Identifiers match
> 6) if Issuers match
> 

Shouldn't just being in possession of the private key be enough to 
decrypt previously encrypted data. (what is a certificate needed
for in this use case? )

I can think of a minor reason to have a certificate: to locate the 
key pair by searching for subject and key usage - however, that should
not
be the only way by which a software can locate the right key to use, or?

Markus

--------------------------------
Markus Lorch

Dept. of Computer Science (0106)
Virginia Tech, Blacksburg, VA 24061

Phone/Fax: [phone]
http://csgrad.cs.vt.edu/~mlorch 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BFQY712273 for ietf-pkix-bks; Tue, 11 Mar 2003 07:26:34 -0800 (PST)
Received: from smtp22.kolumbus.fi (smtp22.kolumbus.fi [193.229.0.82]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BFQW312269 for <[e-mail]>; Tue, 11 Mar 2003 07:26:33 -0800 (PST)
Received: from dom1-cn2-hki.dom1.epnet (dom1-cn2-hki.dom1.epnet [172.21.176.74]) by smtp22.kolumbus.fi (8.12.8/8.12.4) with ESMTP id h2BFQRI3023895 for <[e-mail]>; Tue, 11 Mar 2003 17:26:27 +0200 (EET)
Received: from dom1-mb1-hki.dom1.epnet ([172.21.176.65]) by dom1-cn2-hki.dom1.epnet with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 17:26:25 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Recommendation on subject matching rules needed..
Date: Tue, 11 Mar 2003 17:26:25 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Recommendation on subject matching rules needed..
Thread-Index: AcLn1NcX1zR/JHV5R/CwaoHtBJXxwgAARE7Q
From: "Vainikainen Saku EINT" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 11 Mar 2003 15:26:25.0469 (UTC) FILETIME=[943176D0:01C2E7E2]
X-MailScanner: Found to be clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2BFQX312270
Sender: [e-mail]
Precedence: 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 don't follow the logic here... If hash of issuer+serial is 
> used, won't the same issue happen upon revalidation of the 
> key pair (that is, when the original certificate expires)? Or 
> am I more or less required to do a key replacement operation 
> (or changeover, or whatever the correct terminology is) at that point?

As far as I have understood, we cannot modify the cert (eg. do a rekey)
without changing the serial number, ie. we have to issue a new
certificate if we do any changes in the contents.

Again the passport analogy - if your name changes, you need a new
passport. If you want to change your passport photo, you need a new
passport. If your passport expires, you need a new passport, etc..

This is why I would like to see some rules on matching the user and the
key instead of doing the matching based on issuer+serno, cert hash or
other hash derivatives.

Saku.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BFJSl11893 for ietf-pkix-bks; Tue, 11 Mar 2003 07:19:28 -0800 (PST)
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BFJM311882 for <[e-mail]>; Tue, 11 Mar 2003 07:19:22 -0800 (PST)
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04119; Tue, 11 Mar 2003 07:19:18 -0800 (PST)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h2BFJH021803; Tue, 11 Mar 2003 10:19:17 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 11 Mar 2003 10:16:55 -0500
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "'Anders Rundgren'" <[e-mail]>, [e-mail], [e-mail]
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)
References: <007f01c2e75f$4b93ec10$2d00a8c0@Chokhani>
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>

Thanks to Santosh and Roger for correcting me on the
CP/CPS distinction. I apologize for my error. I don't
claim to be an expert on CP/CPS. For that, I defer to
Santosh and others.

In any case, we all agree that relying party software
cannot read and evaluate the text of the CP or CPS.
That's why the Certificate Policies extension uses OIDs
to identify policies in a machine-readable manner.

In his most recent email, Anders said:
> I'm sorry that I mixed CP and CPS but I would like to extend
> the scope of my previous "policy-rant" to include all legal
> information inserted in EE-certificates whatever it is called
> and whatever its purpose may be.

Since this is just a rant, I should ignore it. And I'm
no legal expert, so I can't say why lawyers want to
refer to the text of a CP or CPS in a certificate. But
as long as they don't use too many bits for it (by
including the actual text instead of a URL), I don't mind.

Anders also stated that "all commercial CAs of any
significance" use a separate CA for each policy. This
is probably true. So far, most relying party software
doesn't support the Certificate Policies extension. It
would be pointless or even dangerous for large commercial
CAs to ignore this. But that doesn't mean it must always
be so. If we refuse to work on anything that's not already
widely deployed, we'll have to stop all innovation.
Instead, we must continue to address real problems with
real solutions. If customers see value in these solutions,
they will be implemented by vendors.

Certificate policies have definite utility. Several
communities are piloting their use, such as the U.S.
Government. Without certificate policies, they would
need to maintain a separate network of CAs for every
policy and require identical policies throughout each
network. Using certificate policies allows them to
have a single network of CAs with various policies
in use, some within only a subnetwork.

Anders also said it is very hard to "standardize legal
stuff". I agree. That's one reason why PKI deployment
has been slow. In some contexts, it's not necessary to
agree on what a certificate means. But in most of the
contexts that really care about security, it *is*
necessary to agree. That's when CPs and CPSs become
important.

One emerging solution is to have a consortium develop
a common CP and run a bridge CA. When organizations ask
to cross-certify with the bridge, they must agree to the
CP and demonstrate that they have a CP and CPS that is
stringent enough for the bridge CA to accept it as
equivalent. This is a time when policy mapping becomes
especially important.

As I said above, I should probably just ignore statements
on this list that are misinformed, misguided, or misleading.
That's what most people on the list seem to do. But I
worry that leaving such statements unchallenged will lead
people to conclude they are correct. So I'll try my best
to answer these comments, when I can find the time. Please
correct me if my answers are wrong.

Thanks,

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BEv2j10813 for ietf-pkix-bks; Tue, 11 Mar 2003 06:57:02 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BEv0310809; Tue, 11 Mar 2003 06:57:00 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.8/8.12.8) with ESMTP id h2BEunZF003827; Wed, 12 Mar 2003 03:56:49 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h2BEup205527; Wed, 12 Mar 2003 03:56:51 +1300
Date: Wed, 12 Mar 2003 03:56:51 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Recommendation on subject matching rules needed..
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[Also CC'd to S/MIME]

"Vainikainen Saku EINT" <[e-mail]> writes:

>>>It seems that all the software we have tested (eg. MSoft, Utimaco)
>>
>>Everyone, not just those two.
>
>OK - this is more or less what I assumed :( Do you know if there is any work
>being done on this subject in terms of a recommendation
>paper/draft/something?

See my previous message.  It's really an application/policy issue, I don't
know if there's much to say in standards except maybe to post a skull and
crossbones next to a description of the problem to let people know what
they're in for.

>Our cards (=certs) are valid for three years. If the card has been in use for
>2 years when we reissue it with recovered enc key, we need to reissue the enc
>cert also - otherwise the recovered enc key cert could be usable only for one
>year whereas the other certs would be usable for three years.

Why not just leave the decryption key as is and issue a new 3-year decryption
cert?  This in effect is what I do in my code (with the date-based transparent
rollover).

>Also - if we pile up all the previous enc certs to the card along with the
>new cert, we run out of card space as well as introduce new problems since
>the apps usually don't iterate though all the certs and end up using the
>first cert available.

Can you fit 4 keys?

(On a completely unrelated topic, are you sure the software you're using is
 able to make sense of the NR key there?  A lot of software is totally
 incapable of distinguishing between signature and NR keys, and just takes the
 first one that it finds with {signature,NR} enabled.  For that matter, I've
 found a number of card issuers in [looks at sender's country code], uhh,
 well, Scandinavia who set PKCS #11 key usage bits incorrectly on cards, so
 you get crypto keys marked as signing keys and vice versa, or all keys marked
 as crypto or signing keys, or other oddities, and no-one even notices that
 they're encrypting with the NR key.  The point is that if your software can't
 differentiate between signature and NR (or even all three key types), you
 could dump the NR key and add an extra encryption key instead).

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BEj4n10457 for ietf-pkix-bks; Tue, 11 Mar 2003 06:45:04 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BEj1310451; Tue, 11 Mar 2003 06:45:01 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.8/8.12.8) with ESMTP id h2BEipZF003661; Wed, 12 Mar 2003 03:44:51 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h2BEipt05508; Wed, 12 Mar 2003 03:44:51 +1300
Date: Wed, 12 Mar 2003 03:44:51 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RE: Recommendation on subject matching rules needed..
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[CC'd to the S/MIME list, this is really an S/MIME and not a PKIX issue.  For
 those just joining us, the issue is what to do when you re-certify your
 encryption key (NB: Someone else is doing this, not me :-)]

"Olle Mulmo" <[e-mail]> writes:

>I don't follow the logic here... If hash of issuer+serial is used, 

Just the issuerAndSerialNumber, there's no hash.

>won't the same issue happen upon revalidation of the key pair (that is, when
>the original certificate expires)? Or am I more or less required to do a key
>replacement operation (or changeover, or whatever the correct terminology is)
>at that point?

It's a black hole.  The method I've seen used a few times (because it works
with pretty much anything) is some variation of running two systems, one with
the clock set back so it can still use the old key, and another one with the
clock running at the current time for the new key.  Every vendor does it
differently.  Some require a system rebuild (the equivalent of a
reformat+reinstall-Windows operation for the crypto/PKI software).  Some
handle both keys, with various amounts of manual intervention.  I've seen one
group that have a Grand Key Changeover day when everyone has to roll over
their keys (well, certs), and people are instructed not to send any critical
encrypted messages at that time.

My code allows multiple keys and preferentially grabs the most recent (that
is, currently-valid) one, since that's the behaviour the most users asked for.
On the decrypting side, it looks up the key purely by issuerAndSerialNumber
(ignoring date issues), so you can decrypt with both the old and new key,
depending on what the sender used.  That way you can swap in a new key at any
time and it just works (if you even happen to be reading PKCS #15/ISO 7816-15
and wonder why there are validity times attached to private keys, this is
why).

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BELeY09318 for ietf-pkix-bks; Tue, 11 Mar 2003 06:21:40 -0800 (PST)
Received: from mail.slb.com (nammta01.sugar-land.nam.slb.com [163.188.150.130]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BELc309314 for <[e-mail]>; Tue, 11 Mar 2003 06:21:39 -0800 (PST)
Received: from conversion-daemon.nammta01.sugar-land.nam.slb.com by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) id <[e-mail]> for [e-mail]; Tue, 11 Mar 2003 14:18:39 +0000 (GMT)
Received: from namems01.sugar-land.oilfield.slb.com (namems01.sugar-land.oilfield.slb.com [163.188.150.131]) by nammta01.sugar-land.nam.slb.com (iPlanet Messaging Server 5.2 HotFix 1.06 (built Nov 15 2002)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 11 Mar 2003 14:18:14 +0000 (GMT)
Received: from conversion-daemon.namems01.sugar-land.oilfield.slb.com by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov  1 2002)) id <[e-mail]> for [e-mail]; Tue, 11 Mar 2003 14:18:14 +0000 (GMT)
Received: from SCHLUMBE-OITRVU.parsippany.sns.slb.com (vpnpool106.houston.sinet.slb.com [163.188.124.106]) by namems01.sugar-land.oilfield.slb.com (iPlanet Messaging Server 5.1 HotFix 1.7 (built Nov  1 2002)) with ESMTP id <[e-mail]> for [e-mail]; Tue, 11 Mar 2003 14:18:14 +0000 (GMT)
Content-return: prohibited
Date: Tue, 11 Mar 2003 09:18:11 -0500
From: "Joel S. Kazin" <[e-mail]>
Subject: RE: Certificate Policies (was Re: Trivial PKI Question)
In-reply-to: <007f01c2e75f$4b93ec10$2d00a8c0@Chokhani>
X-Sender: jkazin@163.188.150.131
To: [e-mail]
Message-id: <5.1.1.1.2.20030311085737.00aa3d20@163.188.150.131>
MIME-version: 1.0
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
Content-type: multipart/alternative; boundary="Boundary_(ID_p5GMg+EWC6c5btylKhlS7w)"
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--Boundary_(ID_p5GMg+EWC6c5btylKhlS7w)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

RFC 3280 allows a CA to include both the OID of the CP and the OID of the 
CPS within a certificate. I specify this when writing CP and CPS 
documents.  While I would not recommend it, and one attorney actually asked 
for it, the CA can also include the full text of a user notice within the 
certificate. From RFC 3280.

id-ce-certificatePolicies OBJECT IDENTIFIER ::=  { id-ce 32 }

    anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies 0 }

    certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation

    PolicyInformation ::= SEQUENCE {
         policyIdentifier   CertPolicyId,
         policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                 PolicyQualifierInfo OPTIONAL }

    CertPolicyId ::= OBJECT IDENTIFIER

    PolicyQualifierInfo ::= SEQUENCE {
         policyQualifierId  PolicyQualifierId,
         qualifier          ANY DEFINED BY policyQualifierId }

    -- policyQualifierIds for Internet policy qualifiers

    id-qt          OBJECT IDENTIFIER ::=  { id-pkix 2 }
    id-qt-cps      OBJECT IDENTIFIER ::=  { id-qt 1 }
    id-qt-unotice  OBJECT IDENTIFIER ::=  { id-qt 2 }

    PolicyQualifierId ::=
         OBJECT IDENTIFIER ( id-qt-cps | id-qt-unotice )

    Qualifier ::= CHOICE {
         cPSuri           CPSuri,
         userNotice       UserNotice }


At 06:46 PM 3/10/2003 -0500, Santosh Chokhani wrote:

>Steve:
>
>CPS is not necessarily written by lawyers.  A CPS is a description of
>procedures used to meet the CP requirements.  If one is following RFC 2527
>framework, lawyers may write legal sections within Chapter 2.  Rest of the
>CPS is better written by systems folks who know about the operating
>procedures and security controls.

I agreed with Santosh. With a few exceptions, mostly the ABA-ISC folks and 
a few legal firms, attorneys at large corporations deploying a PKI do not 
initially know what a CP is and would not be ready to write one.  Writing a 
CPS is a job for someone with a background in IT controls and 
operations.  One of the major delays in implementing a large PKI is getting 
the organization's attorneys to review and approve the CP and CPS 
documents.  Getting approval for RFC 2527bis will help a bit as it keeps 
the legal sections of the "framework" together.


>The CPS pointer is provided in the certificate in case the relying party
>wants to review the controls used in generation and revocation of a
>certificate.
>
>I agree with you in terms of policy OIDs in the certificates.
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On
>Behalf Of Steve Hanna
>Sent: Monday, March 10, 2003 5:02 PM
>To: Anders Rundgren
>Cc: [e-mail]; [e-mail]
>Subject: Re: Certificate Policies (was Re: Trivial PKI Question)
>
>
>
>I've been meaning to correct a comment you made in an
>earlier message:
>
>Chris Gilbert wrote:
> > > The two are likely to contain different certificatePolicies.
>
>You responded:
>
> > <CertificatePolicyRant>
> > It is interesting to note that CPSs are frequently mentioned in this
> > context in spite of the fact that none of the major crypto-packages
> > (Windows and Java) offers any way to specify CPSs as a part of a CA
> > trust acceptance process.  The reason for this is simple: Computers
> > don't understand legal matters and CPSs are deployment-wise anything
> > but standardized. Peter Gutman's term "Kitchen sink extensions" is a
> > fair description of the value of CPSs for practical purposes.  Do
> > "SysAdmins" ever bother about the CPS of their VeriSign web-server
> > certificates? My Thawt web-server cert does not even have a CPS
> > extension and I haven't missed it that much.  CPSs were designed by
> > lawyers for lawyers.  But lawyers do not run e-business systems, write
> > application software packages, or know how to handle a Java keystore.
> > </CertificatePolicyRant>
>
>You're confusing a Certification Practice Statement (CPS)
>with a Certificate Policy. A CPS is typically written by lawyers for lawyers
>and can't be evaluated by a machine. But that doesn't mean that the
>Certificate Policies extension isn't useful or supported. It's a completely
>different beast.
>
>The Certificate Policies extension allows a CA to include
>OIDs in a PKC indicating the policy (or policies) under
>which the PKC was issued. This is especially important when there's more
>than one certificate policy in use within a group of CAs (high assurance,
>low assurance, or whatever). The relying party needs to distinguish which
>certificate policy (or policies) applies to each certificate.
>
>J2SE 1.4 and later allows applications to specify which certificate policy
>OIDs are acceptable when they request validation of a certification path.
>And we handle policy mapping properly. I don't know how many applications
>use these features, but they are provided.
>
>As for whether it's useful or important to include a CPS Pointer in a
>certificate, I don't know. I'll leave that up to the lawyers.
>
>Thanks,
>
>Steve

Senior Consultant
Technical Consulting Practice, Northeast Region
Schlumberger Network Solutions

[e-mail]
www.slb.com/nws

35 Waterview Blvd.
Suite 210
Parsippany, NJ 07054-1200
USA

Phone  [phone]
Mobile  [phone]

--Boundary_(ID_p5GMg+EWC6c5btylKhlS7w)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html>
RFC 3280 allows a CA to include both the OID of the CP and the OID of the
CPS within a certificate. I specify this when writing CP and CPS
documents.&nbsp; While I would not recommend it, and one attorney
actually asked for it, the CA can also include the full text of a user
notice within the certificate. From RFC 3280.<br><br>
<font size=2>i</font><font size=2 color="#0000FF">d-ce-certificatePolicies
OBJECT IDENTIFIER ::=&nbsp; { id-ce 32 }<br><br>
&nbsp;&nbsp; anyPolicy OBJECT IDENTIFIER ::= { id-ce-certificate-policies
0 }<br><br>
&nbsp;&nbsp; certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF
PolicyInformation<br><br>
&nbsp;&nbsp; PolicyInformation ::= SEQUENCE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; policyIdentifier&nbsp;&nbsp;
CertPolicyId,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; policyQualifiers&nbsp;&nbsp;
SEQUENCE SIZE (1..MAX) OF<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
PolicyQualifierInfo OPTIONAL }<br><br>
&nbsp;&nbsp; CertPolicyId ::= OBJECT IDENTIFIER<br><br>
&nbsp;&nbsp; PolicyQualifierInfo ::= SEQUENCE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; policyQualifierId&nbsp;
PolicyQualifierId,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
qualifier&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ANY
DEFINED BY policyQualifierId }<br><br>
&nbsp;&nbsp; -- policyQualifierIds for Internet policy
qualifiers<br><br>
&nbsp;&nbsp; id-qt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
OBJECT IDENTIFIER ::=&nbsp; { id-pkix 2 }<br>
&nbsp;&nbsp; id-qt-cps&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OBJECT IDENTIFIER
::=&nbsp; { id-qt 1 }<br>
&nbsp;&nbsp; id-qt-unotice&nbsp; OBJECT IDENTIFIER ::=&nbsp; { id-qt 2
}<br><br>
&nbsp;&nbsp; PolicyQualifierId ::=<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OBJECT IDENTIFIER ( id-qt-cps
| id-qt-unotice )<br><br>
&nbsp;&nbsp; Qualifier ::= CHOICE {<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
cPSuri&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
CPSuri,<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
userNotice&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UserNotice }<br><br>
<br>
</font>At 06:46 PM 3/10/2003 -0500, Santosh Chokhani wrote:<br><br>
<blockquote type=cite class=cite cite>Steve:<br><br>
CPS is not necessarily written by lawyers.&nbsp; A CPS is a description
of<br>
procedures used to meet the CP requirements.&nbsp; If one is following
RFC 2527<br>
framework, lawyers may write legal sections within Chapter 2.&nbsp; Rest
of the<br>
CPS is better written by systems folks who know about the operating<br>
procedures and security controls.</blockquote><br>
I agreed with Santosh. With a few exceptions, mostly the ABA-ISC folks
and a few legal firms, attorneys at large corporations deploying a PKI do
not initially know what a CP is and would not be ready to write
one.&nbsp; Writing a CPS is a job for someone with a background in IT
controls and operations.&nbsp; One of the major delays in implementing a
large PKI is getting the organization's attorneys to review and approve
the CP and CPS documents.&nbsp; Getting approval for RFC 2527bis will
help a bit as it keeps the legal sections of the &quot;framework&quot;
together.&nbsp;&nbsp; &nbsp; <br><br>
<br>
<blockquote type=cite class=cite cite>The CPS pointer is provided in the
certificate in case the relying party<br>
wants to review the controls used in generation and revocation of a<br>
certificate.<br><br>
I agree with you in terms of policy OIDs in the certificates.<br><br>
-----Original Message-----<br>
From: [e-mail]
[<a href="mailto:[e-mail]" eudora="autourl">mailto:[e-mail]</a>]
On<br>
Behalf Of Steve Hanna<br>
Sent: Monday, March 10, 2003 5:02 PM<br>
To: Anders Rundgren<br>
Cc: [e-mail]; [e-mail]<br>
Subject: Re: Certificate Policies (was Re: Trivial PKI 
Question)<br><br>
<br><br>
I've been meaning to correct a comment you made in an<br>
earlier message:<br><br>
Chris Gilbert wrote:<br>
&gt; &gt; The two are likely to contain different
certificatePolicies.<br><br>
You responded:<br><br>
&gt; &lt;CertificatePolicyRant&gt;<br>
&gt; It is interesting to note that CPSs are frequently mentioned in this
<br>
&gt; context in spite of the fact that none of the major crypto-packages
<br>
&gt; (Windows and Java) offers any way to specify CPSs as a part of a CA
<br>
&gt; trust acceptance process.&nbsp; The reason for this is simple:
Computers <br>
&gt; don't understand legal matters and CPSs are deployment-wise anything
<br>
&gt; but standardized. Peter Gutman's term &quot;Kitchen sink
extensions&quot; is a <br>
&gt; fair description of the value of CPSs for practical purposes.&nbsp;
Do <br>
&gt; &quot;SysAdmins&quot; ever bother about the CPS of their VeriSign
web-server <br>
&gt; certificates? My Thawt web-server cert does not even have a CPS
<br>
&gt; extension and I haven't missed it that much.&nbsp; CPSs were
designed by <br>
&gt; lawyers for lawyers.&nbsp; But lawyers do not run e-business
systems, write <br>
&gt; application software packages, or know how to handle a Java
keystore. <br>
&gt; &lt;/CertificatePolicyRant&gt;<br><br>
You're confusing a Certification Practice Statement (CPS)<br>
with a Certificate Policy. A CPS is typically written by lawyers for
lawyers<br>
and can't be evaluated by a machine. But that doesn't mean that the<br>
Certificate Policies extension isn't useful or supported. It's a
completely<br>
different beast.<br><br>
The Certificate Policies extension allows a CA to include<br>
OIDs in a PKC indicating the policy (or policies) under<br>
which the PKC was issued. This is especially important when there's
more<br>
than one certificate policy in use within a group of CAs (high
assurance,<br>
low assurance, or whatever). The relying party needs to distinguish
which<br>
certificate policy (or policies) applies to each certificate.<br><br>
J2SE 1.4 and later allows applications to specify which certificate
policy<br>
OIDs are acceptable when they request validation of a certification
path.<br>
And we handle policy mapping properly. I don't know how many
applications<br>
use these features, but they are provided.<br><br>
As for whether it's useful or important to include a CPS Pointer in
a<br>
certificate, I don't know. I'll leave that up to the lawyers.<br><br>
Thanks,<br><br>
Steve</blockquote>
<x-sigsep><p></x-sigsep>
Senior Consultant<br>
Technical Consulting Practice, Northeast Region<br>
Schlumberger Network Solutions<br><br>
[e-mail]<br>
<a href="http://www.slb.com/nws" eudora="autourl">www.slb.com/nws<br><br>
</a>35 Waterview Blvd.<br>
Suite 210<br>
Parsippany, NJ 07054-1200<br>
USA<br><br>
Phone&nbsp; [phone]<br>
Mobile&nbsp; [phone]</html>

--Boundary_(ID_p5GMg+EWC6c5btylKhlS7w)--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BDrtG08333 for ietf-pkix-bks; Tue, 11 Mar 2003 05:53:55 -0800 (PST)
Received: from smtp23.kolumbus.fi (smtp23.kolumbus.fi [193.229.0.81]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BDrr308328 for <[e-mail]>; Tue, 11 Mar 2003 05:53:53 -0800 (PST)
Received: from dom1-cn2-hki.dom1.epnet (dom1-cn2-hki.dom1.epnet [172.21.176.74]) by smtp23.kolumbus.fi (8.12.8/8.12.4) with ESMTP id h2BDrl9b006400 for <[e-mail]>; Tue, 11 Mar 2003 15:53:47 +0200 (EET)
Received: from dom1-mb1-hki.dom1.epnet ([172.21.176.65]) by dom1-cn2-hki.dom1.epnet with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 15:53:46 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Recommendation on subject matching rules needed..
Date: Tue, 11 Mar 2003 15:53:46 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Recommendation on subject matching rules needed..
Thread-Index: AcLnxNh5UW+rgvpvTQ2Zo3hebvX+zQADmfnQ
From: "Vainikainen Saku EINT" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 11 Mar 2003 13:53:46.0402 (UTC) FILETIME=[A2BB2820:01C2E7D5]
X-MailScanner: Found to be clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2BDrs308330
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >It seems that all the software we have tested (eg. MSoft, Utimaco)
>
> Everyone, not just those two.

OK - this is more or less what I assumed :( Do you know if there is any
work being done on this subject in terms of a recommendation
paper/draft/something ?

I mean, this is like a person with a new passport being denied entrance
to some country, because on his/her previous visit his/her passport had
a different serial number.. (ok - a bit bad analogy, but anyways..)
 
> >The only problem is that the encryption key pair may have been 
> >recertified in between.
> 
> Therein lies the problem: Don't issue multiple certificates 
> for the same key.  If you "recover the archived encryption 
> keypair" why not recover the cert that goes with it?

Our cards (=certs) are valid for three years. If the card has been in
use for 2 years when we reissue it with recovered enc key, we need to
reissue the enc cert also - otherwise the recovered enc key cert could
be usable only for one year whereas the other certs would be usable for
three years.

Also - if we pile up all the previous enc certs to the card along with
the new cert, we run out of card space as well as introduce new problems
since the apps usually don't iterate though all the certs and end up
using the first cert available.

Saku.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BDm3R08163 for ietf-pkix-bks; Tue, 11 Mar 2003 05:48:03 -0800 (PST)
Received: from ratatosk.pdc.kth.se (ratatosk.pdc.kth.se [193.10.159.41]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BDm1308159 for <[e-mail]>; Tue, 11 Mar 2003 05:48:02 -0800 (PST)
X-Rcpt-To: unknown
X-Mail-From: [e-mail]
X-Client: dhcp-221-133.pdc.kth.se (130.237.221.133)
Received: from fiololle.pdc.kth.se (dhcp-221-133.pdc.kth.se [130.237.221.133]) (authenticated bits=0) by ratatosk.pdc.kth.se (8.12.8/8.12.8) with ESMTP id h2BDlhYI257910; Tue, 11 Mar 2003 14:47:44 +0100 (CET)
Reply-To: <[e-mail]>
From: "Olle Mulmo" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: Recommendation on subject matching rules needed..
Date: Tue, 11 Mar 2003 14:47:37 +0100
Message-ID: <001b01c2e7d4$c6e5b0e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I don't follow the logic here... If hash of issuer+serial is used, won't
the same issue happen upon revalidation of the key pair (that is, when
the original certificate expires)? Or am I more or less required to do a
key replacement operation (or changeover, or whatever the correct
terminology is) at that point?

/Olle

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Peter Gutmann
Sent: den 11 mars 2003 12:53
To: [e-mail]; [e-mail]
Subject: Re: Recommendation on subject matching rules needed..



"Vainikainen Saku EINT" <[e-mail]> writes:

>It seems that all the software we have tested (eg. MSoft, Utimaco)

Everyone, not just those two.

>tend to do somekind of binary comparison (hash values I suppose) 

issuerAndSerialNumber.

>The only problem is that the encryption key pair may have been
>recertified in between.

Therein lies the problem: Don't issue multiple certificates for the
same key.  If you "recover the archived encryption keypair" why not
recover the cert that goes with it?

(NB: Saying "We need to be able to issue a new encryption cert because
 we revoke the old one" isn't valid because the private key is still in
 use, so revoking the old cert is pointless).

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BDRKx07210 for ietf-pkix-bks; Tue, 11 Mar 2003 05:27:20 -0800 (PST)
Received: from vmmr9.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BDRH307206 for <[e-mail]>; Tue, 11 Mar 2003 05:27:17 -0800 (PST)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr9.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id PCE80908; Tue, 11 Mar 2003 08:27:17 -0500 (EST)
Received: from laptop-cpq.retrospekt.com (1Cust42.tnt1.stk3.swe.da.uu.net [213.116.224.42]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ABU07646; Tue, 11 Mar 2003 08:27:15 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 11 Mar 2003 14:26:36 +0100
To: [e-mail]
From: Stefan Santesson <[e-mail]>
Subject: QC Declaration
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>

The EU directive introduced a requirement on each CA, issuing QC (Qualified 
Certificates), to clearly indicate in these certificate that they are 
issued as QC.

ETSI implemented RFC 3039 in relation to the European electronic signature 
directive through their Technical Standard (TS 101862)

TS 101862 specified 2 alternative ways to declare a certificate as QC.

1) By inclusion of a QCStatements extension
2) By including a certificate policy identifying this property

Even though solution number 1) is far easier to handle by applications, 
since they don't need to recognize specific QC Policies, ETSI didn't make 
solution 1) mandatory or even consider making it critical, due to lack of 
confidence that clients would widely deploy this solution. ETSI needed to 
define a solution that could work even if no one choose to implement the 
new extensions provided by RFC 3039.

However, It is not feasible to keep clients updated over time with 
different QC policies and even those policies that are regarded 
standardized may be updated with change of OID as a result. It would be 
devastating if we can't update a QCP because that would force an OID update 
and that would render certificates useless because clients learned to 
recognize only the old OID. This would be to build in a new root 
certificate problem into the platforms.

My observations is that times have changed. I have seen clear indications 
that market players want, and even require for interoperability reasons, 
that use QCStatements solution is made mandatory and maybe even critical 
for QC.

Since both RFC 3039, and TS 101862 are up for revision, it is time to 
revisit this issue.

I have some questions and proposals:

- Is there any experiences of this issue outside of Europe. I.e. are there 
other legal systems that make use of the same declaration logic as the EU 
directive, where the RFC 3039 profile is used fully or partly as a solution 
to this issue?

- I would suggest that the QCStatement mechanism is ought to be a mandatory 
tool to communicate a Qualified Status. The question is:
    1) whether this will have enough implementation support to succeed?
    2) whether is best specified in RFC 3039 or in local profiles (such as 
TS 101862)?
    3) If there could be a clear context defined where criticality could be 
allowed or even required?

I would really like feedback from practical experiences from this issue, as 
well as constructive proposals.

/Stefan




/Stefan



_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone] 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BDOkg07167 for ietf-pkix-bks; Tue, 11 Mar 2003 05:24:46 -0800 (PST)
Received: from hubie.hubbardind.com (mail.hubbardsupply.com [65.245.100.65]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BDOi307163 for <[e-mail]>; Tue, 11 Mar 2003 05:24:44 -0800 (PST)
Received: by HUBIE.hubbardsupply.com with Internet Mail Service (5.5.2653.19) id <1JGDBPAQ>; Tue, 11 Mar 2003 08:24:45 -0500
Message-ID: <[e-mail]>
From: Roger Younglove <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>, Anders Rundgren <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: RE: Certificate Policies (was Re: Trivial PKI Question)
Date: Tue, 11 Mar 2003 08:24:44 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E7D1.944F47C0"
Sender: [e-mail]
Precedence: 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_01C2E7D1.944F47C0
Content-Type: text/plain

Steve
I respectfully disagree on one of your points. See comment interspersed.

Roger Younglove, CISSP, IAM
Principal Consultant
NetWorks Group
O. 810.225.4800 ex. 2245
M. 810.599.0879
E. [e-mail]
www.networksgroup.com
 

-----Original Message-----
From: Steve Hanna [mailto:[e-mail]] 
Sent: Monday, March 10, 2003 5:02 PM
To: Anders Rundgren
Cc: [e-mail]; [e-mail]
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)


>I've been meaning to correct a comment you made in an
>earlier message:

>Chris Gilbert wrote:
> > The two are likely to contain different certificatePolicies.

>You responded:

>> <CertificatePolicyRant>
>> It is interesting to note that CPSs are frequently mentioned in this
>>context
>> in spite of the fact that none of the major crypto-packages (Windows
>> and Java) offers any way to specify CPSs as a part of a CA trust
>>acceptance
>> process.  The reason for this is simple: Computers don't understand
>> legal matters and CPSs are deployment-wise anything but standardized.
>> Peter Gutman's term "Kitchen sink extensions" is a fair description of
>> the value of CPSs for practical purposes.  Do "SysAdmins" ever
>> bother about the CPS of their VeriSign web-server certificates?
>> My Thawt web-server cert does not even have a CPS extension and
>> I haven't missed it that much.  CPSs were designed by lawyers for
>> lawyers.  But lawyers do not run e-business systems, write application
>> software packages, or know how to handle a Java keystore.
>> </CertificatePolicyRant>

>You're confusing a Certification Practice Statement (CPS)
>with a Certificate Policy. A CPS is typically written by
>lawyers for lawyers and can't be evaluated by a machine.
That is not true a CPS is the technical "how it is done" to the CP.
The CP places requirements on the operation of the CA and RA, the CPS states
how those requirements are met. Written by technicians for technicians to
evaluate. 
>But that doesn't mean that the Certificate Policies
>extension isn't useful or supported. It's a completely
>different beast.
<snip>
Thanks,

Steve

------_=_NextPart_001_01C2E7D1.944F47C0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Certificate Policies (was Re: Trivial PKI Question)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Steve</FONT>
<BR><FONT SIZE=3D2>I respectfully disagree on one of your points. See =
comment interspersed.</FONT>
</P>

<P><FONT SIZE=3D2>Roger Younglove, CISSP, IAM</FONT>
<BR><FONT SIZE=3D2>Principal Consultant</FONT>
<BR><FONT SIZE=3D2>NetWorks Group</FONT>
<BR><FONT SIZE=3D2>O. 810.225.4800 ex. 2245</FONT>
<BR><FONT SIZE=3D2>M. 810.599.0879</FONT>
<BR><FONT SIZE=3D2>E. [e-mail]</FONT>
<BR><FONT SIZE=3D2>www.networksgroup.com</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Steve Hanna [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, March 10, 2003 5:02 PM</FONT>
<BR><FONT SIZE=3D2>To: Anders Rundgren</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Certificate Policies (was Re: Trivial =
PKI Question)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;I've been meaning to correct a comment you made =
in an</FONT>
<BR><FONT SIZE=3D2>&gt;earlier message:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Chris Gilbert wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The two are likely to contain different =
certificatePolicies.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;You responded:</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt; &lt;CertificatePolicyRant&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; It is interesting to note that CPSs are =
frequently mentioned in this &gt;&gt;context</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; in spite of the fact that none of the major =
crypto-packages (Windows</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; and Java) offers any way to specify CPSs as =
a part of a CA trust &gt;&gt;acceptance</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; process.&nbsp; The reason for this is =
simple: Computers don't understand</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; legal matters and CPSs are deployment-wise =
anything but standardized.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; Peter Gutman's term &quot;Kitchen sink =
extensions&quot; is a fair description of</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; the value of CPSs for practical =
purposes.&nbsp; Do &quot;SysAdmins&quot; ever</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; bother about the CPS of their VeriSign =
web-server certificates?</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; My Thawt web-server cert does not even have =
a CPS extension and</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I haven't missed it that much.&nbsp; CPSs =
were designed by lawyers for</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; lawyers.&nbsp; But lawyers do not run =
e-business systems, write application</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; software packages, or know how to handle a =
Java keystore.</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; &lt;/CertificatePolicyRant&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&gt;You're confusing a Certification Practice =
Statement (CPS)</FONT>
<BR><FONT SIZE=3D2>&gt;with a Certificate Policy. A CPS is typically =
written by</FONT>
<BR><FONT SIZE=3D2>&gt;lawyers for lawyers and can't be evaluated by a =
machine.</FONT>
<BR><FONT SIZE=3D2>That is not true a CPS is the technical &quot;how it =
is done&quot; to the CP.</FONT>
<BR><FONT SIZE=3D2>The CP places requirements on the operation of the =
CA and RA, the CPS states how those requirements are met. Written by =
technicians for technicians to evaluate. </FONT></P>

<P><FONT SIZE=3D2>&gt;But that doesn't mean that the Certificate =
Policies</FONT>
<BR><FONT SIZE=3D2>&gt;extension isn't useful or supported. It's a =
completely</FONT>
<BR><FONT SIZE=3D2>&gt;different beast.</FONT>
<BR><FONT SIZE=3D2>&lt;snip&gt;</FONT>
<BR><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Steve</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2E7D1.944F47C0--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BBrWX29023 for ietf-pkix-bks; Tue, 11 Mar 2003 03:53:32 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BBrU329019 for <[e-mail]>; Tue, 11 Mar 2003 03:53:30 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.8/8.12.8) with ESMTP id h2BBrIZF001369; Wed, 12 Mar 2003 00:53:18 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h2BBrJr04990; Wed, 12 Mar 2003 00:53:19 +1300
Date: Wed, 12 Mar 2003 00:53:19 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Recommendation on subject matching rules needed..
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Vainikainen Saku EINT" <[e-mail]> writes:

>It seems that all the software we have tested (eg. MSoft, Utimaco)

Everyone, not just those two.

>tend to do somekind of binary comparison (hash values I suppose) 

issuerAndSerialNumber.

>The only problem is that the encryption key pair may have been
>recertified in between.

Therein lies the problem: Don't issue multiple certificates for the
same key.  If you "recover the archived encryption keypair" why not
recover the cert that goes with it?

(NB: Saying "We need to be able to issue a new encryption cert because
 we revoke the old one" isn't valid because the private key is still in
 use, so revoking the old cert is pointless).

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2BAMhu22813 for ietf-pkix-bks; Tue, 11 Mar 2003 02:22:43 -0800 (PST)
Received: from smtp23.kolumbus.fi (smtp23.kolumbus.fi [193.229.0.81]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2BAMe322804 for <[e-mail]>; Tue, 11 Mar 2003 02:22:41 -0800 (PST)
Received: from dom1-cn1-hki.dom1.epnet (dom1-cn1-hki.dom1.epnet [172.21.176.70]) by smtp23.kolumbus.fi (8.12.8/8.12.4) with ESMTP id h2BAMO9b000261 for <[e-mail]>; Tue, 11 Mar 2003 12:22:28 +0200 (EET)
Received: from dom1-mb1-hki.dom1.epnet ([172.21.176.65]) by dom1-cn1-hki.dom1.epnet with Microsoft SMTPSVC(5.0.2195.5329); Tue, 11 Mar 2003 12:22:23 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Recommendation on subject matching rules needed..
Date: Tue, 11 Mar 2003 12:22:23 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Recommendation on subject matching rules needed..
Thread-Index: AcLdhmhLy6eLKJTCSRKM9fqZyAgCcgKMToxA
From: "Vainikainen Saku EINT" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 11 Mar 2003 10:22:23.0873 (UTC) FILETIME=[1B5ACF10:01C2E7B8]
X-MailScanner: Found to be clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2BAMf322808
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello all!
 
I'll layout the problem we have run into:
 
We have setup a PKI with encryption key archival and recovery 
features, and we are using a smartcard with three key pairs 
(auth, nonrep, enc). Our CA-hierarchy has two levels (root + 
subs). All subject certs and related CA certs are stored in 
the chip along with the key pairs.

The card personalisation process has two phases: 
prepersonalisation and personalisation phase. During 
prepersonalisation we generate keypairs, PINs and PKCS#15 
file structure to the card and in personalisation phase we 
certify the keys.

Now, when we create a new card to replace a lost/damaged/etc. 
card, we recover the archived encryption keypair and generate 
new auth and nonrep keypairs. Then we create new certs to all 
of the key pairs.

We are testing signing and encryption in S/MIME software and 
encryption in file/directory/volume encryption software, 
which all encrypt and decrypt nicely using our card. The 
problem emerges when trying to access encrypted data with a 
reissued card.

It seems that all the software we have tested (eg. MSoft, 
Utimaco) tend to do somekind of binary comparison (hash 
values I suppose) on the certificate used to encrypt the data 
(which is usually stored with the encrypted data) and on the 
certificate related to the encryption keypair being used to 
decrypt the data.

This of course works fine as long as the same certificate is 
used to encrypt and "decrypt" the data. The only problem is 
that the encryption key pair may have been recertified in between.

Certificate contains enough data to compare the subjects and 
the keys instead of the certificates. The comparison should - in 
my opinion - go more or less as follows:

Allow decrypt

1) if Subject Key Identifiers match
2) if Subject Unique Identifiers match
3) if Subjects + Subject Alt. Names match
4) if Issuer Key Identifiers match
5) if Issuer Unique Identifiers match
6) if Issuers match

Has anyone run into this problem as well ? Is this 
problem discussed in any existing papers (I haven't yet found 
any) ? I suppose this is going to be quite a problem if not 
addressed properly..

Saku Vainikainen
PKI-Specialist

Elisa Internet Oy
FINLAND


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2B8ScF06293 for ietf-pkix-bks; Tue, 11 Mar 2003 00:28:38 -0800 (PST)
Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B8SZ306275 for <[e-mail]>; Tue, 11 Mar 2003 00:28:35 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maila.telia.com (8.12.8/8.12.8) with SMTP id h2B8SOMD005727; Tue, 11 Mar 2003 09:28:24 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <007c01c2e7a6$b02d4760$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "'Steve Hanna'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <007f01c2e75f$4b93ec10$2d00a8c0@Chokhani>
Subject: Re: Certificate Policies (real-world vs. PKIX)
Date: Tue, 11 Mar 2003 09:17:42 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Guys,

I'm sorry that I mixed CP and CPS but I would like to extend
the scope of my previous "policy-rant" to include all legal
information inserted in EE-certificates whatever it is called
and whatever its purpose may be.

I look on this issue from a pragmatic point of view.

In case you are interested in how hands-on thinking works here is
some of this admittedly "low-brow" stuff.   The advantage with
"low-brow" solutions is that they are robust and can be understood
by people who do not have a degree in informatics.

Coping with different policies according to the real-world 
------------------------------------------------------------------

All commercial CAs of any significance have selected the same
method which is to have a separate CA for each "product" as run-time
checks of policies only complicates things for their customers (and is
in no way standardized). 

That is, Policy <==> CA.  No more, no less.

Coping with different policies according to PKIX (?)
------------------------------------------------------------

I hope that you at least acknowledge that in order to use [1] policy
extensions in a wider scope where numerous CAs are involved,
they must all adhere to the same definitions.  But, AFAIK it is
- very hard to standardize "information" & "content" in general
- likely to be magnitudes harder to standardize legal stuff

Question: If policy extensions only work within rather limited 
circles why use [1] such at all?  

1] "use" in this case refers to application SW reading policy 
extensions and "acting" differently depending on what they got.
Note: To put legal stuff in EE-certificates essentially only to please
lawyers or management is completely outside of this discussion.


In case you think I am wrong, I suggest you take on the completely 
death-defying task to make the UN create standard policy profiles.

OTOH I believe Kofi Annan has some more urgent real-world
business to cater for.  And "our" problem has de-facto already
been solved, although using another method than originally planned.

cheers,
Anders

----- Original Message ----- 
From: "Santosh Chokhani" <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>; "'Anders Rundgren'" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Tuesday, March 11, 2003 00:46
Subject: RE: Certificate Policies (was Re: Trivial PKI Question)


Steve:

CPS is not necessarily written by lawyers.  A CPS is a description of
procedures used to meet the CP requirements.  If one is following RFC 2527
framework, lawyers may write legal sections within Chapter 2.  Rest of the
CPS is better written by systems folks who know about the operating
procedures and security controls.

The CPS pointer is provided in the certificate in case the relying party
wants to review the controls used in generation and revocation of a
certificate.

I agree with you in terms of policy OIDs in the certificates.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Steve Hanna
Sent: Monday, March 10, 2003 5:02 PM
To: Anders Rundgren
Cc: [e-mail]; [e-mail]
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)



I've been meaning to correct a comment you made in an
earlier message:

Chris Gilbert wrote:
> > The two are likely to contain different certificatePolicies.

You responded:

> <CertificatePolicyRant>
> It is interesting to note that CPSs are frequently mentioned in this 
> context in spite of the fact that none of the major crypto-packages 
> (Windows and Java) offers any way to specify CPSs as a part of a CA 
> trust acceptance process.  The reason for this is simple: Computers 
> don't understand legal matters and CPSs are deployment-wise anything 
> but standardized. Peter Gutman's term "Kitchen sink extensions" is a 
> fair description of the value of CPSs for practical purposes.  Do 
> "SysAdmins" ever bother about the CPS of their VeriSign web-server 
> certificates? My Thawt web-server cert does not even have a CPS 
> extension and I haven't missed it that much.  CPSs were designed by 
> lawyers for lawyers.  But lawyers do not run e-business systems, write 
> application software packages, or know how to handle a Java keystore. 
> </CertificatePolicyRant>

You're confusing a Certification Practice Statement (CPS)
with a Certificate Policy. A CPS is typically written by lawyers for lawyers
and can't be evaluated by a machine. But that doesn't mean that the
Certificate Policies extension isn't useful or supported. It's a completely
different beast.

The Certificate Policies extension allows a CA to include
OIDs in a PKC indicating the policy (or policies) under
which the PKC was issued. This is especially important when there's more
than one certificate policy in use within a group of CAs (high assurance,
low assurance, or whatever). The relying party needs to distinguish which
certificate policy (or policies) applies to each certificate.

J2SE 1.4 and later allows applications to specify which certificate policy
OIDs are acceptable when they request validation of a certification path.
And we handle policy mapping properly. I don't know how many applications
use these features, but they are provided.

As for whether it's useful or important to include a CPS Pointer in a
certificate, I don't know. I'll leave that up to the lawyers.

Thanks,

Steve






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2B1ucl12095 for ietf-pkix-bks; Mon, 10 Mar 2003 17:56:38 -0800 (PST)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B1ua312091 for <[e-mail]>; Mon, 10 Mar 2003 17:56:36 -0800 (PST)
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Mon, 10 Mar 2003 17:56:33 -0800
Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 Mar 2003 17:56:27 -0800
Received: from RED-IMC-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 10 Mar 2003 17:56:29 -0800
Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 10 Mar 2003 17:56:31 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.82]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3765.0); Mon, 10 Mar 2003 17:56:18 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: basicConstraints with CA=False in EE certs
Date: Mon, 10 Mar 2003 17:56:31 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: basicConstraints with CA=False in EE certs
Thread-Index: AcLnayoBwrAko+S4QoSorLNz7/6zzAAAMTIg
From: "Ryan M. Hurst" <[e-mail]>
To: "Jean-Marc Desperrier" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 11 Mar 2003 01:56:18.0902 (UTC) FILETIME=[686BEF60:01C2E771]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C2E771.6FD7A695"

------_=_NextPart_001_01C2E771.6FD7A695
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Although MSRC02-050 makes CryptoAPI conformant to the basicConstraints
and keyCertSign elements of the RFC to accommodate for this defect in
down-level clients that have not applied the fix you can do either:

1.    make sure that the issuing CA uses path length value in the
issuing BC

2.    make sure your end-entity certificate contains a basic constraints
ca=3Dfalse

=20

For more information on this see:
http://www.microsoft.com/technet/treeview/default.asp?url=3D/technet/secu=
r
ity/bulletin/MS02-050.asp

=20

Hope this helps,

=20

Ryan M. Hurst

Program Manager

Windows Security

=20

=20

-----Original Message-----
From: Jean-Marc Desperrier [mailto:[e-mail]]=20
Sent: Monday, March 10, 2003 3:34 PM
To: [e-mail]
Cc: [e-mail]
Subject: Re: basicConstraints with CA=3DFalse in EE certs

=20

=20

[e-mail] wrote:

=20

>To complicate matters Microsoft Security Bulletin MS02-050 describes

>an exploitation whereby unpatched CSPs do not process

>basicConstraints at all leaving them vulnerable to ID spoofing attacks

>( CAN-2002-0862 ) . This problem is fixed by a patch which enforces

>a check on basicConstraints.

>

BTW if ever you were not fully satisfied by the solution given by Peter,


you can create certificate that are conformant to RFC2459 (no=20

basicConstraint) and will be protected against this problem by making=20

sure the Basic Constraint of the CA that emits them as a path length=20

restriction of 0 (final CA, can only emit EE certs).

=20

Microsoft fails to give the kind of really detailled explanation about=20

the problem that would help implementers, but tests show that all=20

version of the CAPI/application that will take into account the =
CA=3Dfalse


basicConstraint, will also take into account the path length restriction


of 0.

=20

=20


------_=_NextPart_001_01C2E771.6FD7A695
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 10 (filtered)">

<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 77.95pt 1.0in 77.95pt;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Although MSRC02-050 makes CryptoAPI conformant to the =
basicConstraints
and keyCertSign elements of the RFC to accommodate for this defect in =
down-level
clients that have not applied the fix you can do =
either:</span></font></p>

<p class=3DMsoPlainText =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D2
face=3D"Courier New"><span style=3D'font-size:10.0pt'>1.<font size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;
</span></font></span></font>make sure that the issuing CA uses path =
length
value in the issuing BC</p>

<p class=3DMsoPlainText =
style=3D'margin-left:.5in;text-indent:-.25in'><font size=3D2
face=3D"Courier New"><span style=3D'font-size:10.0pt'>2.<font size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;
</span></font></span></font>make sure your end-entity certificate =
contains a basic
constraints ca=3Dfalse</p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>For more information on this see: <a
href=3D"http://www.microsoft.com/technet/treeview/default.asp?url=3D/tech=
net/security/bulletin/MS02-050.asp">http://www.microsoft.com/technet/tree=
view/default.asp?url=3D/technet/security/bulletin/MS02-050.asp</a></span>=
</font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Hope this helps,</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Ryan M. Hurst</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Program Manager</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Windows Security</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>-----Original Message-----<br>
From: Jean-Marc Desperrier [mailto:[e-mail]] <br>
Sent: Monday, March 10, 2003 3:34 PM<br>
To: [e-mail]<br>
Cc: [e-mail]<br>
Subject: Re: basicConstraints with CA=3DFalse in EE =
certs</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>[e-mail] wrote:</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt;To complicate matters Microsoft Security Bulletin MS02-050
describes</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt;an exploitation whereby unpatched CSPs do not =
process</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt;basicConstraints at all leaving them vulnerable to ID =
spoofing
attacks</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt;( CAN-2002-0862 ) . This problem is fixed by a patch which =
enforces</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt;a check on basicConstraints.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&gt;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>BTW if ever you were not fully satisfied by the solution given =
by
Peter, </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>you can create certificate that are conformant to RFC2459 (no =
</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>basicConstraint) and will be protected against this problem by =
making </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>sure the Basic Constraint of the CA that emits them as a path =
length </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>restriction of 0 (final CA, can only emit EE =
certs).</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Microsoft fails to give the kind of really detailled explanation =
about </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>the problem that would help implementers, but tests show that =
all </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>version of the CAPI/application that will take into account the =
CA=3Dfalse
</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>basicConstraint, will also take into account the path length
restriction </span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>of 0.</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;</span></font></p>

</div>

</body>

</html>
=00
------_=_NextPart_001_01C2E771.6FD7A695--

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



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2B1SJF11312 for ietf-pkix-bks; Mon, 10 Mar 2003 17:28:19 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2B1SF311305 for <[e-mail]>; Mon, 10 Mar 2003 17:28:16 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.8/8.12.8) with ESMTP id h2B1SDZF022006; Tue, 11 Mar 2003 14:28:13 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h2B1SAg02446; Tue, 11 Mar 2003 14:28:10 +1300
Date: Tue, 11 Mar 2003 14:28:10 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: basicConstraints with CA=False in EE certs
Sender: [e-mail]
Precedence: 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 Polk <[e-mail]> writes:

>As Peter implies, since the certificates include the extension but omit the
>boolean "which is the right thing to do", they are compliant with both RFC
>3280 and X.690.  No conflict here!

It's actually incompatible with RFC 2459, and only marginally compatible with
3280:

RFC 2459:

  This extension SHOULD NOT appear in end entity certificates.

RFC 3280:

  This extension MAY appear as a critical or non-critical extension in end
  entity certificates.

The 2459 text excludes it, and the 3280 text makes it highly optional, when in
fact it's "this had better be there or else" ("MUST", I think, would be the
accepted term).  At the current rate of RFC progression, I calculate that
it'll have made it up to "MUST" in [lunga pausa] 2008.

Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ANkWg08482 for ietf-pkix-bks; Mon, 10 Mar 2003 15:46:32 -0800 (PST)
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ANkV308478 for <[e-mail]>; Mon, 10 Mar 2003 15:46:31 -0800 (PST)
Received: from chokhani (117.washington-16rh15rt.dc.dial-access.att.net[12.91.134.117]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003031023462711300mjdphe>; Mon, 10 Mar 2003 23:46:27 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>, "'Anders Rundgren'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Certificate Policies (was Re: Trivial PKI Question)
Date: Mon, 10 Mar 2003 18:46:38 -0500
Message-ID: <007f01c2e75f$4b93ec10$2d00a8c0@Chokhani>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h2ANkV308479
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve:

CPS is not necessarily written by lawyers.  A CPS is a description of
procedures used to meet the CP requirements.  If one is following RFC 2527
framework, lawyers may write legal sections within Chapter 2.  Rest of the
CPS is better written by systems folks who know about the operating
procedures and security controls.

The CPS pointer is provided in the certificate in case the relying party
wants to review the controls used in generation and revocation of a
certificate.

I agree with you in terms of policy OIDs in the certificates.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Steve Hanna
Sent: Monday, March 10, 2003 5:02 PM
To: Anders Rundgren
Cc: [e-mail]; [e-mail]
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)



I've been meaning to correct a comment you made in an
earlier message:

Chris Gilbert wrote:
> > The two are likely to contain different certificatePolicies.

You responded:

> <CertificatePolicyRant>
> It is interesting to note that CPSs are frequently mentioned in this 
> context in spite of the fact that none of the major crypto-packages 
> (Windows and Java) offers any way to specify CPSs as a part of a CA 
> trust acceptance process.  The reason for this is simple: Computers 
> don't understand legal matters and CPSs are deployment-wise anything 
> but standardized. Peter Gutman's term "Kitchen sink extensions" is a 
> fair description of the value of CPSs for practical purposes.  Do 
> "SysAdmins" ever bother about the CPS of their VeriSign web-server 
> certificates? My Thawt web-server cert does not even have a CPS 
> extension and I haven't missed it that much.  CPSs were designed by 
> lawyers for lawyers.  But lawyers do not run e-business systems, write 
> application software packages, or know how to handle a Java keystore. 
> </CertificatePolicyRant>

You're confusing a Certification Practice Statement (CPS)
with a Certificate Policy. A CPS is typically written by lawyers for lawyers
and can't be evaluated by a machine. But that doesn't mean that the
Certificate Policies extension isn't useful or supported. It's a completely
different beast.

The Certificate Policies extension allows a CA to include
OIDs in a PKC indicating the policy (or policies) under
which the PKC was issued. This is especially important when there's more
than one certificate policy in use within a group of CAs (high assurance,
low assurance, or whatever). The relying party needs to distinguish which
certificate policy (or policies) applies to each certificate.

J2SE 1.4 and later allows applications to specify which certificate policy
OIDs are acceptable when they request validation of a certification path.
And we handle policy mapping properly. I don't know how many applications
use these features, but they are provided.

As for whether it's useful or important to include a CPS Pointer in a
certificate, I don't know. I'll leave that up to the lawyers.

Thanks,

Steve



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ANWRE08130 for ietf-pkix-bks; Mon, 10 Mar 2003 15:32:27 -0800 (PST)
Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.28]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ANWQ308126 for <[e-mail]>; Mon, 10 Mar 2003 15:32:26 -0800 (PST)
Received: from free.fr (171.111-30-212.9massy1-1-ro-as-i4-1.9tel.net [212.30.111.171]) by huva.hittite.isp.9tel.net (Postfix) with ESMTP id 26B4E9BB43; Tue, 11 Mar 2003 00:32:47 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 11 Mar 2003 00:34:09 +0100
From: Jean-Marc Desperrier <[e-mail]>
Organization: totalement desorganise
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030129
X-Accept-Language: en-us, en, fr, fr-fr, ja
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail]
Subject: Re: basicConstraints with CA=False in EE certs
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] wrote:

>To complicate matters Microsoft Security Bulletin MS02-050 describes
>an exploitation whereby unpatched CSPs do not process
>basicConstraints at all leaving them vulnerable to ID spoofing attacks
>( CAN-2002-0862 ) . This problem is fixed by a patch which enforces
>a check on basicConstraints.
>
BTW if ever you were not fully satisfied by the solution given by Peter, 
you can create certificate that are conformant to RFC2459 (no 
basicConstraint) and will be protected against this problem by making 
sure the Basic Constraint of the CA that emits them as a path length 
restriction of 0 (final CA, can only emit EE certs).

Microsoft fails to give the kind of really detailled explanation about 
the problem that would help implementers, but tests show that all 
version of the CAPI/application that will take into account the CA=false 
basicConstraint, will also take into account the path length restriction 
of 0.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AM4ED03542 for ietf-pkix-bks; Mon, 10 Mar 2003 14:04:14 -0800 (PST)
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AM4D303538 for <[e-mail]>; Mon, 10 Mar 2003 14:04:13 -0800 (PST)
Received: from sydney.East.Sun.COM ([129.148.9.16]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17233; Mon, 10 Mar 2003 14:04:10 -0800 (PST)
Received: from sun.com (dhcp-ubur02-75-167 [129.148.75.167]) by sydney.East.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id h2AM49016451; Mon, 10 Mar 2003 17:04:10 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 10 Mar 2003 17:01:48 -0500
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Anders Rundgren <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Certificate Policies (was Re: Trivial PKI Question)
References: <[e-mail]> <00b501c2e30d$d9d28e10$0500a8c0@arport>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I've been meaning to correct a comment you made in an
earlier message:

Chris Gilbert wrote:
> > The two are likely to contain different certificatePolicies.

You responded:

> <CertificatePolicyRant>
> It is interesting to note that CPSs are frequently mentioned in this context
> in spite of the fact that none of the major crypto-packages (Windows
> and Java) offers any way to specify CPSs as a part of a CA trust acceptance
> process.  The reason for this is simple: Computers don't understand
> legal matters and CPSs are deployment-wise anything but standardized.
> Peter Gutman's term "Kitchen sink extensions" is a fair description of
> the value of CPSs for practical purposes.  Do "SysAdmins" ever
> bother about the CPS of their VeriSign web-server certificates?
> My Thawt web-server cert does not even have a CPS extension and
> I haven't missed it that much.  CPSs were designed by lawyers for
> lawyers.  But lawyers do not run e-business systems, write application
> software packages, or know how to handle a Java keystore.
> </CertificatePolicyRant>

You're confusing a Certification Practice Statement (CPS)
with a Certificate Policy. A CPS is typically written by
lawyers for lawyers and can't be evaluated by a machine.
But that doesn't mean that the Certificate Policies
extension isn't useful or supported. It's a completely
different beast.

The Certificate Policies extension allows a CA to include
OIDs in a PKC indicating the policy (or policies) under
which the PKC was issued. This is especially important when
there's more than one certificate policy in use within a
group of CAs (high assurance, low assurance, or whatever).
The relying party needs to distinguish which certificate
policy (or policies) applies to each certificate.

J2SE 1.4 and later allows applications to specify which
certificate policy OIDs are acceptable when they request
validation of a certification path. And we handle policy
mapping properly. I don't know how many applications use
these features, but they are provided.

As for whether it's useful or important to include a CPS Pointer
in a certificate, I don't know. I'll leave that up to the
lawyers.

Thanks,

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ALRI002186 for ietf-pkix-bks; Mon, 10 Mar 2003 13:27:18 -0800 (PST)
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ALRF302182 for <[e-mail]>; Mon, 10 Mar 2003 13:27:16 -0800 (PST)
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h2ALQkCa004688 for <[e-mail]>; Mon, 10 Mar 2003 16:26:47 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 10 Mar 2003 16:28:49 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Re: Agenda Requests for PKIX (seriously)
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have sent out follow-up messages (e.g., "how much time do you need for 
your presentation?") to everyone whose agenda request did NOT get buried in 
my mailbox.

That is, if you sent in a request but haven't seen a follow-up from me, you 
should re-send your agenda request.

Thanks,

Tim Polk

At 02:40 PM 3/10/2003 -0500, Tim Polk wrote:


>Folks,
>
>Apparently, I need to start on the agenda far earlier for the next 
>meeting.  As several have noticed, time is running late and I haven't put 
>the agenda together yet.  From other messages on this topic, I see that 
>the lack of an agenda is clearly wasting the WG's time and energy.  Since 
>we have other important things to do, I will rectify that ASAP.
>
>I have had a number of requests but need to get the complete list of 
>requests before I finalize the agenda.  If you *haven't* already sent me 
>mail, please drop me a line by COB Tuesday (5PM Eastern-US).  I will post 
>the agenda Tuesday night.
>
>Thanks,
>
>Tim Polk



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AJfFR24535 for ietf-pkix-bks; Mon, 10 Mar 2003 11:41:15 -0800 (PST)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AJfC324531 for <[e-mail]>; Mon, 10 Mar 2003 11:41:12 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maild.telia.com (8.12.8/8.12.8) with SMTP id h2AJfDVK027410 for <[e-mail]>; Mon, 10 Mar 2003 20:41:13 +0100 (CET)
X-Original-Recipient: <[e-mail]>
Message-ID: <00cf01c2e73b$83bec700$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Non-constructive PKIX Input
Date: Mon, 10 Mar 2003 20:30:31 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve wrote:

"If not, then your comment is just sniping, offered by someone
who has never contributed constructively to any PKIX effort."

Some of these non-constructive contributions include:

######## RFC3039 ########

After long and hard debates, I persuaded the authors to honor the idea
that QC CAs should not be allowed reuse DNs, as reuses would lead
to a considerably reduced credibility for the QC-concept as a whole. 


######## Permanent Identifier Extension ########

Now close to becoming a 3-year (!) task.
I have given the authors constructive input on how to align this
effort with existing practices in a way that also opens the door to a
higher-level PKI structure.

Here something went very wrong, and I still don't understand why. 
I always wanted and still do want to reconcile my efforts with their
stuff in order to create a "killer" RFC.  However, *they* don't.

Actually the only thing missing is a clear statement if RFC3039 is
correct regarding its description of "SerialNumber" [1], and thus
*can* be used as foundation for other standards, or if it incorrectly
passed the RFC-process due to an omission.

   1] It MAY contain a number or code assigned by the CA or an
       identifier assigned by a government or civil authority


######## Warranty Extension ########

My *thorough* analysis of the warranty-extension, which revealed
that the software support needed is of a magnitude and complexity that
likely will thwart any usage of it, still remains unchallenged.  

That the analysis is unchallenged is either due to the fact that no one
cares about the warranty-extension, or that the analysis is correct.

Whichever is true, it in a *constructive* way leads to the conclusion
that the warranty-extension draft should either be retargetted or be
abandoned.  I have proposed an effort to retarget the draft both
technically and scope-wise.  I'm not sure if this is possible though. 


####### Attribute Certificates and related drafts #######

OK, I admit that I have been a bit "hard" in my critique of these items.
It seems that the "market" has in its more "subtle" ways done the same.
The rationale behind this is though very simple:  An attribute-
certificate is nothing but a set of attributes optionally containing
a link to an entity associated with these attributes.  To an virtually
endless list of variants one should also add purchase orders, air-line
tickets, as well as more obscure things like authorization objects. 
A problem that the AC-developers did not take in consideration is that
real-world "AC"-designers are mainly concerned about content and
associated processes.  I.e. the "format" is definitely secondary.
To standardize "content" howver, is a task for the communities that
are supposed to deal with it, and not the IETF.  As these "communities"
all have different requirements, "legacy" designs, and technical
competences,  "AC"-formats are simply not possible to standardize at this
stage, maybe never.  A signed PDF-file may actually be want some need!

If one were to  write a sophisticated "AC"-based user-administration
system, RFC3281 would very unlikely be the choice, given XML's
extremely strong position for *new* designs.  SAML et. al. have
also enabled entirely new ways to build access systems, futher
limiting the viabiliy of X.509 ACs.

An X.509.v3 PKC OTOH, is (at its best), just a link between a key
and a name,  making it "universal", and was therefore an excellent
target for *successful* standardization in all possible aspects.


####### Subject Identification Method #######

An exhaustive analysis were performed, resulting in an advice to use
the already available OASIS SAML system (which I BTW also have
contributed to) as it offers a higher level of user-convenience and
does not rely on rather "special" client-based stuff.  This scheme also
lends itself to other novel uses of PKI and browser-technology.  I
therefore suggested dropping SIM as a PKIX task.


####### Naive statements and questions #######

The "Trivial PKI Question" was characterized as being naive at best.
I think that some people have some problems with "my approach" which
is to get as much feedback as possible.  By not applying a too pompous
tone, you get a lot!   In this case I put this question in various foras and
got results that were all over the map.   I noted that the answers
gotten from the PKIX-list were the least useful which confirms my view
that there must be pretty few active SW engineers following this list.


#### ### Plug-and-play PKI  #######

On your request (as you don't like my "colorful" PPTs), I indeed
created a PnP draft embryo:   
http://www.x-obi.com/OBI400/draft-rundgren-pkix-pnppki4ws-00.pdf
You and Tim have had that in your "custody" for 9 weeks but I still
have not gotten a formal decision or any real feedback.   Indirectly 
you said in your last message that efforts "competing" with existing
drafts will not be supported.  This reveals that you have not read the
paper thoroughly as it also addresses some entirely different issues
than the permanent identifier draft does.   I maintain that the only 
way one can ever understand the motives behind a sophisticated 
scheme like PnP, is to perform something like a "virtual design"
with and without the support of the scheme in question.  This is
what I did with the warranty extension and unfortunately it turned
out rather bad.


####### Server-based Legal-entity-only Signatures #######

I believe I'm partly responsible for this becoming a hot EU topic.
Many countries including Sweden now support this more or less
officially, in spite of being an "unthinkable" solution just a few
years ago.    Although not exactly an IETF-item, this will have a
profound effect on PKI deployment and probably even affect some
PKI-related standards as well.   That VISA dropped SET and
now push 3D Secure, is another sign of that "old truths" at least
in the realm of PKI, seem not to be that "true" anymore.

A one-page related document:
http://www.x-obi.com/OBI400/b2bsign.pdf

A long related document:
http://www.x-obi.com/OBI400/pki4org.pdf




####### Dissing Policy Extensions #######

As it is infeasible to standardize information of the "fluffy"
kind that Policy Extensions constitute, I maintain that usage of
these extensions have no purpose from an application software
point of view.  No existing COTS products make any use of PEs
and probably never will. Constructive input? Yes, for those who
accidently believed that PEs actually fill an important mission.  
For a CA to have a CP is surely important but that is not the
same as stuffing it in a certificate as an OID or so.


####### Dissing Directories #######

Is now an almost "accepted" activity within the PKI community.


Anders R




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AJcrR24405 for ietf-pkix-bks; Mon, 10 Mar 2003 11:38:53 -0800 (PST)
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AJco324398 for <[e-mail]>; Mon, 10 Mar 2003 11:38:50 -0800 (PST)
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h2AJceCa009776 for <[e-mail]>; Mon, 10 Mar 2003 14:38:40 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 10 Mar 2003 14:40:43 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Agenda Requests for PKIX (seriously)
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>

Folks,

Apparently, I need to start on the agenda far earlier for the next 
meeting.  As several have noticed, time is running late and I haven't put 
the agenda together yet.  From other messages on this topic, I see that the 
lack of an agenda is clearly wasting the WG's time and energy.  Since we 
have other important things to do, I will rectify that ASAP.

I have had a number of requests but need to get the complete list of 
requests before I finalize the agenda.  If you *haven't* already sent me 
mail, please drop me a line by COB Tuesday (5PM Eastern-US).  I will post 
the agenda Tuesday night.

Thanks,

Tim Polk



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AIOP620164 for ietf-pkix-bks; Mon, 10 Mar 2003 10:24:25 -0800 (PST)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AIOO320160 for <[e-mail]>; Mon, 10 Mar 2003 10:24:24 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h2AIOK5w009104; Mon, 10 Mar 2003 13:24:20 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100309ba9285f44939@[128.89.88.34]>
In-Reply-To: <00b301c2e72c$4bfe4ed0$020aff0a@tsg1>
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]> <008801c2e5b1$fd603cf0$0500a8c0@arport> <a05200f25ba919f2aa947@[10.10.10.2]> <002c01c2e6cc$80bd4640$0500a8c0@arport> <p0521050cba926acf7349@[63.202.92.157]> <00b301c2e72c$4bfe4ed0$020aff0a@tsg1>
Date: Mon, 10 Mar 2003 13:21:34 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: The IETF 56 - PKIX Agenda
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Todd,

We've had this discussion before, but for the edification of 
newcomers to the list, I guess it must be revisited:

>Paul - as someone else that has had run-ins with the management of
>PKIX  - what Anders commentary was relevant to was the
>operational integrity of this WG and the people that either impugn that or
>make it real.

As I noted in my response to Anders, people who do not contribute 
constructively to WG activities are in a poor position to complain.

>The issue is not Steve, the issue is that there is no change in the
>management of this WG and has been none for so long that claims that the
>existing chairs are squatters are getting harder and harder to refute. In
>fact without change through the management of the WG, there will come a time
>when even the most stupefied idiot will see this as well and at that point
>the rest of the WG starts to look like a bunch of skinned fish.

Over time you have been of two minds o this topic. Sometime you state 
that it's not about me, but at other times you have made it clear 
that I, as an individual, am the target of your complaints. In any 
case, the IESG is empowered to make the determination of when there 
isn a need to change WG leadership. Involuntary changes have taken 
place in the past, but there have also been examples of one person 
chairing a WG for a very long time.

>This WG like all other standards body WG's must espouse itself to the higher
>vision of fair play, not in getting a select few protocols to elevated
>status and that is the net-net of it.

All standards bodies with which I am familiar make choices about what 
work they pursue and which proposals they endorse when there are 
competing proposals, Your notion of fair play, as articulated 
recently on the POISED mailing list, calls for the IETF to publish 
anything that it put before it, which is not at all consistent with 
the operation of other standards bodies. If a standards body fails to 
make architectural choices, the result is a proliferation of 
standards that fail to ensure interoperability, and that is the 
opposite of what a standards body should do.

>As to intentional or unintentional flames, they happen and that's life.

True

>As to what to do about the problem - I would propose that unless PKIX can
>find new people willing to stand as its chair that it has become a
>"permanent edifice", and that it needs to be shutdown and its projects
>shuttled to other WG's for completion.

The IESG makes the determination of when a WG should cease operation. 
You have tried to persuade them to change the leadership of this WG 
in the past, to no avail, and then  you tried to persuade folks to 
change the operating procedures of the IETF, having failed in your 
original quest.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AIGgb19959 for ietf-pkix-bks; Mon, 10 Mar 2003 10:16:42 -0800 (PST)
Received: from maild.telia.com (maild.telia.com [194.22.190.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AIGf319955 for <[e-mail]>; Mon, 10 Mar 2003 10:16:41 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maild.telia.com (8.12.8/8.12.8) with SMTP id h2AIGfVK012930; Mon, 10 Mar 2003 19:16:42 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <004401c2e72f$b4c03610$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Stefan Santesson" <[e-mail]>
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]> <[e-mail]> <[e-mail]>
Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
Date: Mon, 10 Mar 2003 19:06:00 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: 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 conclusion is that in your opinion there is no problem with
>RFC 3039 with regard to this.

>Personally I have had a hard time see the problem with this.
> This was sorted out many years ago and X.520 as even updated to
>clarify that it was appropriate to accommodate this use, i.e. assigning
>identifiers to humans. (X.520: "The Serial Number attribute
>type specifies an identifier, the serial number of an object. ")

I know this but based on private mails the PI advocates still
think this a bad use of serialNumber.   As you probably don't care
about PI you have nothing to worry about.

In case you DO care about PI, please show me how YOU would
apply PI to the following RFC3039 compliant "Swedish" certificate:

DN: CN=John Doe, serialNumber=676767666767, C=SE

Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AHgcn18751 for ietf-pkix-bks; Mon, 10 Mar 2003 09:42:38 -0800 (PST)
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AHga318745; Mon, 10 Mar 2003 09:42:37 -0800 (PST)
Received: from tsg1 (unknown[12.81.121.177]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003031017422411100m1m1ee>; Mon, 10 Mar 2003 17:42:25 +0000
Message-ID: <00b301c2e72c$4bfe4ed0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>, "Paul Hoffman / IMC" <[e-mail]>
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]> <008801c2e5b1$fd603cf0$0500a8c0@arport> <a05200f25ba919f2aa947@[10.10.10.2]> <002c01c2e6cc$80bd4640$0500a8c0@arport> <p0521050cba926acf7349@[63.202.92.157]>
Subject: Re: The IETF 56 - PKIX Agenda
Date: Mon, 10 Mar 2003 09:41:23 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul - as someone else that has had run-ins with the management of
PKIX  - what Anders commentary was relevant to was the
operational integrity of this WG and the people that either impugn that or
make it real.

The issue is not Steve, the issue is that there is no change in the
management of this WG and has been none for so long that claims that the
existing chairs are squatters are getting harder and harder to refute. In
fact without change through the management of the WG, there will come a time
when even the most stupefied idiot will see this as well and at that point
the rest of the WG starts to look like a bunch of skinned fish.

This WG like all other standards body WG's must espouse itself to the higher
vision of fair play, not in getting a select few protocols to elevated
status and that is the net-net of it.

As to intentional or unintentional flames, they happen and that's life.

As to what to do about the problem - I would propose that unless PKIX can
find new people willing to stand as its chair that it has become a
"permanent edifice", and that it needs to be shutdown and its projects
shuttled to other WG's for completion.

Todd

----- Original Message -----
From: "Paul Hoffman / IMC" <[e-mail]>
To: <[e-mail]>
Sent: Monday, March 10, 2003 8:19 AM
Subject: Re: The IETF 56 - PKIX Agenda


>
> At 7:15 AM +0100 3/10/03, Anders Rundgren wrote:
> >You are absolutely right, this is childish, but you also do not have
> >the full background to this long-time feud.
>
> The background doesn't matter. If I find yourself about to write
> something childish, and I am an adult, it is my responsibility to not
> finish it.
>
> >I honestly regret the personal attack on Steve & Co which actually
> >was NOT even meant to reach a larger audience (you extended the
> >reply-list and I did not notice that).
>
> It is not clear that sending personal attacks to individuals is that
> much better than sending them to the whole mailing list. In the
> latter case, it wastes more people's time, but in the former case, it
> causes the person being attacked to wonder why he/she should be doing
> this.
>
> If we want effective official and unofficial leadership in the WG, we
> shouldn't be sending personal attacks to individuals or to the whole
> WG.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AGLe912385 for ietf-pkix-bks; Mon, 10 Mar 2003 08:21:40 -0800 (PST)
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AGLa312378 for <[e-mail]>; Mon, 10 Mar 2003 08:21:37 -0800 (PST)
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h2AGL0Ca025480; Mon, 10 Mar 2003 11:21:02 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 10 Mar 2003 11:23:02 -0500
To: [e-mail] (Peter Gutmann), [e-mail], [e-mail]
From: Tim Polk <[e-mail]>
Subject: Re: basicConstraints with CA=False in EE certs
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris,

One final point to add to Peter's excellent writeup.  As Peter implies, 
since the certificates include the extension but omit the boolean "which is 
the right thing to do", they are compliant with both RFC 3280 and 
X.690.  No conflict here!

Thanks,

Tim Polk

At 04:56 AM 3/7/2003 +1300, Peter Gutmann wrote:

>[e-mail] writes:
>
> >ITU-T Rec. X.690 specifies that the default values for an extension should
> >not be encoded. Thus, in EE certs where basicConstraints with CA=False 
> is the
> >default, the extension should be omitted at encoding.
>
>You don't omit the extension, you omit the BOOLEAN containing the CA flag,
>resulting in a zero-length SEQUENCE, viz:
>
>  543 30    9:         SEQUENCE {
>  545 06    3:           OBJECT IDENTIFIER basicConstraints (2 5 29 19)
>  550 04    2:           OCTET STRING, encapsulates {
>  552 30    0:               SEQUENCE {}
>             :               }
>             :           }
>
> >It is currently common practice, however, for CAs (some, not all) to encode
> >CA=False in the EE cert.
>
>They encode a zero-length SEQUENCE, which is the right thing to do.  From the
>style guide:
>
>   PKIX requires that end entity certificates not have a basicConstraints
>   extension, which leaves the handling of the CA status of the certificate to
>   chance.  Several popular applications treat these certificates as CA
>   certificates for backwards-compatibility with X.509v1 CA certificates which
>   didn't include basicConstraints, but in practice it's not really 
> possible to
>   determine how these certificates will be treated.  Because of this, 
> it's not
>   possible to issue a PKIX-compliant end entity certificate and know how 
> it'll
>   be treated once it's in circulation.
>
>   The theory behind this usage is that applications should know that a v3
>   certificate without basicConstraints defaults to being a non-CA 
> certificate,
>   however (even assuming that applications implemented this), if
>   basicConstraints would have been the only extension in the certificate then
>   defaulting to leaving it out would make it a v1 certificate as required by
>   PKIX, so the v1 rules would apply.  To get the required processing, the
>   certificate would have to be marked as v3 even though it's v1 (and the
>   application processing it would have to know about the expected behaviour).
>   In any case it's a somewhat peculiar use of the certificate version number
>   field to convey certificate constraint information.
>
>   One use for this feature is that it may be used as a cryptographically 
> strong
>   random number generator.  For each crypto key an application would 
> issue 128
>   basicConstraint-less certificates, hand them out to different
>   implementations/users, and use their CA/non-CA interpretation as one 
> bit of a
>   session key.  This should yield close to 128 bits of pure entropy in each
>   key.
>
> >So, is anyone dealing with this conflict ? ie, at some point in the near
> >future are we going to get an update to X.690 which says you *should* encode
> >basicConstraints with CA=False in EE certs or are ITU waiting for i)
> >Microsoft to fix their CSP and ii) V*risign to reissue all of their EE certs
> >which contain this encoding ?
>
>There are certain things in standards where the implementors know that you
>ignore the standard and do what works instead.  This is one of them (the Style
>Guide exists to document this implementation folklore, although it really
>needs updating).
>
> >Your thoughts are appreciated. The most up-to-date status of this problem
> >would be of use to us.
>
>See above.  That's been in the Style Guide for, I guess, about 5 years or so,
>things haven't changed since then (I doubt the standards are going to change
>to reflect reality, and reality certainly isn't going to change to reflect the
>standards).
>
>Peter.



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AGK5112343 for ietf-pkix-bks; Mon, 10 Mar 2003 08:20:05 -0800 (PST)
Received: from [63.202.92.157] (adsl-63-202-92-157.dsl.snfc21.pacbell.net [63.202.92.157]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AGK3312332 for <[e-mail]>; Mon, 10 Mar 2003 08:20:03 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0521050cba926acf7349@[63.202.92.157]>
In-Reply-To: <002c01c2e6cc$80bd4640$0500a8c0@arport>
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]> <008801c2e5b1$fd603cf0$0500a8c0@arport> <a05200f25ba919f2aa947@[10.10.10.2]> <002c01c2e6cc$80bd4640$0500a8c0@arport>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Mon, 10 Mar 2003 08:19:41 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: The IETF 56 - PKIX Agenda
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 7:15 AM +0100 3/10/03, Anders Rundgren wrote:
>You are absolutely right, this is childish, but you also do not have
>the full background to this long-time feud.

The background doesn't matter. If I find yourself about to write 
something childish, and I am an adult, it is my responsibility to not 
finish it.

>I honestly regret the personal attack on Steve & Co which actually
>was NOT even meant to reach a larger audience (you extended the
>reply-list and I did not notice that).

It is not clear that sending personal attacks to individuals is that 
much better than sending them to the whole mailing list. In the 
latter case, it wastes more people's time, but in the former case, it 
causes the person being attacked to wonder why he/she should be doing 
this.

If we want effective official and unofficial leadership in the WG, we 
shouldn't be sending personal attacks to individuals or to the whole 
WG.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2ADVT505899 for ietf-pkix-bks; Mon, 10 Mar 2003 05:31:29 -0800 (PST)
Received: from hubie.hubbardind.com (mail.hubbardsupply.com [65.245.100.65]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2ADVR305895 for <[e-mail]>; Mon, 10 Mar 2003 05:31:27 -0800 (PST)
Received: by HUBIE.hubbardsupply.com with Internet Mail Service (5.5.2653.19) id <1JGDBN3N>; Mon, 10 Mar 2003 08:31:26 -0500
Message-ID: <[e-mail]>
From: Roger Younglove <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: General purpose OId's for certificate policies?
Date: Mon, 10 Mar 2003 08:31:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E709.546CE5E0"
Sender: [e-mail]
Precedence: 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_01C2E709.546CE5E0
Content-Type: text/plain

Comments interspersed

Roger Younglove, CISSP, IAM
Principal Consultant
NetWorks Group
O. 810.225.4800 ex. 2245
M. 810.599.0879
E. [e-mail]
www.networksgroup.com
 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Sunday, March 09, 2003 8:38 AM
To: [e-mail]
Subject: General purpose OId's for certificate policies?


Hi,

I've been trying to understand how the certificate policy extension of a 
certificate is used today and to which extend current and future 
PKI-dependent applications can make use of it. I tried to find examples of 
certificate policy OId's, but the few I found seemed to be limited to a 
particular CA, a particular organization, a particular application (like 
server authentication --- presumably TLS/SSL), etc.

My first question is therefore; is the current practice for each CA to
define 
their own certificate policy OId and maybe even a new OId for each 
organization to which the CA has issued certificates to?
**ry, Yes each CA registers an OID to identify its self and uses an
extension of that OID to identify the CP that the cert is issued under. If
there are more than one type of cert issued by that CA the OID identifies
each CP used. This allows a RP to identify the issuing CA and CP and make a
decision at if the cert is acceptable for the particular use to which it has
been applied.

It seems reasonable to have such highly specialised/limited scope OId's in 
some PKI deployments. However, for large volume commercial products like 
PDA's and cell phones, it seems difficult to provide a general, managable, 
and userfriendly mechanism for updating the configuration of the terminals 
with knowledge of the correct policy OId's. During the production of such 
terminals, it is typically not known where the terminal will be deployed, so

it seems that it is in general not possible to preconfigure the terminals 
with the correct OId's, either.

For the end-user, it would probably be easier if, for example, there were 
generally agreed upon policy OId's for web server authentication (class 
1/2/3, etc.), email signature validation, etc. I am thinking along the lines

of the policy OId's defined for the extendedKeyUsage (althought the two 
extensions are used differently in the path validation algorithm) with the 
addition that some generally agreed upon graduation of what policy is
implied 
(the class 1, class 2, class 3, etc.).

My second question is therefore; does anyone on this mail list know whether 
such general purpose policy OId's exist (for use with commercial/public 
internet services), or if initiatives to define such Oid's are ongoing? (If 
yes, I would be very interested in some links to the relevant sources.)
**ry, Not to my knowledge. 

Or, is it so that when it comes to, e.g., typical deployments of TLS/SSL
over 
the public internet, the certificate policies extension is not seen useful
at 
all? What is the general opinion on this from todays CA's?

What I have in mind is that there can be many different applications running

on top of, say, TLS. If a key usage extension is present in a TLS server 
certificate, then RFC 2246 states what this extension must contain for the 
client to accept the servers certificate. But how can one tell (based on the

server certificate) whether the server is allowed to use TLS for WEB
content, 
only, or for both SMTP and WEB content (thought-up examples)? I was thinking

that exactly the certificate policies extension could help the client to 
differentiate between these situations. How do todays CA's see this? Is this

kind of differentiation irrelevant for their trust models?

/bv

------_=_NextPart_001_01C2E709.546CE5E0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: General purpose OId's for certificate policies?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Comments interspersed</FONT>
</P>

<P><FONT SIZE=3D2>Roger Younglove, CISSP, IAM</FONT>
<BR><FONT SIZE=3D2>Principal Consultant</FONT>
<BR><FONT SIZE=3D2>NetWorks Group</FONT>
<BR><FONT SIZE=3D2>O. 810.225.4800 ex. 2245</FONT>
<BR><FONT SIZE=3D2>M. 810.599.0879</FONT>
<BR><FONT SIZE=3D2>E. [e-mail]</FONT>
<BR><FONT SIZE=3D2>www.networksgroup.com</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Sunday, March 09, 2003 8:38 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: General purpose OId's for certificate =
policies?</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>I've been trying to understand how the certificate =
policy extension of a </FONT>
<BR><FONT SIZE=3D2>certificate is used today and to which extend =
current and future </FONT>
<BR><FONT SIZE=3D2>PKI-dependent applications can make use of it. I =
tried to find examples of </FONT>
<BR><FONT SIZE=3D2>certificate policy OId's, but the few I found seemed =
to be limited to a </FONT>
<BR><FONT SIZE=3D2>particular CA, a particular organization, a =
particular application (like </FONT>
<BR><FONT SIZE=3D2>server authentication --- presumably TLS/SSL), =
etc.</FONT>
</P>

<P><FONT SIZE=3D2>My first question is therefore; is the current =
practice for each CA to define </FONT>
<BR><FONT SIZE=3D2>their own certificate policy OId and maybe even a =
new OId for each </FONT>
<BR><FONT SIZE=3D2>organization to which the CA has issued certificates =
to?</FONT>
<BR><FONT SIZE=3D2>**ry, Yes each CA registers an OID to identify its =
self and uses an extension of that OID to identify the CP that the cert =
is issued under. If there are more than one type of cert issued by that =
CA the OID identifies each CP used. This allows a RP to identify the =
issuing CA and CP and make a decision at if the cert is acceptable for =
the particular use to which it has been applied.</FONT></P>

<P><FONT SIZE=3D2>It seems reasonable to have such highly =
specialised/limited scope OId's in </FONT>
<BR><FONT SIZE=3D2>some PKI deployments. However, for large volume =
commercial products like </FONT>
<BR><FONT SIZE=3D2>PDA's and cell phones, it seems difficult to provide =
a general, managable, </FONT>
<BR><FONT SIZE=3D2>and userfriendly mechanism for updating the =
configuration of the terminals </FONT>
<BR><FONT SIZE=3D2>with knowledge of the correct policy OId's. During =
the production of such </FONT>
<BR><FONT SIZE=3D2>terminals, it is typically not known where the =
terminal will be deployed, so </FONT>
<BR><FONT SIZE=3D2>it seems that it is in general not possible to =
preconfigure the terminals </FONT>
<BR><FONT SIZE=3D2>with the correct OId's, either.</FONT>
</P>

<P><FONT SIZE=3D2>For the end-user, it would probably be easier if, for =
example, there were </FONT>
<BR><FONT SIZE=3D2>generally agreed upon policy OId's for web server =
authentication (class </FONT>
<BR><FONT SIZE=3D2>1/2/3, etc.), email signature validation, etc. I am =
thinking along the lines </FONT>
<BR><FONT SIZE=3D2>of the policy OId's defined for the extendedKeyUsage =
(althought the two </FONT>
<BR><FONT SIZE=3D2>extensions are used differently in the path =
validation algorithm) with the </FONT>
<BR><FONT SIZE=3D2>addition that some generally agreed upon graduation =
of what policy is implied </FONT>
<BR><FONT SIZE=3D2>(the class 1, class 2, class 3, etc.).</FONT>
</P>

<P><FONT SIZE=3D2>My second question is therefore; does anyone on this =
mail list know whether </FONT>
<BR><FONT SIZE=3D2>such general purpose policy OId's exist (for use =
with commercial/public </FONT>
<BR><FONT SIZE=3D2>internet services), or if initiatives to define such =
Oid's are ongoing? (If </FONT>
<BR><FONT SIZE=3D2>yes, I would be very interested in some links to the =
relevant sources.)</FONT>
<BR><FONT SIZE=3D2>**ry, Not to my knowledge. </FONT>
</P>

<P><FONT SIZE=3D2>Or, is it so that when it comes to, e.g., typical =
deployments of TLS/SSL over </FONT>
<BR><FONT SIZE=3D2>the public internet, the certificate policies =
extension is not seen useful at </FONT>
<BR><FONT SIZE=3D2>all? What is the general opinion on this from todays =
CA's?</FONT>
</P>

<P><FONT SIZE=3D2>What I have in mind is that there can be many =
different applications running </FONT>
<BR><FONT SIZE=3D2>on top of, say, TLS. If a key usage extension is =
present in a TLS server </FONT>
<BR><FONT SIZE=3D2>certificate, then RFC 2246 states what this =
extension must contain for the </FONT>
<BR><FONT SIZE=3D2>client to accept the servers certificate. But how =
can one tell (based on the </FONT>
<BR><FONT SIZE=3D2>server certificate) whether the server is allowed to =
use TLS for WEB content, </FONT>
<BR><FONT SIZE=3D2>only, or for both SMTP and WEB content (thought-up =
examples)? I was thinking </FONT>
<BR><FONT SIZE=3D2>that exactly the certificate policies extension =
could help the client to </FONT>
<BR><FONT SIZE=3D2>differentiate between these situations. How do =
todays CA's see this? Is this </FONT>
<BR><FONT SIZE=3D2>kind of differentiation irrelevant for their trust =
models?</FONT>
</P>

<P><FONT SIZE=3D2>/bv</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2E709.546CE5E0--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AAnpb21993 for ietf-pkix-bks; Mon, 10 Mar 2003 02:49:51 -0800 (PST)
Received: from vmmr7.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AAnm321986 for <[e-mail]>; Mon, 10 Mar 2003 02:49:48 -0800 (PST)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id OSP22383; Mon, 10 Mar 2003 05:49:48 -0500 (EST)
Received: from laptop-cpq.retrospekt.com (1Cust80.tnt6.stk3.swe.da.uu.net [213.116.236.80]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ABS22984; Mon, 10 Mar 2003 05:49:44 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 10 Mar 2003 11:36:39 +0100
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
In-Reply-To: <008c01c2e6e9$5a102090$0500a8c0@arport>
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]> <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_176456631==.ALT"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Anders,

Just so I get you right.

The conclusion is that in your opinion there is no problem with RFC 3039 
with regard to this.

Personally I have had a hard time see the problem with this. This was 
sorted out many years ago and X.520 was even updated to clarify that it was 
appropriate to accommodate this use, i.e. assigning identifiers to humans. 
(X.520: "The Serial Number attribute type specifies an identifier, the 
serial number of an object. ")

/Stefan

At 10:42 2003-03-10 +0100, Anders Rundgren wrote:
>Stefan,
>
>If you read the PI draft there is no mentioning of RFC3039 or existing
>practices for representing permanent identifiers.    The culprit
>is the following line describing "serialNumber":
>
>    "It MAY contain a number or code assigned by the CA or an
>      identifier assigned by a government or civil authority"
>
>This is also one of the existing practices.
>
>However, in various messages, the PI practices as well as RFC3039
>is held as being a violation of PKI(X) standards and therefore should
>be deprecated.
>
>Note: I don't think Denis and the others have the guts to require
>a deprecation in the upcoming RFC3039 revision, they sort of
>prefer to make incompatible RFCs instead to show their dismay.
>
>That is their way to play in the PKIX kindergarten, I have mine as
>somebody noted :-)
>
>I prefer setting the record straight and go on, to hopefully be
>able to enter the PKIX primary school some day...
>
>Anders
>
>
>
>----- Original Message -----
>From: "Stefan Santesson" <[e-mail]>
>To: "Anders Rundgren" <[e-mail]>; "Peter Gutmann" 
><[e-mail]>; <[e-mail]>; "Jimi Thompson"
><[e-mail]>
>Sent: Monday, March 10, 2003 09:52
>Subject: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
>
>
>Anders,
>
>Sorry, but I couldn't figure out from this message what the problem with
>RFC 3039 are.
>Could you reveal them? (Short list in condensed form is OK)
>
>/Stefan
>
>At 21:33 2003-03-08 +0100, Anders Rundgren wrote:
>
> >Hi Jimi,
> >Actually we have a non-kindergarten problem as well.  That there is
> >no agenda unfortunately also describes the state of PKIX and its
> >leadership.  PKIX have many items in the workings that have not
> >been properly pitted against other solutions and therefore probably
> >never will get any real support.
> >
> >One of these things is the PI (permanent identifier) draft, which is
> >unique in the sense that it does not support *any* existing CAs using such
> >schemes.  What's even more odd is that the authors and Dr. Kent are
> >proud of that, due to some more or less religious beliefs that the "market"
> >(only in Scandinavia encompassing some 10-15M subscribers) are
> >deliberately violating PKI standards.  That these CAs are 100%
> >compliant with RFC3039,  Dr. Kent claims depends on that the RFC
> >authors were PAID by the CAs to make this RFC compliant to their
> >"lousy" scheme.  But if  RFC3039 were incorrect it should never have
> >passed the RFC process.  But no one said a word.  As at least one of
> >the RFC authors is a top scientist, I rather think that it is Dr. Kent and
> >his tired lot, that are simply obstructing progress for reasons unknown
> >to me.
> >
> >Anders
> >
> >----- Original Message -----
> >From: "Jimi Thompson" <[e-mail]>
> >To: "Peter Gutmann" <[e-mail]>;
> ><[e-mail]>; <[e-mail]>
> >Sent: Saturday, March 08, 2003 19:19
> >Subject: Re: The IETF 56 - PKIX Agenda
> >
> >
> >
> >Hmmm.....you realize of course that we have a far more interesting
> >phenomenon to study here.  It seems that certain of the PKIX member
> >have been suddenly time warped back to kindergarten.  We need to do
> >three things - 1) figure out how to get them back,  2) figure out how
> >to make money off this thing (I'm thinking pay-per-view) and 3) here
> >in the States we don't use custard, we use Jello since it's cheaper.
> >
> >
> > >"Anders Rundgren" <[e-mail]> writes:
> > >
> > >>In the absence of a published agenda I take the liberty to create one
> > which I
> > >>think could gather some interest :-)
> > >
> > >You forgot the main event:
> > >
> > >   What needs to be done to make PKI work?
> > >
> > >   This forum will be open to all PKIX members, and will constitute a 
> large
> > >   pool filled knee-deep with custard [1].  Marquis of Queensberry
> > Rules, but
> > >   with pies substituted for gloves.  Participants are expected to provide
> > >   appropriate clothing.  Remaining IETF members will look on in
> > amusement or
> > >   dismay, depending on their views on PKI.
> > >
> > >Peter.
> > >
> > >[1] Adrian Mitchell fans may hold the event in the Royal Albert Hall
> > instead.
> >
> >
> >--
> >Thanks,
> >
> >Ms. Jimi Thompson, CISSP, Rev.
> >
> >"If the automobile had followed the same development cycle as the
> >computer, a Rolls-Royce would today cost $100, get a million miles
> >per gallon, and explode once a year, killing everyone inside." --
> >Robert Cringely
>
>_____________________________
>Stefan Santesson,  Retrospekt AB
>http://www.retrospekt.com
>[phone]

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone]  
--=====================_176456631==.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<body>
Anders,<br><br>
Just so I get you right.<br><br>
The conclusion is that in your opinion there is no problem with RFC 3039
with regard to this.<br><br>
Personally I have had a hard time see the problem with this. This was
sorted out many years ago and X.520 was even updated to clarify that it
was appropriate to accommodate this use, i.e. assigning identifiers to
humans. (X.520: &quot;The <i>Serial Number</i> attribute type specifies
an identifier, the serial number of an object. &quot;)<br><br>
/Stefan<br><br>
At 10:42 2003-03-10 +0100, Anders Rundgren wrote:<br>
<blockquote type=cite class=cite cite>Stefan,<br><br>
If you read the PI draft there is no mentioning of RFC3039 or
existing<br>
practices for representing permanent identifiers.&nbsp;&nbsp;&nbsp; The
culprit<br>
is the following line describing &quot;serialNumber&quot;:<br><br>
&nbsp;&nbsp; &quot;It MAY contain a number or code assigned by the CA or
an<br>
&nbsp;&nbsp;&nbsp;&nbsp; identifier assigned by a government or civil
authority&quot;<br><br>
This is also one of the existing practices.<br><br>
However, in various messages, the PI practices as well as RFC3039<br>
is held as being a violation of PKI(X) standards and therefore
should<br>
be deprecated.<br><br>
Note: I don't think Denis and the others have the guts to require<br>
a deprecation in the upcoming RFC3039 revision, they sort of<br>
prefer to make incompatible RFCs instead to show their dismay.<br><br>
That is their way to play in the PKIX kindergarten, I have mine as<br>
somebody noted :-)<br><br>
I prefer setting the record straight and go on, to hopefully be<br>
able to enter the PKIX primary school some day...<br><br>
Anders<br><br>
<br><br>
----- Original Message -----<br>
From: &quot;Stefan Santesson&quot; &lt;[e-mail]&gt;<br>
To: &quot;Anders Rundgren&quot; &lt;[e-mail]&gt;;
&quot;Peter Gutmann&quot; &lt;[e-mail]&gt;;
&lt;[e-mail]&gt;; &quot;Jimi Thompson&quot;<br>
&lt;[e-mail]&gt;<br>
Sent: Monday, March 10, 2003 09:52<br>
Subject: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda<br><br>
<br>
Anders,<br><br>
Sorry, but I couldn't figure out from this message what the problem
with<br>
RFC 3039 are.<br>
Could you reveal them? (Short list in condensed form is OK)<br><br>
/Stefan<br><br>
At 21:33 2003-03-08 +0100, Anders Rundgren wrote:<br><br>
&gt;Hi Jimi,<br>
&gt;Actually we have a non-kindergarten problem as well.&nbsp; That there
is<br>
&gt;no agenda unfortunately also describes the state of PKIX and 
its<br>
&gt;leadership.&nbsp; PKIX have many items in the workings that have
not<br>
&gt;been properly pitted against other solutions and therefore
probably<br>
&gt;never will get any real support.<br>
&gt;<br>
&gt;One of these things is the PI (permanent identifier) draft, which
is<br>
&gt;unique in the sense that it does not support *any* existing CAs using
such<br>
&gt;schemes.&nbsp; What's even more odd is that the authors and Dr. Kent
are<br>
&gt;proud of that, due to some more or less religious beliefs that the
&quot;market&quot;<br>
&gt;(only in Scandinavia encompassing some 10-15M subscribers) are<br>
&gt;deliberately violating PKI standards.&nbsp; That these CAs are
100%<br>
&gt;compliant with RFC3039,&nbsp; Dr. Kent claims depends on that the
RFC<br>
&gt;authors were PAID by the CAs to make this RFC compliant to 
their<br>
&gt;&quot;lousy&quot; scheme.&nbsp; But if&nbsp; RFC3039 were incorrect
it should never have<br>
&gt;passed the RFC process.&nbsp; But no one said a word.&nbsp; As at
least one of<br>
&gt;the RFC authors is a top scientist, I rather think that it is Dr.
Kent and<br>
&gt;his tired lot, that are simply obstructing progress for reasons
unknown<br>
&gt;to me.<br>
&gt;<br>
&gt;Anders<br>
&gt;<br>
&gt;----- Original Message -----<br>
&gt;From: &quot;Jimi Thompson&quot; &lt;[e-mail]&gt;<br>
&gt;To: &quot;Peter Gutmann&quot; 
&lt;[e-mail]&gt;;<br>
&gt;&lt;[e-mail]&gt;; &lt;[e-mail]&gt;<br>
&gt;Sent: Saturday, March 08, 2003 19:19<br>
&gt;Subject: Re: The IETF 56 - PKIX Agenda<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;Hmmm.....you realize of course that we have a far more
interesting<br>
&gt;phenomenon to study here.&nbsp; It seems that certain of the PKIX
member<br>
&gt;have been suddenly time warped back to kindergarten.&nbsp; We need to
do<br>
&gt;three things - 1) figure out how to get them back,&nbsp; 2) figure
out how<br>
&gt;to make money off this thing (I'm thinking pay-per-view) and 3)
here<br>
&gt;in the States we don't use custard, we use Jello since it's
cheaper.<br>
&gt;<br>
&gt;<br>
&gt; &gt;&quot;Anders Rundgren&quot; &lt;[e-mail]&gt;
writes:<br>
&gt; &gt;<br>
&gt; &gt;&gt;In the absence of a published agenda I take the liberty to
create one<br>
&gt; which I<br>
&gt; &gt;&gt;think could gather some interest :-)<br>
&gt; &gt;<br>
&gt; &gt;You forgot the main event:<br>
&gt; &gt;<br>
&gt; &gt;&nbsp;&nbsp; What needs to be done to make PKI work?<br>
&gt; &gt;<br>
&gt; &gt;&nbsp;&nbsp; This forum will be open to all PKIX members, and
will constitute a large<br>
&gt; &gt;&nbsp;&nbsp; pool filled knee-deep with custard [1].&nbsp;
Marquis of Queensberry<br>
&gt; Rules, but<br>
&gt; &gt;&nbsp;&nbsp; with pies substituted for gloves.&nbsp;
Participants are expected to provide<br>
&gt; &gt;&nbsp;&nbsp; appropriate clothing.&nbsp; Remaining IETF members
will look on in<br>
&gt; amusement or<br>
&gt; &gt;&nbsp;&nbsp; dismay, depending on their views on PKI.<br>
&gt; &gt;<br>
&gt; &gt;Peter.<br>
&gt; &gt;<br>
&gt; &gt;[1] Adrian Mitchell fans may hold the event in the Royal Albert
Hall<br>
&gt; instead.<br>
&gt;<br>
&gt;<br>
&gt;--<br>
&gt;Thanks,<br>
&gt;<br>
&gt;Ms. Jimi Thompson, CISSP, Rev.<br>
&gt;<br>
&gt;&quot;If the automobile had followed the same development cycle as
the<br>
&gt;computer, a Rolls-Royce would today cost $100, get a million
miles<br>
&gt;per gallon, and explode once a year, killing everyone inside.&quot;
--<br>
&gt;Robert Cringely<br><br>
_____________________________<br>
Stefan Santesson,&nbsp; Retrospekt AB<br>
<a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a><br>
[phone]</blockquote>
<x-sigsep><p></x-sigsep>
_____________________________<br>
Stefan Santesson,&nbsp; Retrospekt AB<br>
<a href="http://www.retrospekt.com/" eudora="autourl">http://www.retrospekt.com</a><br>
[phone] </body>
</html>

--=====================_176456631==.ALT--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2AAbRC21328 for ietf-pkix-bks; Mon, 10 Mar 2003 02:37:27 -0800 (PST)
Received: from vmmr7.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2AAbO321323 for <[e-mail]>; Mon, 10 Mar 2003 02:37:24 -0800 (PST)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr7.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id OSP21694; Mon, 10 Mar 2003 05:37:24 -0500 (EST)
Received: from laptop-cpq.retrospekt.com (1Cust80.tnt6.stk3.swe.da.uu.net [213.116.236.80]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ABS22422; Mon, 10 Mar 2003 05:37:21 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 10 Mar 2003 11:36:39 +0100
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
In-Reply-To: <008c01c2e6e9$5a102090$0500a8c0@arport>
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]> <[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>

Anders,

Just so I get you right.

The conclusion is that in your opinion there is no problem with RFC 3039 
with regard to this.

/Stefan

At 10:42 2003-03-10 +0100, Anders Rundgren wrote:
>Stefan,
>
>If you read the PI draft there is no mentioning of RFC3039 or existing
>practices for representing permanent identifiers.    The culprit
>is the following line describing "serialNumber":
>
>    "It MAY contain a number or code assigned by the CA or an
>      identifier assigned by a government or civil authority"
>
>This is also one of the existing practices.
>
>However, in various messages, the PI practices as well as RFC3039
>is held as being a violation of PKI(X) standards and therefore should
>be deprecated.
>
>Note: I don't think Denis and the others have the guts to require
>a deprecation in the upcoming RFC3039 revision, they sort of
>prefer to make incompatible RFCs instead to show their dismay.
>
>That is their way to play in the PKIX kindergarten, I have mine as
>somebody noted :-)
>
>I prefer setting the record straight and go on, to hopefully be
>able to enter the PKIX primary school some day...
>
>Anders
>
>
>
>----- Original Message -----
>From: "Stefan Santesson" <[e-mail]>
>To: "Anders Rundgren" <[e-mail]>; "Peter Gutmann" 
><[e-mail]>; <[e-mail]>; "Jimi Thompson"
><[e-mail]>
>Sent: Monday, March 10, 2003 09:52
>Subject: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
>
>
>Anders,
>
>Sorry, but I couldn't figure out from this message what the problem with
>RFC 3039 are.
>Could you reveal them? (Short list in condensed form is OK)
>
>/Stefan
>
>At 21:33 2003-03-08 +0100, Anders Rundgren wrote:
>
> >Hi Jimi,
> >Actually we have a non-kindergarten problem as well.  That there is
> >no agenda unfortunately also describes the state of PKIX and its
> >leadership.  PKIX have many items in the workings that have not
> >been properly pitted against other solutions and therefore probably
> >never will get any real support.
> >
> >One of these things is the PI (permanent identifier) draft, which is
> >unique in the sense that it does not support *any* existing CAs using such
> >schemes.  What's even more odd is that the authors and Dr. Kent are
> >proud of that, due to some more or less religious beliefs that the "market"
> >(only in Scandinavia encompassing some 10-15M subscribers) are
> >deliberately violating PKI standards.  That these CAs are 100%
> >compliant with RFC3039,  Dr. Kent claims depends on that the RFC
> >authors were PAID by the CAs to make this RFC compliant to their
> >"lousy" scheme.  But if  RFC3039 were incorrect it should never have
> >passed the RFC process.  But no one said a word.  As at least one of
> >the RFC authors is a top scientist, I rather think that it is Dr. Kent and
> >his tired lot, that are simply obstructing progress for reasons unknown
> >to me.
> >
> >Anders
> >
> >----- Original Message -----
> >From: "Jimi Thompson" <[e-mail]>
> >To: "Peter Gutmann" <[e-mail]>;
> ><[e-mail]>; <[e-mail]>
> >Sent: Saturday, March 08, 2003 19:19
> >Subject: Re: The IETF 56 - PKIX Agenda
> >
> >
> >
> >Hmmm.....you realize of course that we have a far more interesting
> >phenomenon to study here.  It seems that certain of the PKIX member
> >have been suddenly time warped back to kindergarten.  We need to do
> >three things - 1) figure out how to get them back,  2) figure out how
> >to make money off this thing (I'm thinking pay-per-view) and 3) here
> >in the States we don't use custard, we use Jello since it's cheaper.
> >
> >
> > >"Anders Rundgren" <[e-mail]> writes:
> > >
> > >>In the absence of a published agenda I take the liberty to create one
> > which I
> > >>think could gather some interest :-)
> > >
> > >You forgot the main event:
> > >
> > >   What needs to be done to make PKI work?
> > >
> > >   This forum will be open to all PKIX members, and will constitute a 
> large
> > >   pool filled knee-deep with custard [1].  Marquis of Queensberry
> > Rules, but
> > >   with pies substituted for gloves.  Participants are expected to provide
> > >   appropriate clothing.  Remaining IETF members will look on in
> > amusement or
> > >   dismay, depending on their views on PKI.
> > >
> > >Peter.
> > >
> > >[1] Adrian Mitchell fans may hold the event in the Royal Albert Hall
> > instead.
> >
> >
> >--
> >Thanks,
> >
> >Ms. Jimi Thompson, CISSP, Rev.
> >
> >"If the automobile had followed the same development cycle as the
> >computer, a Rolls-Royce would today cost $100, get a million miles
> >per gallon, and explode once a year, killing everyone inside." --
> >Robert Cringely
>
>_____________________________
>Stefan Santesson,  Retrospekt AB
>http://www.retrospekt.com
>[phone]

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone] 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2A9r8r16648 for ietf-pkix-bks; Mon, 10 Mar 2003 01:53:08 -0800 (PST)
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2A9r4316644 for <[e-mail]>; Mon, 10 Mar 2003 01:53:05 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailc.telia.com (8.12.8/8.12.8) with SMTP id h2A9r4Ha023180; Mon, 10 Mar 2003 10:53:04 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <008c01c2e6e9$5a102090$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Stefan Santesson" <[e-mail]>
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]> <[e-mail]>
Subject: Re: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
Date: Mon, 10 Mar 2003 10:42:22 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: 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,

If you read the PI draft there is no mentioning of RFC3039 or existing
practices for representing permanent identifiers.    The culprit
is the following line describing "serialNumber":

   "It MAY contain a number or code assigned by the CA or an
     identifier assigned by a government or civil authority"

This is also one of the existing practices.

However, in various messages, the PI practices as well as RFC3039
is held as being a violation of PKI(X) standards and therefore should
be deprecated.

Note: I don't think Denis and the others have the guts to require
a deprecation in the upcoming RFC3039 revision, they sort of
prefer to make incompatible RFCs instead to show their dismay.

That is their way to play in the PKIX kindergarten, I have mine as
somebody noted :-)

I prefer setting the record straight and go on, to hopefully be
able to enter the PKIX primary school some day...

Anders



----- Original Message -----
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; "Peter Gutmann" <[e-mail]>; <[e-mail]>; "Jimi Thompson"
<[e-mail]>
Sent: Monday, March 10, 2003 09:52
Subject: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda


Anders,

Sorry, but I couldn't figure out from this message what the problem with
RFC 3039 are.
Could you reveal them? (Short list in condensed form is OK)

/Stefan

At 21:33 2003-03-08 +0100, Anders Rundgren wrote:

>Hi Jimi,
>Actually we have a non-kindergarten problem as well.  That there is
>no agenda unfortunately also describes the state of PKIX and its
>leadership.  PKIX have many items in the workings that have not
>been properly pitted against other solutions and therefore probably
>never will get any real support.
>
>One of these things is the PI (permanent identifier) draft, which is
>unique in the sense that it does not support *any* existing CAs using such
>schemes.  What's even more odd is that the authors and Dr. Kent are
>proud of that, due to some more or less religious beliefs that the "market"
>(only in Scandinavia encompassing some 10-15M subscribers) are
>deliberately violating PKI standards.  That these CAs are 100%
>compliant with RFC3039,  Dr. Kent claims depends on that the RFC
>authors were PAID by the CAs to make this RFC compliant to their
>"lousy" scheme.  But if  RFC3039 were incorrect it should never have
>passed the RFC process.  But no one said a word.  As at least one of
>the RFC authors is a top scientist, I rather think that it is Dr. Kent and
>his tired lot, that are simply obstructing progress for reasons unknown
>to me.
>
>Anders
>
>----- Original Message -----
>From: "Jimi Thompson" <[e-mail]>
>To: "Peter Gutmann" <[e-mail]>;
><[e-mail]>; <[e-mail]>
>Sent: Saturday, March 08, 2003 19:19
>Subject: Re: The IETF 56 - PKIX Agenda
>
>
>
>Hmmm.....you realize of course that we have a far more interesting
>phenomenon to study here.  It seems that certain of the PKIX member
>have been suddenly time warped back to kindergarten.  We need to do
>three things - 1) figure out how to get them back,  2) figure out how
>to make money off this thing (I'm thinking pay-per-view) and 3) here
>in the States we don't use custard, we use Jello since it's cheaper.
>
>
> >"Anders Rundgren" <[e-mail]> writes:
> >
> >>In the absence of a published agenda I take the liberty to create one
> which I
> >>think could gather some interest :-)
> >
> >You forgot the main event:
> >
> >   What needs to be done to make PKI work?
> >
> >   This forum will be open to all PKIX members, and will constitute a large
> >   pool filled knee-deep with custard [1].  Marquis of Queensberry
> Rules, but
> >   with pies substituted for gloves.  Participants are expected to provide
> >   appropriate clothing.  Remaining IETF members will look on in
> amusement or
> >   dismay, depending on their views on PKI.
> >
> >Peter.
> >
> >[1] Adrian Mitchell fans may hold the event in the Royal Albert Hall
> instead.
>
>
>--
>Thanks,
>
>Ms. Jimi Thompson, CISSP, Rev.
>
>"If the automobile had followed the same development cycle as the
>computer, a Rolls-Royce would today cost $100, get a million miles
>per gallon, and explode once a year, killing everyone inside." --
>Robert Cringely

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone]




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2A8rng08067 for ietf-pkix-bks; Mon, 10 Mar 2003 00:53:49 -0800 (PST)
Received: from vmmr9.verisignmail.com (vmmrnat.verisignmail.com [216.168.230.187]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2A8rl308056 for <[e-mail]>; Mon, 10 Mar 2003 00:53:47 -0800 (PST)
Received: from ms1.verisignmail.com (ms1.verisignmail.com [216.168.230.167] (may be forged)) by vmmr9.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id PCD14284; Mon, 10 Mar 2003 03:53:45 -0500 (EST)
Received: from laptop-cpq.retrospekt.com (1Cust64.tnt14.stk3.swe.da.uu.net [213.116.254.64]) by ms1.verisignmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id ABS16541 (AUTH [e-mail]); Mon, 10 Mar 2003 03:53:40 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]@mail.retrospekt.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 10 Mar 2003 09:52:01 +0100
To: "Anders Rundgren" <[e-mail]>, "Peter Gutmann" <[e-mail]>, <[e-mail]>, "Jimi Thompson" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: RFC 3039 problems - Was: Re: The IETF 56 - PKIX Agenda
In-Reply-To: <008801c2e5b1$fd603cf0$0500a8c0@arport>
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

Sorry, but I couldn't figure out from this message what the problem with 
RFC 3039 are.
Could you reveal them? (Short list in condensed form is OK)

/Stefan

At 21:33 2003-03-08 +0100, Anders Rundgren wrote:

>Hi Jimi,
>Actually we have a non-kindergarten problem as well.  That there is
>no agenda unfortunately also describes the state of PKIX and its
>leadership.  PKIX have many items in the workings that have not
>been properly pitted against other solutions and therefore probably
>never will get any real support.
>
>One of these things is the PI (permanent identifier) draft, which is
>unique in the sense that it does not support *any* existing CAs using such
>schemes.  What's even more odd is that the authors and Dr. Kent are
>proud of that, due to some more or less religious beliefs that the "market"
>(only in Scandinavia encompassing some 10-15M subscribers) are
>deliberately violating PKI standards.  That these CAs are 100%
>compliant with RFC3039,  Dr. Kent claims depends on that the RFC
>authors were PAID by the CAs to make this RFC compliant to their
>"lousy" scheme.  But if  RFC3039 were incorrect it should never have
>passed the RFC process.  But no one said a word.  As at least one of
>the RFC authors is a top scientist, I rather think that it is Dr. Kent and
>his tired lot, that are simply obstructing progress for reasons unknown
>to me.
>
>Anders
>
>----- Original Message -----
>From: "Jimi Thompson" <[e-mail]>
>To: "Peter Gutmann" <[e-mail]>; 
><[e-mail]>; <[e-mail]>
>Sent: Saturday, March 08, 2003 19:19
>Subject: Re: The IETF 56 - PKIX Agenda
>
>
>
>Hmmm.....you realize of course that we have a far more interesting
>phenomenon to study here.  It seems that certain of the PKIX member
>have been suddenly time warped back to kindergarten.  We need to do
>three things - 1) figure out how to get them back,  2) figure out how
>to make money off this thing (I'm thinking pay-per-view) and 3) here
>in the States we don't use custard, we use Jello since it's cheaper.
>
>
> >"Anders Rundgren" <[e-mail]> writes:
> >
> >>In the absence of a published agenda I take the liberty to create one 
> which I
> >>think could gather some interest :-)
> >
> >You forgot the main event:
> >
> >   What needs to be done to make PKI work?
> >
> >   This forum will be open to all PKIX members, and will constitute a large
> >   pool filled knee-deep with custard [1].  Marquis of Queensberry 
> Rules, but
> >   with pies substituted for gloves.  Participants are expected to provide
> >   appropriate clothing.  Remaining IETF members will look on in 
> amusement or
> >   dismay, depending on their views on PKI.
> >
> >Peter.
> >
> >[1] Adrian Mitchell fans may hold the event in the Royal Albert Hall 
> instead.
>
>
>--
>Thanks,
>
>Ms. Jimi Thompson, CISSP, Rev.
>
>"If the automobile had followed the same development cycle as the
>computer, a Rolls-Royce would today cost $100, get a million miles
>per gallon, and explode once a year, killing everyone inside." --
>Robert Cringely

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
[phone] 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2A6Qei16090 for ietf-pkix-bks; Sun, 9 Mar 2003 22:26:40 -0800 (PST)
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2A6Qa316086 for <[e-mail]>; Sun, 9 Mar 2003 22:26:37 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailc.telia.com (8.12.8/8.12.8) with SMTP id h2A6QXHa022796; Mon, 10 Mar 2003 07:26:33 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <002c01c2e6cc$80bd4640$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, "Jimi Thompson" <[e-mail]>
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]> <008801c2e5b1$fd603cf0$0500a8c0@arport> <a05200f25ba919f2aa947@[10.10.10.2]>
Subject: Re: The IETF 56 - PKIX Agenda
Date: Mon, 10 Mar 2003 07:15:51 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jimi,
You are absolutely right, this is childish, but you also do not have
the full background to this long-time feud.

I honestly regret the personal attack on Steve & Co which actually
was NOT even meant to reach a larger audience (you extended the
reply-list and I did not notice that).   Steve, are you listening?

Regarding the PI/RFC3039 story it is unfortunately the case that
 these efforts are on completely separate routes in spite of being
natural "companions".  The PI authors who soon have been
toiling with the draft for 3 years,  have not presented any rationale
for not aligning their effort to RFC3039 and existing practices.

It seems like a task for the WG-chairs to settle this score once for all.
Does the following line in RFC3039 regarding "serialNumber"
violate PKI(X) standards?

   1] It MAY contain a number or code assigned by the CA or an
       identifier assigned by a government or civil authority

As PI is close to final call, RFC3039 is subject to a revision, and
there is a PI "competitor" in the workings that exploits the current
practice and RFC3039, it is really "now or never".

Anders



----- Original Message ----- 
From: "Jimi Thompson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; "Peter Gutmann" <[e-mail]>; <[e-mail]>
Sent: Monday, March 10, 2003 03:22
Subject: Re: The IETF 56 - PKIX Agenda


At 9:33 PM +0100 3/8/03, Anders Rundgren wrote:
Anders & PKIX WG,

I personally don't care about the motivation or the past.  It is past 
and therefore belongs with the dust.  My point is that there seems to 
be a problem.  Instead of working together to solve it and produce a 
fine technical solution everyone can live with, there is a certain 
element on this list who is simply not being constructive.  I would 
suspect that for all of us, that our time is valuable.  Wasting a 
commodity that one can never recover seems childish to me.

I am aware that there are personal differences, however, we are all 
supposed to be adults and professionals.  Working with a group means 
making compromises - sometimes even ones that you don't personally 
care for.  It just goes with the territory.   I know it's not easy 
when the draft of the RFC doesn't have what you want in it.  It's 
painful because you worked so hard.  It annoying because you feel 
that you are right.   But I'm sure that the other people on this list 
worked hard and good valid ideas, too.  Sometimes you have to move in 
increments.  Somtimes you don't get what you want at all.  That's 
just how it goes.  It's not supposed to devolve in to personal 
attacks and sarcastic sniping.

There is a place for everything, but this isn't the place for 
"religious beliefs".  Take that to 
church/mosque/synagog/temple/whatever with you.  We're here to build 
something that the rest of the world needs.  Let's get back to the 
task at hand.  If one can't contribute and be constructive, then 
perhaps its time to "sit this one out".

>Hi Jimi,
>Actually we have a non-kindergarten problem as well.  That there is
>no agenda unfortunately also describes the state of PKIX and its
>leadership.  PKIX have many items in the workings that have not
>been properly pitted against other solutions and therefore probably
>never will get any real support.
>
>One of these things is the PI (permanent identifier) draft, which is
>unique in the sense that it does not support *any* existing CAs using such
>schemes.  What's even more odd is that the authors and Dr. Kent are
>proud of that, due to some more or less religious beliefs that the "market"
>(only in Scandinavia encompassing some 10-15M subscribers) are
>deliberately violating PKI standards.  That these CAs are 100%
>compliant with RFC3039,  Dr. Kent claims depends on that the RFC
>authors were PAID by the CAs to make this RFC compliant to their
>"lousy" scheme.  But if  RFC3039 were incorrect it should never have
>passed the RFC process.  But no one said a word.  As at least one of
>the RFC authors is a top scientist, I rather think that it is Dr. Kent and
>his tired lot, that are simply obstructing progress for reasons unknown
>to me.
>
>Anders
>
>----- Original Message -----
>From: "Jimi Thompson" <[e-mail]>
>To: "Peter Gutmann" <[e-mail]>; 
><[e-mail]>; <[e-mail]>
>Sent: Saturday, March 08, 2003 19:19
>Subject: Re: The IETF 56 - PKIX Agenda
>
>
>
>Hmmm.....you realize of course that we have a far more interesting
>phenomenon to study here.  It seems that certain of the PKIX member
>have been suddenly time warped back to kindergarten.  We need to do
>three things - 1) figure out how to get them back,  2) figure out how
>to make money off this thing (I'm thinking pay-per-view) and 3) here
>in the States we don't use custard, we use Jello since it's cheaper.
>
>
>>"Anders Rundgren" <[e-mail]> writes:
>>
>>>In the absence of a published agenda I take the liberty to create 
>>>one which I
>>>think could gather some interest :-)
>>
>>You forgot the main event:
>>
>>    What needs to be done to make PKI work?
>>
>>    This forum will be open to all PKIX members, and will constitute a large
>>    pool filled knee-deep with custard [1].  Marquis of Queensberry Rules, but
>>    with pies substituted for gloves.  Participants are expected to provide
>  >   appropriate clothing.  Remaining IETF members will look on in 
>amusement or
>>    dismay, depending on their views on PKI.
>>
>>Peter.
>>
>>[1] Adrian Mitchell fans may hold the event in the Royal Albert Hall instead.
>
>
>--
>Thanks,
>
>Ms. Jimi Thompson, CISSP, Rev.
>
>"If the automobile had followed the same development cycle as the
>computer, a Rolls-Royce would today cost $100, get a million miles
>per gallon, and explode once a year, killing everyone inside." --
>Robert Cringely


-- 
Thanks,

Ms. Jimi Thompson, CISSP, Rev.

"If the automobile had followed the same development cycle as the 
computer, a Rolls-Royce would today cost $100, get a million miles 
per gallon, and explode once a year, killing everyone inside." -- 
Robert Cringely



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2A2QLJ11592 for ietf-pkix-bks; Sun, 9 Mar 2003 18:26:21 -0800 (PST)
Received: from smtpauth2-ext.prodigy.net (smtpauth2-ext.prodigy.net [207.115.63.116]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2A2QJ311583 for <[e-mail]>; Sun, 9 Mar 2003 18:26:19 -0800 (PST)
Received: from [10.10.10.2] (crtntx1-ar1-4-60-255-009.crtntx1.dsl-verizon.net [4.60.255.9]) (authenticated) by smtpauth2-ext.prodigy.net (8.11.0/8.11.0) with ESMTP id h2A2QGc07992; Sun, 9 Mar 2003 21:26:17 -0500
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05200f25ba919f2aa947@[10.10.10.2]>
In-Reply-To: <008801c2e5b1$fd603cf0$0500a8c0@arport>
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]> <008801c2e5b1$fd603cf0$0500a8c0@arport>
Date: Sun, 9 Mar 2003 20:22:52 -0600
To: "Anders Rundgren" <[e-mail]>, "Peter Gutmann" <[e-mail]>, <[e-mail]>
From: Jimi Thompson <[e-mail]>
Subject: Re: The IETF 56 - PKIX Agenda
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 9:33 PM +0100 3/8/03, Anders Rundgren wrote:
Anders & PKIX WG,

I personally don't care about the motivation or the past.  It is past 
and therefore belongs with the dust.  My point is that there seems to 
be a problem.  Instead of working together to solve it and produce a 
fine technical solution everyone can live with, there is a certain 
element on this list who is simply not being constructive.  I would 
suspect that for all of us, that our time is valuable.  Wasting a 
commodity that one can never recover seems childish to me.

I am aware that there are personal differences, however, we are all 
supposed to be adults and professionals.  Working with a group means 
making compromises - sometimes even ones that you don't personally 
care for.  It just goes with the territory.   I know it's not easy 
when the draft of the RFC doesn't have what you want in it.  It's 
painful because you worked so hard.  It annoying because you feel 
that you are right.   But I'm sure that the other people on this list 
worked hard and good valid ideas, too.  Sometimes you have to move in 
increments.  Somtimes you don't get what you want at all.  That's 
just how it goes.  It's not supposed to devolve in to personal 
attacks and sarcastic sniping.

There is a place for everything, but this isn't the place for 
"religious beliefs".  Take that to 
church/mosque/synagog/temple/whatever with you.  We're here to build 
something that the rest of the world needs.  Let's get back to the 
task at hand.  If one can't contribute and be constructive, then 
perhaps its time to "sit this one out".

>Hi Jimi,
>Actually we have a non-kindergarten problem as well.  That there is
>no agenda unfortunately also describes the state of PKIX and its
>leadership.  PKIX have many items in the workings that have not
>been properly pitted against other solutions and therefore probably
>never will get any real support.
>
>One of these things is the PI (permanent identifier) draft, which is
>unique in the sense that it does not support *any* existing CAs using such
>schemes.  What's even more odd is that the authors and Dr. Kent are
>proud of that, due to some more or less religious beliefs that the "market"
>(only in Scandinavia encompassing some 10-15M subscribers) are
>deliberately violating PKI standards.  That these CAs are 100%
>compliant with RFC3039,  Dr. Kent claims depends on that the RFC
>authors were PAID by the CAs to make this RFC compliant to their
>"lousy" scheme.  But if  RFC3039 were incorrect it should never have
>passed the RFC process.  But no one said a word.  As at least one of
>the RFC authors is a top scientist, I rather think that it is Dr. Kent and
>his tired lot, that are simply obstructing progress for reasons unknown
>to me.
>
>Anders
>
>----- Original Message -----
>From: "Jimi Thompson" <[e-mail]>
>To: "Peter Gutmann" <[e-mail]>; 
><[e-mail]>; <[e-mail]>
>Sent: Saturday, March 08, 2003 19:19
>Subject: Re: The IETF 56 - PKIX Agenda
>
>
>
>Hmmm.....you realize of course that we have a far more interesting
>phenomenon to study here.  It seems that certain of the PKIX member
>have been suddenly time warped back to kindergarten.  We need to do
>three things - 1) figure out how to get them back,  2) figure out how
>to make money off this thing (I'm thinking pay-per-view) and 3) here
>in the States we don't use custard, we use Jello since it's cheaper.
>
>
>>"Anders Rundgren" <[e-mail]> writes:
>>
>>>In the absence of a published agenda I take the liberty to create 
>>>one which I
>>>think could gather some interest :-)
>>
>>You forgot the main event:
>>
>>    What needs to be done to make PKI work?
>>
>>    This forum will be open to all PKIX members, and will constitute a large
>>    pool filled knee-deep with custard [1].  Marquis of Queensberry Rules, but
>>    with pies substituted for gloves.  Participants are expected to provide
>  >   appropriate clothing.  Remaining IETF members will look on in 
>amusement or
>>    dismay, depending on their views on PKI.
>>
>>Peter.
>>
>>[1] Adrian Mitchell fans may hold the event in the Royal Albert Hall instead.
>
>
>--
>Thanks,
>
>Ms. Jimi Thompson, CISSP, Rev.
>
>"If the automobile had followed the same development cycle as the
>computer, a Rolls-Royce would today cost $100, get a million miles
>per gallon, and explode once a year, killing everyone inside." --
>Robert Cringely


-- 
Thanks,

Ms. Jimi Thompson, CISSP, Rev.

"If the automobile had followed the same development cycle as the 
computer, a Rolls-Royce would today cost $100, get a million miles 
per gallon, and explode once a year, killing everyone inside." -- 
Robert Cringely


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h29GeDf19623 for ietf-pkix-bks; Sun, 9 Mar 2003 08:40:13 -0800 (PST)
Received: from smtp220.tiscali.dk (smtp220.tiscali.dk [62.79.79.114]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h29GeA319619 for <[e-mail]>; Sun, 9 Mar 2003 08:40:11 -0800 (PST)
Received: from howard (212.54.73.107.reg05.ppp.vby.pbv.tiscali.dk [212.54.73.107]) by smtp220.tiscali.dk (8.12.6/8.12.6) with ESMTP id h29Gdn8Q036364 for <[e-mail]>; Sun, 9 Mar 2003 17:40:00 +0100 (CET) (envelope-from [e-mail])
Content-Type: text/plain; charset="us-ascii"
From: [e-mail]
Reply-To: [e-mail]
To: [e-mail]
Subject: General purpose OId's for certificate policies?
Date: Sun, 9 Mar 2003 14:37:34 +0100
X-Mailer: KMail [version 1.4]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

I've been trying to understand how the certificate policy extension of a 
certificate is used today and to which extend current and future 
PKI-dependent applications can make use of it. I tried to find examples of 
certificate policy OId's, but the few I found seemed to be limited to a 
particular CA, a particular organization, a particular application (like 
server authentication --- presumably TLS/SSL), etc.

My first question is therefore; is the current practice for each CA to define 
their own certificate policy OId and maybe even a new OId for each 
organization to which the CA has issued certificates to?

It seems reasonable to have such highly specialised/limited scope OId's in 
some PKI deployments. However, for large volume commercial products like 
PDA's and cell phones, it seems difficult to provide a general, managable, 
and userfriendly mechanism for updating the configuration of the terminals 
with knowledge of the correct policy OId's. During the production of such 
terminals, it is typically not known where the terminal will be deployed, so 
it seems that it is in general not possible to preconfigure the terminals 
with the correct OId's, either.

For the end-user, it would probably be easier if, for example, there were 
generally agreed upon policy OId's for web server authentication (class 
1/2/3, etc.), email signature validation, etc. I am thinking along the lines 
of the policy OId's defined for the extendedKeyUsage (althought the two 
extensions are used differently in the path validation algorithm) with the 
addition that some generally agreed upon graduation of what policy is implied 
(the class 1, class 2, class 3, etc.).

My second question is therefore; does anyone on this mail list know whether 
such general purpose policy OId's exist (for use with commercial/public 
internet services), or if initiatives to define such Oid's are ongoing? (If 
yes, I would be very interested in some links to the relevant sources.)

Or, is it so that when it comes to, e.g., typical deployments of TLS/SSL over 
the public internet, the certificate policies extension is not seen useful at 
all? What is the general opinion on this from todays CA's?

What I have in mind is that there can be many different applications running 
on top of, say, TLS. If a key usage extension is present in a TLS server 
certificate, then RFC 2246 states what this extension must contain for the 
client to accept the servers certificate. But how can one tell (based on the 
server certificate) whether the server is allowed to use TLS for WEB content, 
only, or for both SMTP and WEB content (thought-up examples)? I was thinking 
that exactly the certificate policies extension could help the client to 
differentiate between these situations. How do todays CA's see this? Is this 
kind of differentiation irrelevant for their trust models?

/bv



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h29EkB611710 for ietf-pkix-bks; Sun, 9 Mar 2003 06:46:11 -0800 (PST)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h29Ek9311705 for <[e-mail]>; Sun, 9 Mar 2003 06:46:09 -0800 (PST)
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.8/8.12.2) with ESMTP id h29Ek3W8114964; Sun, 9 Mar 2003 09:46:03 -0500
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.8/NCO/VER6.5) with ESMTP id h29Ek0dp058132; Sun, 9 Mar 2003 09:46:01 -0500
Subject: Re: basicConstraints with CA=False in EE certs
To: [e-mail] (Peter Gutmann)
Cc: [e-mail], [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
Message-ID: <[e-mail]>
From: Tom Gindin <[e-mail]>
Date: Sun, 9 Mar 2003 09:45:28 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.1 w/SPR JHEG5JQ5CD|February 20, 2003) at 03/09/2003 09:46:02
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Peter:

      The safe procedure for issuers is to issue all v3 EE certificates
with a KeyUsage extension.  It is clearly against the rules for an RP to
treat a certificate with a KeyUsage present which does not contain
keyCertSign as a CA certificate, is it not?  RFC 3280 section 6.1.4 point n
certainly suggests this ("If a key usage extension is present, verify that
the keyCertSign bit is set").  RFC 2459 only enforced this when KeyUsage
was critical.
      IMHO we should recommend that any newly written or released RP
software follow RFC 3280 rather  than RFC 2459 in this respect, because of
the security dangers of allowing a PKIX-compliant EE certificate to act as
an intermediate CA.  We probably already recommend that, but following 2459
in this case is dangerous.

            Tom Gindin



                                                                                                       
                      [e-mail]                                                                
                      nd.ac.nz (Peter          To:       [e-mail],                  
                      Gutmann)                  [e-mail]                                      
                      Sent by:                 cc:                                                     
                      owner-ietf-pkix@m        Subject:  Re: basicConstraints with CA=False in EE      
                      ail.imc.org               certs                                                  
                                                                                                       
                                                                                                       
                      03/06/2003 10:56                                                                 
                      AM                                                                               
                                                                                                       
                                                                                                       





[e-mail] writes:

>ITU-T Rec. X.690 specifies that the default values for an extension should
>not be encoded. Thus, in EE certs where basicConstraints with CA=False is
the
>default, the extension should be omitted at encoding.

You don't omit the extension, you omit the BOOLEAN containing the CA flag,
resulting in a zero-length SEQUENCE, viz:

 543 30    9:         SEQUENCE {
 545 06    3:           OBJECT IDENTIFIER basicConstraints (2 5 29 19)
 550 04    2:           OCTET STRING, encapsulates {
 552 30    0:               SEQUENCE {}
            :               }
            :           }

>It is currently common practice, however, for CAs (some, not all) to
encode
>CA=False in the EE cert.

They encode a zero-length SEQUENCE, which is the right thing to do.  From
the
style guide:

  PKIX requires that end entity certificates not have a basicConstraints
  extension, which leaves the handling of the CA status of the certificate
to
  chance.  Several popular applications treat these certificates as CA
  certificates for backwards-compatibility with X.509v1 CA certificates
which
  didn't include basicConstraints, but in practice it's not really possible
to
  determine how these certificates will be treated.  Because of this, it's
not
  possible to issue a PKIX-compliant end entity certificate and know how
it'll
  be treated once it's in circulation.

  The theory behind this usage is that applications should know that a v3
  certificate without basicConstraints defaults to being a non-CA
certificate,
  however (even assuming that applications implemented this), if
  basicConstraints would have been the only extension in the certificate
then
  defaulting to leaving it out would make it a v1 certificate as required
by
  PKIX, so the v1 rules would apply.  To get the required processing, the
  certificate would have to be marked as v3 even though it's v1 (and the
  application processing it would have to know about the expected
behaviour).
  In any case it's a somewhat peculiar use of the certificate version
number
  field to convey certificate constraint information.

  One use for this feature is that it may be used as a cryptographically
strong
  random number generator.  For each crypto key an application would issue
128
  basicConstraint-less certificates, hand them out to different
  implementations/users, and use their CA/non-CA interpretation as one bit
of a
  session key.  This should yield close to 128 bits of pure entropy in each
  key.

>So, is anyone dealing with this conflict ? ie, at some point in the near
>future are we going to get an update to X.690 which says you *should*
encode
>basicConstraints with CA=False in EE certs or are ITU waiting for i)
>Microsoft to fix their CSP and ii) V*risign to reissue all of their EE
certs
>which contain this encoding ?

There are certain things in standards where the implementors know that you
ignore the standard and do what works instead.  This is one of them (the
Style
Guide exists to document this implementation folklore, although it really
needs updating).

>Your thoughts are appreciated. The most up-to-date status of this problem
>would be of use to us.

See above.  That's been in the Style Guide for, I guess, about 5 years or
so,
things haven't changed since then (I doubt the standards are going to
change
to reflect reality, and reality certainly isn't going to change to reflect
the
standards).

Peter.






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h28KiGL11946 for ietf-pkix-bks; Sat, 8 Mar 2003 12:44:16 -0800 (PST)
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h28KiC311942 for <[e-mail]>; Sat, 8 Mar 2003 12:44:12 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailc.telia.com (8.12.8/8.12.8) with SMTP id h28Ki5EB007053; Sat, 8 Mar 2003 21:44:05 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <008801c2e5b1$fd603cf0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, "Jimi Thompson" <[e-mail]>
References: <[e-mail]> <a05200f04ba8fe3a33a37@[10.10.10.2]>
Subject: Re: The IETF 56 - PKIX Agenda
Date: Sat, 8 Mar 2003 21:33:28 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: 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 Jimi,
Actually we have a non-kindergarten problem as well.  That there is
no agenda unfortunately also describes the state of PKIX and its
leadership.  PKIX have many items in the workings that have not
been properly pitted against other solutions and therefore probably
never will get any real support.

One of these things is the PI (permanent identifier) draft, which is
unique in the sense that it does not support *any* existing CAs using such
schemes.  What's even more odd is that the authors and Dr. Kent are
proud of that, due to some more or less religious beliefs that the "market"
(only in Scandinavia encompassing some 10-15M subscribers) are
deliberately violating PKI standards.  That these CAs are 100%
compliant with RFC3039,  Dr. Kent claims depends on that the RFC
authors were PAID by the CAs to make this RFC compliant to their
"lousy" scheme.  But if  RFC3039 were incorrect it should never have 
passed the RFC process.  But no one said a word.  As at least one of
the RFC authors is a top scientist, I rather think that it is Dr. Kent and
his tired lot, that are simply obstructing progress for reasons unknown
to me.

Anders

----- Original Message ----- 
From: "Jimi Thompson" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Saturday, March 08, 2003 19:19
Subject: Re: The IETF 56 - PKIX Agenda



Hmmm.....you realize of course that we have a far more interesting 
phenomenon to study here.  It seems that certain of the PKIX member 
have been suddenly time warped back to kindergarten.  We need to do 
three things - 1) figure out how to get them back,  2) figure out how 
to make money off this thing (I'm thinking pay-per-view) and 3) here 
in the States we don't use custard, we use Jello since it's cheaper.


>"Anders Rundgren" <[e-mail]> writes:
>
>>In the absence of a published agenda I take the liberty to create one which I
>>think could gather some interest :-)
>
>You forgot the main event:
>
>   What needs to be done to make PKI work?
>
>   This forum will be open to all PKIX members, and will constitute a large
>   pool filled knee-deep with custard [1].  Marquis of Queensberry Rules, but
>   with pies substituted for gloves.  Participants are expected to provide
>   appropriate clothing.  Remaining IETF members will look on in amusement or
>   dismay, depending on their views on PKI.
>
>Peter.
>
>[1] Adrian Mitchell fans may hold the event in the Royal Albert Hall instead.


-- 
Thanks,

Ms. Jimi Thompson, CISSP, Rev.

"If the automobile had followed the same development cycle as the 
computer, a Rolls-Royce would today cost $100, get a million miles 
per gallon, and explode once a year, killing everyone inside." -- 
Robert Cringely



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h28IMle04381 for ietf-pkix-bks; Sat, 8 Mar 2003 10:22:47 -0800 (PST)
Received: from smtpauth2-ext.prodigy.net (smtpauth2-ext.prodigy.net [207.115.63.116]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h28IMf304362 for <[e-mail]>; Sat, 8 Mar 2003 10:22:41 -0800 (PST)
Received: from [10.10.10.2] (crtntx1-ar1-4-60-255-009.crtntx1.dsl-verizon.net [4.60.255.9]) (authenticated) by smtpauth2-ext.prodigy.net (8.11.0/8.11.0) with ESMTP id h28IMbc342208; Sat, 8 Mar 2003 13:22:37 -0500
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05200f04ba8fe3a33a37@[10.10.10.2]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Sat, 8 Mar 2003 12:19:11 -0600
To: [e-mail] (Peter Gutmann), [e-mail], [e-mail]
From: Jimi Thompson <[e-mail]>
Subject: Re: The IETF 56 - PKIX Agenda
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>

Hmmm.....you realize of course that we have a far more interesting 
phenomenon to study here.  It seems that certain of the PKIX member 
have been suddenly time warped back to kindergarten.  We need to do 
three things - 1) figure out how to get them back,  2) figure out how 
to make money off this thing (I'm thinking pay-per-view) and 3) here 
in the States we don't use custard, we use Jello since it's cheaper.


>"Anders Rundgren" <[e-mail]> writes:
>
>>In the absence of a published agenda I take the liberty to create one which I
>>think could gather some interest :-)
>
>You forgot the main event:
>
>   What needs to be done to make PKI work?
>
>   This forum will be open to all PKIX members, and will constitute a large
>   pool filled knee-deep with custard [1].  Marquis of Queensberry Rules, but
>   with pies substituted for gloves.  Participants are expected to provide
>   appropriate clothing.  Remaining IETF members will look on in amusement or
>   dismay, depending on their views on PKI.
>
>Peter.
>
>[1] Adrian Mitchell fans may hold the event in the Royal Albert Hall instead.


-- 
Thanks,

Ms. Jimi Thompson, CISSP, Rev.

"If the automobile had followed the same development cycle as the 
computer, a Rolls-Royce would today cost $100, get a million miles 
per gallon, and explode once a year, killing everyone inside." -- 
Robert Cringely


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h289wJr05676 for ietf-pkix-bks; Sat, 8 Mar 2003 01:58:19 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h289wH305667 for <[e-mail]>; Sat, 8 Mar 2003 01:58:18 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.8/8.12.8) with ESMTP id h289wCZF018254; Sat, 8 Mar 2003 22:58:12 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h289wDO23606; Sat, 8 Mar 2003 22:58:13 +1300
Date: Sat, 8 Mar 2003 22:58:13 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: The IETF 56 - PKIX Agenda
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>In the absence of a published agenda I take the liberty to create one which I
>think could gather some interest :-)

You forgot the main event:

  What needs to be done to make PKI work?
  
  This forum will be open to all PKIX members, and will constitute a large
  pool filled knee-deep with custard [1].  Marquis of Queensberry Rules, but
  with pies substituted for gloves.  Participants are expected to provide
  appropriate clothing.  Remaining IETF members will look on in amusement or
  dismay, depending on their views on PKI.

Peter.

[1] Adrian Mitchell fans may hold the event in the Royal Albert Hall instead.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h288sKq27366 for ietf-pkix-bks; Sat, 8 Mar 2003 00:54:20 -0800 (PST)
Received: from mailc.telia.com (mailc.telia.com [194.22.190.4]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h288sJ327358 for <[e-mail]>; Sat, 8 Mar 2003 00:54:19 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailc.telia.com (8.12.8/8.12.8) with SMTP id h288sEEB021843 for <[e-mail]>; Sat, 8 Mar 2003 09:54:14 +0100 (CET)
X-Original-Recipient: <[e-mail]>
Message-ID: <005c01c2e54e$cfab1220$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: The IETF 56 - PKIX Agenda
Date: Sat, 8 Mar 2003 09:43:37 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: 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 absence of a published agenda I take the liberty to
create one which I think could gather some interest :-)

The Warranty Extension:
  The authors describe the underlying software support
  implied by the proposed extension.   2 hours minimum!

Attribute Certificate Policy Extensions:
  Denis Pinkas describes the rationale for introducing an extension
  to something that essentially have no user support in itself.
  This one should be a real quickie!

The X.509 Style Guide:
  Peter Gutman demonstrates the "consensus" of the PKI community,
  and what works and what don't.
  Peter seems like a fun guy so we give him an hour!

Rationale for Plug-and-Play PKI for Web Services:
  Yours truly gives you some food for thought to why business system
  vendors' still don't have a clue on how to fit PKI to their products.
  As I can go on literally forever, you will probably have to throw me out. :-)

cheers,
Anders R








Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27IOJv09218 for ietf-pkix-bks; Fri, 7 Mar 2003 10:24:19 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27IOI309212 for <[e-mail]>; Fri, 7 Mar 2003 10:24:18 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA07585; Fri, 7 Mar 2003 19:24:19 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Fri, 7 Mar 2003 19:24:19 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id TAA21417; Fri, 7 Mar 2003 19:24:18 +0100 (MET)
Date: Fri, 7 Mar 2003 19:24:18 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Trivial PKI Question
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Were you planning to attend this IETF meeting? If so then you have a 
> legitimate desire to see the agenda as soon as possible. 
 
I think that is a desirable to have an agenda available
early enough before a meeting for everybody who participates
in the working group, and not only if you intend to come to
the meeting. This may allow people to contact meeting  participants 
to make comments on behalf of them or to make a contribution on the 
mailing list or to choose to come, to justify the travel, etc. 

Agenda points requests can also get lost, and this is not exactly
nice if you discover this almost during a meeting. 

Regards
Peter 





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27HLKR07306 for ietf-pkix-bks; Fri, 7 Mar 2003 09:21:20 -0800 (PST)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27HLA307297 for <[e-mail]>; Fri, 7 Mar 2003 09:21:18 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h27HL15w013409; Fri, 7 Mar 2003 12:21:06 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100304ba8e5ee614f5@[128.89.88.34]>
In-Reply-To: <008201c2e476$2f792ea0$0500a8c0@arport>
References: <035501c2e1ce$1c5e2640$0500a8c0@arport> <p05100311ba8d57362102@[128.89.88.34]> <008201c2e476$2f792ea0$0500a8c0@arport>
Date: Fri, 7 Mar 2003 12:13:46 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Trivial PKI Question
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 7:52 AM +0100 3/7/03, Anders Rundgren wrote:
>Steve Kent wrote:
>
><snip of a ton of mostly only patronizing lines>
>
>    >any time someone uses the term "frictionless" I know we've moved into
>    >marketing hype land.
>
>To this private list of Dr. Kent's no-words we should also add 
>"existing practices",
>"simplicity", "scalability", "plug-and-play", "business-system", "XML-based",
>"VeriSign", "Microsoft", and most of all "the market".

I realize that English is not your native language, and thus I do 
applaud your generally excellent use of English. Let me help clarify 
some of the subtleties that seem to be confusing, based on the text 
above:

	- "Exitsing practices" is a fine phrase, but it is sometimes 
used by folks to avoid changes to paradigms with which they feel 
comfortable. So, depending on how one uses it, the phrase might be a 
good reason for a design choice, or a defense against an appropriate 
paradigm shift.

	- "Simplicity" and "scaleability" are over-used, generally 
not quantifiable, and usually trite terms on the verge of being 
buzzwords. The phrase "plug-and-play" is certainly a buzz phrase, and 
more appropriately rendered as "plug and pray" in many instances.

	- Proper names of companies are just that, even when spelled 
using the poly-capitalized form that became so trendy in the 90's.

	- "XML-based" is potentially an accurate description of a 
technology, but it confers no intrinsic goodness.

	- "Market" is a term often used by people in an attempt to 
lend weight to their positions, when no technical justification for 
such positions exists. It too could be a neutral, useful term, but 
its misuse renders it questionable in many contexts.

Hopefully this brief tutorial will help your writing in the future.

>
>    >Oh. This is just another advertisement for your notions on how to
>    >"fix" everything that is "wrong" with X.509.
>
>By adding a minute constraint extension on top of RFC3280, PKI can
>technically be converted from being an n-level structure of arbitrary
>complexity, into a 2-level self-describing structure.

Is the preceding string of words intended to convey some meaning?

>But as "simplicity" is like a red blanket to Dr. Kent, he insists only
>promoting technically broken stuff like the PI, which obviously was
>engineered by looking at the world through a microscope.

Simplicity is hardly a panacea, though it is a desirable feature. On 
the other hand, some things that are promoted as simple as just 
simplistic.

>
>   >Nevermind,
>
>I don't.  I rather support Phill's statement that it is time for you and PKIX
>to wrap-up and close the show.  "The thrill is gone".  It is BTW only two
>weeks to the next IETF, and you have even have not even managed to create
>an agenda for PKIX.  http://www.ietf.org/meetings/wg_agenda_56.html
>

Were you planning to attend this IETF meeting? If so then you have a 
legitimate desire to see the agenda as soon as possible. If not, then 
your comment is just sniping, offered by someone who has never 
contributed constructively to any PKIX effort. Tim is responsible for 
the agenda, and I'm sure your concern will be noted by him.

More broadly, if you believe PKIX is not providing utility then feel 
free to not participate in the WG activities, rather than wasting the 
time of WG members. The message that prompted my response exhibited 
very sloppy analysis which was contrived to promote your pet project 
as a solution. I provided a detailed critique of the errors and 
omissions in the message, to which you did not respond. Instead, your 
response merely tries to argue that YOU know what the market wants 
and YOU have THE solution. That seems to be typical form of your 
messages to this list, hence my characterization of you not 
contributing constructively.

Maybe there is a problem that is important and for which you have a 
good solution. Unfortunately, you have repeatedly failed to do a good 
job of characterizing the problem. Instead, you have emphasized your 
proposed solution. We don't need solutions looking for problems, 
especially when your solutions conflict with existing PKIX standards 
track efforts.

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27GAbu00939 for ietf-pkix-bks; Fri, 7 Mar 2003 08:10:37 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27GAY300934 for <[e-mail]>; Fri, 7 Mar 2003 08:10:35 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h27GAA803396 for <[e-mail]>; Fri, 7 Mar 2003 16:10:10 GMT
Received: from  ([10.153.25.53]) by Baltimore-FW1; Fri, 07 Mar 2003 16:06:23 +0000 (GMT)
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Fri, 7 Mar 2003 16:10:27 +0000
Received: from  ([10.153.25.10]) by Baltimore-FW1; Fri, 07 Mar 2003 16:06:21 +0000 (GMT)
Received: from baltimore.ie (wks165-4.ie.baltimore.com [10.153.4.165]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA27338 for <[e-mail]>; Fri, 7 Mar 2003 16:10:30 GMT
Message-ID: <[e-mail]>
Date: Fri, 07 Mar 2003 16:10:00 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: [Fwd: RFC3281 erratum]
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>

All,

We've been informed that the definition of Clearance in the
AC profile managed to get out of whack with that in X.501.

I've just posted the following erratum notice to the RFC
editor, who keeps such things at [1].

If you have an AC implementation which handles Clearance
attirbutes this affects you, otherwise, go right ahead and 
ignore this,
Regards,
Stephen.

[1] http://www.rfc-editor.org/errata.html

Stephen Farrell wrote:
> 
> Dear RFC editor,
> 
> Could you please post the following additional erratum for RFC2381.
> 
> Thank you,
> Stephen.
> 
> RFC2381, sections 4.4.6 and Appendix B contain a definition of
> Clearance which is incompatible with the latest X.501 definition
> of the same type. The two types were intended to be identical.
> 
> RFC3281 defines clearance as follows:
> 
>    Clearance ::= SEQUENCE {
>            policyId            [0] OBJECT IDENTIFIER,
>            classList           [1] ClassList DEFAULT {unclassified},
>            securityCategories  [2] SET OF SecurityCategory OPTIONAL
>    }
> 
> Whereas X.501 currently defines Clearance as follows:
> 
>    Clearance ::= SEQUENCE {
>            policyId            OBJECT IDENTIFIER,
>            classList           ClassList DEFAULT {unclassified},
>            securityCategories  SET OF SecurityCategory OPTIONAL
>    }
> 
> The differences in tagging arose due to an unnoticed technical
> corrigendum (TC-2) being applied to the X.501 document during
> preparation of RFC3281.
> 
> The X.501 format is the correct form and will be included in
> a future update of RFC3281.
> 
> Implementers SHOULD modify their decoding functions to accept
> either format and, even if claiming RFC3281 conformance, SHOULD
> output the (correct) X.501 format pending the issuing of a corrected
> RFC at which point the incorrect RFC3281 format will no longer be
> specified.
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) [phone]
> 39 Parkgate Street,                     fax: [phone]
> Dublin 8.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27Eugt26450 for ietf-pkix-bks; Fri, 7 Mar 2003 06:56:42 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27Eue326446 for <[e-mail]>; Fri, 7 Mar 2003 06:56:41 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07296; Fri, 7 Mar 2003 09:54:34 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-10.txt
Date: Fri, 07 Mar 2003 09:54:34 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure: 
			  Logotypes in X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-10.txt
	Pages		: 21
	Date		: 2003-3-6
	
This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
Please send comments on this document to the [e-mail]
mailing list.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-logotypes-10.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-logotypes-10.txt

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h27AoRb07328 for ietf-pkix-bks; Fri, 7 Mar 2003 02:50:27 -0800 (PST)
Received: from smtp.telenordia.se (franklin.telenor.se [213.150.135.136]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h27AoN307322 for <[e-mail]>; Fri, 7 Mar 2003 02:50:24 -0800 (PST)
Received: from  webmail4 (webmail4.tninet.se [62.127.77.119]) by franklin.telenor.se (BMR ErlangTM/OTP 3.1) with ESMTP id 731507.34217.1047.0s15464033franklin ; Fri, 07 Mar 2003 11:50:17 +0100
Message-ID: <203065615.1047034217831.JavaMail.webmail@webmail4>
Date: Fri, 7 Mar 2003 11:50:17 +0100 (MET)
From: Henrik Bergman <[e-mail]>
To: [e-mail]
Subject: Buyer cert
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Authenticated-User: [e-mail] (simpson.svenskaspel.se)
X-Mailer: Telenordia Webmail
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h27AoQ307324
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dom har ringt om ditt buyer-cert nu.

Så det bör vara på g. tror det var från S.Afr.

/Henrik
___________________________________________________
[e-mail] 
mob [phone]



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2773bS03654 for ietf-pkix-bks; Thu, 6 Mar 2003 23:03:37 -0800 (PST)
Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2773Z303643 for <[e-mail]>; Thu, 6 Mar 2003 23:03:36 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by maila.telia.com (8.12.8/8.12.8) with SMTP id h2773WqS000634; Fri, 7 Mar 2003 08:03:32 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <008201c2e476$2f792ea0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <035501c2e1ce$1c5e2640$0500a8c0@arport> <p05100311ba8d57362102@[128.89.88.34]>
Subject: Re: Trivial PKI Question
Date: Fri, 7 Mar 2003 07:52:56 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve Kent wrote:

<snip of a ton of mostly only patronizing lines>

   >any time someone uses the term "frictionless" I know we've moved into 
   >marketing hype land.

To this private list of Dr. Kent's no-words we should also add "existing practices",
"simplicity", "scalability", "plug-and-play", "business-system", "XML-based",
"VeriSign", "Microsoft", and most of all "the market".

   >Oh. This is just another advertisement for your notions on how to 
   >"fix" everything that is "wrong" with X.509.

By adding a minute constraint extension on top of RFC3280, PKI can
technically be converted from being an n-level structure of arbitrary
complexity, into a 2-level self-describing structure.

But as "simplicity" is like a red blanket to Dr. Kent, he insists only
promoting technically broken stuff like the PI, which obviously was
engineered by looking at the world through a microscope.

  >Nevermind,

I don't.  I rather support Phill's statement that it is time for you and PKIX
to wrap-up and close the show.  "The thrill is gone".  It is BTW only two
weeks to the next IETF, and you have even have not even managed to create
an agenda for PKIX.  http://www.ietf.org/meetings/wg_agenda_56.html

Anders










Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h274sIs29202 for ietf-pkix-bks; Thu, 6 Mar 2003 20:54:18 -0800 (PST)
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h274sG329196 for <[e-mail]>; Thu, 6 Mar 2003 20:54:17 -0800 (PST)
Received: from tsg1 (unknown[12.81.120.155]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003030704541211100m2akae>; Fri, 7 Mar 2003 04:54:13 +0000
Message-ID: <00b101c2e465$8e325bd0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Jean-Marc Desperrier" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]> <005a01c2e25f$74576410$020aff0a@tsg1> <[e-mail]> <020b01c2e347$ede7f4a0$020aff0a@tsg1> <[e-mail]>
Subject: Re: RFC3161(TSP): doubts about whole thing...
Date: Thu, 6 Mar 2003 20:51:13 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message -----
From: "Jean-Marc Desperrier" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, March 06, 2003 5:28 PM
Subject: Re: RFC3161(TSP): doubts about whole thing...


>
> todd glassey wrote:
>
> >- PLEASE BE VERY SPECIFIC -
> >
> Why should I ?
> You are asking me to oppose RFC3161 token with DB Time Data blob which I
> never intended to do.
>
> DB Time Data blob have their use and will never be replaced by RFC3161
> tokens in most contexts.
> If the way you generate your DB time stamp offers enough garanty for you
> needs, then it can not be beaten.
>
> The only think a RFC3161 token adds to a time data is a signature, and
> the real interest of that signature is to get an independent third party
> involved.
> Only some specific application will really need to get a third party
> involved.
> The second advantage is off-line checking.

How so - What is the difference is reviewing logs automatically and
processing a token to see if it's math holds up?

>
> If you'd restrict yourself to the cases where you can contact the third
> party on-line for checking, you could do only with records and no
signature.
> But it's very convenient to be able to check off-line.

The point of the token was to be of an evidentiary grade substance and such
that machiens could do "legal" things. But maybe that is not what is
needed - perhaps what is really needed is standards on how thes environments
around the transaction-envelope is to be managed. Then the proofing model
for the trust elements is much simpler to deal with. So now - with that
said - why do I need PKI based TST's at all?

The only answer was that by using PKI-enhanced TST's I can get the
transactional event granularity down to a single event or set of policy
decisions (this is the audit perspecitve of it).

> If you are such a professional third party, you will like that most of
> the checking is done off-line, without being overloaded by the load of
> all the people constantly checking the data (this load has a cost, it
> might be a very high one).

This is an assumption and its with this and many more assumptions that the
TSA was born. The problem is that we did not interact with the people that
would have to rely on this data service so we didnt understand that there is
really no difference in the quality of the transaction model whether the
PKI-TST is used or just plain time data is used. That's why the TST's
themselves need so much external data to reinforce or substantiate their
validity.

If we had looked at this better and understood that all that was needed was
an Evidentiary Receipt Standard and a method of representing that in a
smaller hashed data structure and this would have been done and put to bet
years ago.

> For this kind of use, the overload of the 3161 token is not very
> significant, but the added convenience is.

Nope - not from the bigger picture - stop looking at the use of the token as
a developer and start as someone looking for flaws in the external
transaction model or was to improve it. Then tell me what and why with
RFC3161 and I will listen.
>
>

I still think that RFC3161 - I am not in favor of trashing it - too much
work has gone into it - and it should be maintained but not as the IETF's
only time stamping standard.

NTP is now better that it ever was for these services and essentially can
provide similar TS generation facilities but has the added benefits of being
a real timing protocol. There are hundreds of millions of copies of it world
wide so it is ubiquitous in nature and TSA/TSP is not by comparison.  Also -
making NTP evidentiary in nature is inherently simpler than creating a new
TST from scratch - but hey who am I to say...

Todd



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h271XTb23917 for ietf-pkix-bks; Thu, 6 Mar 2003 17:33:29 -0800 (PST)
Received: from smtpauth2-ext.prodigy.net (smtpauth2-ext.prodigy.net [207.115.63.116]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h271XR323913 for <[e-mail]>; Thu, 6 Mar 2003 17:33:27 -0800 (PST)
Received: from [10.10.10.2] (crtntx1-ar1-4-60-255-009.crtntx1.dsl-verizon.net [4.60.255.9]) (authenticated) by smtpauth2-ext.prodigy.net (8.11.0/8.11.0) with ESMTP id h271XJc275204; Thu, 6 Mar 2003 20:33:19 -0500
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <a05200f14ba8da45c0932@[10.10.10.2]>
In-Reply-To: <00e401c2e3c1$30ad4410$0500a8c0@arport>
References:  <[e-mail]> <00e401c2e3c1$30ad4410$0500a8c0@arport>
Date: Thu, 6 Mar 2003 19:30:24 -0600
To: "Anders Rundgren" <[e-mail]>, "Roger Younglove" <[e-mail]>
From: Jimi Thompson <[e-mail]>
Subject: Re: Trivial PKI Question
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:17 AM +0100 3/6/03, Anders Rundgren wrote:
>Roger,
>
>This "works" in the paper-world as people are "flexible".  Automated
>>>receivers OTOH are very unlikely to be able handle arbitrary schemes.
>>>Using a business system as a mid-tier eliminates the need to move the
>>>arbitrary-ness of the paper-world into the e-world.
>
>>**RY it will also work in the e-world as only specified digital signatures
>>will be accepted on order forms from specific companies.
>
>If we now try to scale-up the partner network to the size of major
>manufacturers with tenth of thousands of suppliers, how exactly
>is this going to work?  "Only specified digital signatures" sounds
>very much as out-of-band, small scale etc.  How should an automated
>process be able to cope with that?
>
>>>As as final note, I would like to express a whish that the S/MIME and
>>>PKIX WGs start looking a bit above the ASN.1-level, to also address
>>>deployment issues and shrink-wrap SW support.
>
>>**RY If I understand the role of the IETF WGs correctly it is not with
>>in our area to do those things.
>
>One can note that the only PKIs working on a global scale, are building
>on a one-to-one identity mapping between the entity's perceived identity
>and the identity as expressed in the certificate.  Yes, I of course refer to
>e-mail and web-server certificates.   Other aspiring users of PKI, like
>e-commerce, have not even *begun* to look into the naming issue as
>apparently nobody feels that it is "their business".  Who are we waiting for?
>The IETF, OASIS, W3C, EU, or the UN?   Or are we maybe waiting for
>Microsoft and VeriSign?  I believe the two latter will do this 4US as the
>standards committees seem to be out of ideas, direction, competence and
>ambitions.  We will some time in the future, be discussing in this very list,
>the s.c. "completely broken MS/VS-scheme", that then will be the de-facto
>PKI naming standard.  :-)


I personally have observed the absolute mess Microsoft and Verisign 
have made of things.  They are, as are most corporation, motivated by 
profit.  They just happen to be a bit more motivated than most.  I 
don't want to see them setting any kind of a de-facto standard.  I'll 
gladly work on the naming issue.


-- 
Thanks,

Ms. Jimi Thompson, CISSP, Rev.

"If the automobile had followed the same development cycle as the 
computer, a Rolls-Royce would today cost $100, get a million miles 
per gallon, and explode once a year, killing everyone inside." -- 
Robert Cringely


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h271R3823787 for ietf-pkix-bks; Thu, 6 Mar 2003 17:27:03 -0800 (PST)
Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h271R2323783 for <[e-mail]>; Thu, 6 Mar 2003 17:27:02 -0800 (PST)
Received: from free.fr (136.107-30-212.9massy1-1-ro-as-i4-2.9tel.net [212.30.107.136]) by ioskeha.hittite.isp.9tel.net (Postfix) with ESMTP id BF4CF17B458 for <[e-mail]>; Fri,  7 Mar 2003 02:27:33 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 07 Mar 2003 02:28:43 +0100
From: Jean-Marc Desperrier <[e-mail]>
Organization: totalement desorganise
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030129
X-Accept-Language: en-us, en, fr, fr-fr, ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: RFC3161(TSP): doubts about whole thing...
References: <[e-mail]> <[e-mail]> <005a01c2e25f$74576410$020aff0a@tsg1> <[e-mail]> <020b01c2e347$ede7f4a0$020aff0a@tsg1>
In-Reply-To: <020b01c2e347$ede7f4a0$020aff0a@tsg1>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

todd glassey wrote:

>- PLEASE BE VERY SPECIFIC -
>
Why should I ?
You are asking me to oppose RFC3161 token with DB Time Data blob which I 
never intended to do.

DB Time Data blob have their use and will never be replaced by RFC3161 
tokens in most contexts.
If the way you generate your DB time stamp offers enough garanty for you 
needs, then it can not be beaten.

The only think a RFC3161 token adds to a time data is a signature, and 
the real interest of that signature is to get an independent third party 
involved.
Only some specific application will really need to get a third party 
involved.
The second advantage is off-line checking.

If you'd restrict yourself to the cases where you can contact the third 
party on-line for checking, you could do only with records and no signature.
But it's very convenient to be able to check off-line.
If you are such a professional third party, you will like that most of 
the checking is done off-line, without being overloaded by the load of 
all the people constantly checking the data (this load has a cost, it 
might be a very high one).
For this kind of use, the overload of the 3161 token is not very 
significant, but the added convenience is.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h26LAjR14265 for ietf-pkix-bks; Thu, 6 Mar 2003 13:10:45 -0800 (PST)
Received: from mx1.pacifier.net (mx1.pacifier.net [64.255.237.181]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26LAi314261 for <[e-mail]>; Thu, 6 Mar 2003 13:10:44 -0800 (PST)
Received: from smtp4.pacifier.net (smtp4 [64.255.237.174]) by mx1.pacifier.net (Postfix) with ESMTP id 4F8566B442; Thu,  6 Mar 2003 13:10:13 -0800 (PST)
Received: from revelation (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id 7AECC6A42A; Thu,  6 Mar 2003 12:52:54 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt
Date: Thu, 6 Mar 2003 13:07:30 -0800
Message-ID: <002c01c2e424$673a1310$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

Yes the parameters are the same, however the second structures are not
the same.  A signature value and the key do not have the same structure.
I also index these structures based on the OID value.

jim

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]] 
> Sent: Thursday, March 06, 2003 11:04 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt
> 
> 
> Jim:
> 
> In my proposal, the parameters are exactly the same.  So, the 
> same table, 
> with the same index, can be used.
> 
> Russ
> 
> At 10:43 PM 3/2/2003 -0800, Jim Schaad wrote:
> >Russ,
> >
> >As an implementer, I think of dealing not only with the 
> parameters but
> >the "data" value associated with the OID as being dependent 
> on the OID.
> >This means that the following items are indexed on the OID.  The
> >parameters structure, the public key encoding and the signature value
> >encoding.  In the case of RSA the signature value encoding is really
> >simple - i.e. just the bytes - but for some signature 
> algorithms this is
> >not true.  The fewer tables that I have to do lookups on the 
> easer it is
> >to write general purpose code.  I would be perfectly happen 
> to assign a
> >different OID for each different way that the encodings and 
> mathematics
> >are done.
> >
> >A different question is whether the parameters should be different
> >between the different locations.  I agree that there should be a
> >restriction on only using PSS with a signature key, however I think
> >there is an interesting question about the requirement for different
> >certificates to be assigned if you want to use both SHA-256 
> and SHA-512
> >with the PSS key depending on the question of necessary 
> duration of the
> >signature.
> >
> >jim
> >
> > > -----Original Message-----
> > > From: Russ Housley [mailto:[e-mail]]
> > > Sent: Monday, February 24, 2003 1:28 PM
> > > To: [e-mail]; [e-mail]
> > > Cc: [e-mail]
> > > Subject: RE: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt
> > >
> > >
> > > Burt & Jim:
> > >
> > > Clearly there are some choices.  I believe that use of the
> > > same object
> > > identifier is the best we can do given the current state of
> > > the world.  The
> > > solution that we devise needs to be backward compatible.  I
> > > do not think
> > > that assigning two OIDs for each possible use of an RSA or
> > > Elliptic Curve
> > > public key is desirable.  We already need to assign one 
> OID for the
> > > signature validation (or key management technique).
> > > Assigning a second OID
> > > for use in the subject public key info to say that the key
> > > can only be used
> > > in a particular manner is only useful if the parameters that
> > > are already
> > > associated with the currently assigned OID do not support the
> > > necessary
> > > information.
> > >
> > > Russ
> > >
> > > >[JS] 7.  Section 3.2.  I would like to see a different 
> OID used for a
> > > >signature value from that used to encode the public key.
> > > This makes it
> > > >easier to process for encode/decode as there are not two
> > > structures with
> > > >the same OID.
> > > >
> > > >[BK] The OID is not used to encode the public key directly,
> > > but to encode an
> > > >AlgorithmID; the AlgorithmID is used to describe the public
> > > key. So, the
> > > >AlgorithmID has two meanings, one for the signature, one for
> > > the public key.
> > > >I agree this is potential problem, and am open to alternatives.
> > >
> 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h26L2vq14092 for ietf-pkix-bks; Thu, 6 Mar 2003 13:02:57 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.6) with SMTP id h26L2u314088 for <[e-mail]>; Thu, 6 Mar 2003 13:02:56 -0800 (PST)
Received: (qmail 19542 invoked from network); 6 Mar 2003 19:07:33 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.179.110) by woodstock.binhost.com with SMTP; 6 Mar 2003 19:07:33 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 06 Mar 2003 14:03:34 -0500
To: <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt
Cc: <[e-mail]>
In-Reply-To: <001401c2e150$388af7e0$[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>

Jim:

In my proposal, the parameters are exactly the same.  So, the same table, 
with the same index, can be used.

Russ

At 10:43 PM 3/2/2003 -0800, Jim Schaad wrote:
>Russ,
>
>As an implementer, I think of dealing not only with the parameters but
>the "data" value associated with the OID as being dependent on the OID.
>This means that the following items are indexed on the OID.  The
>parameters structure, the public key encoding and the signature value
>encoding.  In the case of RSA the signature value encoding is really
>simple - i.e. just the bytes - but for some signature algorithms this is
>not true.  The fewer tables that I have to do lookups on the easer it is
>to write general purpose code.  I would be perfectly happen to assign a
>different OID for each different way that the encodings and mathematics
>are done.
>
>A different question is whether the parameters should be different
>between the different locations.  I agree that there should be a
>restriction on only using PSS with a signature key, however I think
>there is an interesting question about the requirement for different
>certificates to be assigned if you want to use both SHA-256 and SHA-512
>with the PSS key depending on the question of necessary duration of the
>signature.
>
>jim
>
> > -----Original Message-----
> > From: Russ Housley [mailto:[e-mail]]
> > Sent: Monday, February 24, 2003 1:28 PM
> > To: [e-mail]; [e-mail]
> > Cc: [e-mail]
> > Subject: RE: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt
> >
> >
> > Burt & Jim:
> >
> > Clearly there are some choices.  I believe that use of the
> > same object
> > identifier is the best we can do given the current state of
> > the world.  The
> > solution that we devise needs to be backward compatible.  I
> > do not think
> > that assigning two OIDs for each possible use of an RSA or
> > Elliptic Curve
> > public key is desirable.  We already need to assign one OID for the
> > signature validation (or key management technique).
> > Assigning a second OID
> > for use in the subject public key info to say that the key
> > can only be used
> > in a particular manner is only useful if the parameters that
> > are already
> > associated with the currently assigned OID do not support the
> > necessary
> > information.
> >
> > Russ
> >
> > >[JS] 7.  Section 3.2.  I would like to see a different OID used for a
> > >signature value from that used to encode the public key.
> > This makes it
> > >easier to process for encode/decode as there are not two
> > structures with
> > >the same OID.
> > >
> > >[BK] The OID is not used to encode the public key directly,
> > but to encode an
> > >AlgorithmID; the AlgorithmID is used to describe the public
> > key. So, the
> > >AlgorithmID has two meanings, one for the signature, one for
> > the public key.
> > >I agree this is potential problem, and am open to alternatives.
> >



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h26KBPR11473 for ietf-pkix-bks; Thu, 6 Mar 2003 12:11:25 -0800 (PST)
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26KBF311458 for <[e-mail]>; Thu, 6 Mar 2003 12:11:22 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h26KBC5w021613; Thu, 6 Mar 2003 15:11:12 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100311ba8d57362102@[128.89.88.34]>
In-Reply-To: <035501c2e1ce$1c5e2640$0500a8c0@arport>
References: <035501c2e1ce$1c5e2640$0500a8c0@arport>
Date: Thu, 6 Mar 2003 15:07:45 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Trivial PKI Question
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:44 PM +0100 3/3/03, Anders Rundgren wrote:
>A "TRIVIAL" PKI QUESTION
>-----------------------------------
>
>Assume that you have a business message like a purchase order
>
>     <Order>
>         <From name="Big Buyer Corp.">
>             <OurRef name="John Doe"/>
>         </From>
>         <To name="MegaCar International"/>
>         <Item>10 Medium-sized SUVs</Item>
>         <Comment>Make it quick please!</Comment>
>     </Order>
>
>Now assume that "Big Buyer Corp." is an advanced organization
>using digital signatures.
>
>==============================================
>Question:  How should the identity as expressed in the document
>relate to the identity as expressed by the signer's certificate?
>==============================================
>
>Among the complications we find
>
>1.  The PKI-identity is presumably "strong" as it is vouched for by a
>      CA, while the identity in the business document is only "claimed"
>      by the entity itself.  ==> The PKI identity is governing?

Whether the identity in the Subject name is accurate depends on who 
the CA is and whether the CA has vouched for a name for which it is 
authoritative, or whether it has done some checking on the likely 
accuracy of some name for which the CA is not authoritative. So, I 
think we already disagree about one premise of your question.

It is clearly desirable that there be an exact match between a name 
in a cert and the name in the document, IF the authorization policy 
requires that level of authentication. As others have noted, another 
likely scenario is that the RP needs only to know that the cert was 
issued by an organization that will assume liability for the actions 
of the individual to whom the cert is issued, irrespective of the 
specific ID in the cert and in the document.

>2.  The hierarchical naming system used by PKI (X.500) is completely
>      different to the various naming schemes used in businesses.

"completely different" is an odd construct in English, and arguably 
just plain wrong in this contect. If I am issued a cert that has a 
subject name of the form "C=US, O= Verizon, OU= BBN Technologies, CN 
= Stephen Kent" that is a hierarchic name that is readily mapped to 
my identity in my professional context, and thus is is not at all 
"completely different" as you assert.

>3.  Some PKI-folks claim that signatures should be tied to individuals.
>      Does this mean that the signer's certificate in the sample should
>      identify John Doe of Big Buyer Corp.?

Some LAWS require that signatures be tied to individuals in some 
contexts. It's not just a matter of opinions expressed by "PKI 
experts." But, you have not provided a sufficient description of the 
context to determine if there is a problem here or not.

>4.  The receivers (relying parties) are automated processes supposed
>      to securely handle similar messages from numerous business parties.

A reasonable goal.

>5.  Current e-commerce standards like ebXML and Web Services does
>      NOT address this basic question.

You have failed to articulate a well-formed question, so the 
conclusion above is not supported by your arguments.

>My own conclusion is that PKI was created to support e-mail where
>these questions do not arise.  For other types of messaging, PKI in
>its current shape does not scale well, or at least creates as many
>new problems as it was meant to solve existing ones.

Definitely wrong. E-mail security encounters some of the problems you 
allude to above, e.g., the mismatch between the Subject DN and an 
e-mail adddress as a suitable, native ID form.  X.509 v3 addressed 
this problem with the Subject AltName extension and the RFC822address 
name form. But, the assertion above is naive, at best.

>Regarding #1, I believe that most business systems ignore the PKI-
>identity due to #2, #3 and #4.  Although a bit weird, the logic behind
>that is that if an entity having a known key/cert is "lying", they will
>sooner or later get in trouble anyway.  The drawback is that this will
>be found out by a *human*, and usually only *after* a malpractice has
>been performed.

I have no idea what "most business systems" do, but since we often 
see people making poor design choices, I would not be surprised by 
any claims of what may be done. Still, remedial security measures are 
very common in many financial transactions and so we ought not say 
that such an approach is not "secure" absent a more thorough analysis 
of the threat model, etc.

>A LONG-TERM REMEDY
>-------------------------------
>
>To create a foundation for more frictionless PKI-secured e-business,
>I think that there *long-term* should be a one-to-one mapping between
>[basic] business message identities and certificate identities.
>As the business community is never going to adopt X.500 naming, as
>well as having their own naming problems, this will likely require
>changes on both sides.  A possible scheme using the currently only
>globally functioning naming system (DNS/URIs), is that entities are
>uniquely defined by two elements:

any time someone uses the term "frictionless" I know we've moved into 
marketing hype land.

>- A naming domain (name space) based on a URI like: "http://www.visa.com/cc"
>- A local identifier in that domain like: 4555-5555-2244-8888
>
>Although the example identified a credit-card, the scheme works for just
>about any kind of object or entity.  An advantage of using HTTP URIs is
>that you usually can get further information "by clicking on the link".

Oh. This is just another advertisement for your notions on how to 
"fix" everything that is "wrong" with X.509.

Nevermind,

Steve


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h26FuJK26638 for ietf-pkix-bks; Thu, 6 Mar 2003 07:56:19 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26FuH326630 for <[e-mail]>; Thu, 6 Mar 2003 07:56:17 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.8/8.12.8) with ESMTP id h26FuDZF008984; Fri, 7 Mar 2003 04:56:13 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h26FuDQ30918; Fri, 7 Mar 2003 04:56:13 +1300
Date: Fri, 7 Mar 2003 04:56:13 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: basicConstraints with CA=False in EE certs
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[e-mail] writes:

>ITU-T Rec. X.690 specifies that the default values for an extension should
>not be encoded. Thus, in EE certs where basicConstraints with CA=False is the
>default, the extension should be omitted at encoding. 

You don't omit the extension, you omit the BOOLEAN containing the CA flag,
resulting in a zero-length SEQUENCE, viz:

 543 30    9:         SEQUENCE {
 545 06    3:           OBJECT IDENTIFIER basicConstraints (2 5 29 19)
 550 04    2:           OCTET STRING, encapsulates {
 552 30    0:               SEQUENCE {}
            :               }
            :           }

>It is currently common practice, however, for CAs (some, not all) to encode
>CA=False in the EE cert.

They encode a zero-length SEQUENCE, which is the right thing to do.  From the
style guide:

  PKIX requires that end entity certificates not have a basicConstraints
  extension, which leaves the handling of the CA status of the certificate to
  chance.  Several popular applications treat these certificates as CA
  certificates for backwards-compatibility with X.509v1 CA certificates which
  didn't include basicConstraints, but in practice it's not really possible to
  determine how these certificates will be treated.  Because of this, it's not
  possible to issue a PKIX-compliant end entity certificate and know how it'll
  be treated once it's in circulation.

  The theory behind this usage is that applications should know that a v3
  certificate without basicConstraints defaults to being a non-CA certificate,
  however (even assuming that applications implemented this), if
  basicConstraints would have been the only extension in the certificate then
  defaulting to leaving it out would make it a v1 certificate as required by
  PKIX, so the v1 rules would apply.  To get the required processing, the
  certificate would have to be marked as v3 even though it's v1 (and the
  application processing it would have to know about the expected behaviour).
  In any case it's a somewhat peculiar use of the certificate version number
  field to convey certificate constraint information.

  One use for this feature is that it may be used as a cryptographically strong
  random number generator.  For each crypto key an application would issue 128
  basicConstraint-less certificates, hand them out to different
  implementations/users, and use their CA/non-CA interpretation as one bit of a
  session key.  This should yield close to 128 bits of pure entropy in each
  key.

>So, is anyone dealing with this conflict ? ie, at some point in the near
>future are we going to get an update to X.690 which says you *should* encode
>basicConstraints with CA=False in EE certs or are ITU waiting for i)
>Microsoft to fix their CSP and ii) V*risign to reissue all of their EE certs
>which contain this encoding ?

There are certain things in standards where the implementors know that you
ignore the standard and do what works instead.  This is one of them (the Style
Guide exists to document this implementation folklore, although it really
needs updating).

>Your thoughts are appreciated. The most up-to-date status of this problem
>would be of use to us.

See above.  That's been in the Style Guide for, I guess, about 5 years or so,
things haven't changed since then (I doubt the standards are going to change
to reflect reality, and reality certainly isn't going to change to reflect the
standards).

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h26F8VJ23881 for ietf-pkix-bks; Thu, 6 Mar 2003 07:08:31 -0800 (PST)
Received: from mail4.consignia.com (mail.royalmail.com [144.87.143.84]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26F8U323874 for <[e-mail]>; Thu, 6 Mar 2003 07:08:30 -0800 (PST)
Received: from postoffice.co.uk (mta1.int.consignia.com [144.87.146.14]) by mail4.consignia.com (Postfix) with SMTP id 86C171221C8 for <[e-mail]>; Thu,  6 Mar 2003 15:08:30 +0000 (GMT)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256CE1.0052B9C5 ; Thu, 6 Mar 2003 15:03:35 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 6 Mar 2003 15:08:08 +0000
Subject: basicConstraints with CA=False in EE certs
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Apologies if this has been discussed recently. I had a look through
the archive and couldn't find a recent record of it.

There is presently a conflict in the exclusion of basicConstraints with
CA=False in EE certs.

ITU-T Rec. X.690 specifies that the default values for an extension
should not be encoded. Thus, in EE certs where basicConstraints
with CA=False is the default, the extension should be omitted at
encoding. It is currently common practice, however, for CAs (some,
not all) to encode CA=False in the EE cert.

To complicate matters Microsoft Security Bulletin MS02-050 describes
an exploitation whereby unpatched CSPs do not process
basicConstraints at all leaving them vulnerable to ID spoofing attacks
( CAN-2002-0862 ) . This problem is fixed by a patch which enforces
a check on basicConstraints.

The net result is that not only is it desirable to have basicConstraints
encoded but also many already deployed certificate have this encoding
in them anyway despite the ITU recommendation. UA software that
is up-to-date with the recommendation stands to reject a significant
proportion of the deployed user community EE certs.

<pauses for breath>

So, is anyone dealing with this conflict ? ie, at some point in the near
future are we going to get an update to X.690 which says you *should*
encode basicConstraints with CA=False in EE certs or are ITU waiting
for i) Microsoft to fix their CSP and ii) V*risign to reissue all of their EE
certs which contain this encoding ?

Your thoughts are appreciated. The most up-to-date status of this
problem would be of use to us.

Chris

This  email  and  any  attachments  are confidential and intended for the addressee
only.   If  you are not the named recipient, you must not use, disclose, reproduce,
copy  or  distribute the contents of this communication.  If you have received this
in error, please contact the sender and then delete this email from your system.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h26BUsn10239 for ietf-pkix-bks; Thu, 6 Mar 2003 03:30:54 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h26BUr310234 for <[e-mail]>; Thu, 6 Mar 2003 03:30:53 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03361; Thu, 6 Mar 2003 06:28:48 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-sonof3039-00.txt
Date: Thu, 06 Mar 2003 06:28:48 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure:Qualified 
                          Certificates Profile
	Author(s)	: S. Santesson, M. Nystrom
	Filename	: draft-ietf-pkix-sonof3039-00.txt
	Pages		: 35
	Date		: 2003-3-5
	
This document forms a certificate profile, based on RFC 3280, for
dentity certificates issued to physical persons.
The goal of this document is to define a general syntax independent
of local legal requirements.  The profile is however designed to
allow further profiling in order to meet specific local needs.
The profile defines specific conventions for certificates that are
qualified within a defined legal framework, named Qualified
Certificates. The profile does however not define any legal
requirements for such Qualified Certificates.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-sonof3039-00.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-sonof3039-00.txt

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h269S1428341 for ietf-pkix-bks; Thu, 6 Mar 2003 01:28:01 -0800 (PST)
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h269Rx328337 for <[e-mail]>; Thu, 6 Mar 2003 01:28:00 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailf.telia.com (8.12.8/8.12.8) with SMTP id h269Rs9f006506; Thu, 6 Mar 2003 10:27:54 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <00e401c2e3c1$30ad4410$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Roger Younglove" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Trivial PKI Question
Date: Thu, 6 Mar 2003 10:17:20 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Roger,

This "works" in the paper-world as people are "flexible".  Automated
>>receivers OTOH are very unlikely to be able handle arbitrary schemes.
>>Using a business system as a mid-tier eliminates the need to move the
>>arbitrary-ness of the paper-world into the e-world.

>**RY it will also work in the e-world as only specified digital signatures
>will be accepted on order forms from specific companies.

If we now try to scale-up the partner network to the size of major
manufacturers with tenth of thousands of suppliers, how exactly
is this going to work?  "Only specified digital signatures" sounds
very much as out-of-band, small scale etc.  How should an automated
process be able to cope with that?

>>As as final note, I would like to express a whish that the S/MIME and
>>PKIX WGs start looking a bit above the ASN.1-level, to also address
>>deployment issues and shrink-wrap SW support.

>**RY If I understand the role of the IETF WGs correctly it is not with
>in our area to do those things.

One can note that the only PKIs working on a global scale, are building
on a one-to-one identity mapping between the entity's perceived identity
and the identity as expressed in the certificate.  Yes, I of course refer to
e-mail and web-server certificates.   Other aspiring users of PKI, like
e-commerce, have not even *begun* to look into the naming issue as
apparently nobody feels that it is "their business".  Who are we waiting for?
The IETF, OASIS, W3C, EU, or the UN?   Or are we maybe waiting for
Microsoft and VeriSign?  I believe the two latter will do this 4US as the
standards committees seem to be out of ideas, direction, competence and
ambitions.  We will some time in the future, be discussing in this very list,
the s.c. "completely broken MS/VS-scheme", that then will be the de-facto
PKI naming standard.  :-)

rgds
Anders



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h25Ints07154 for ietf-pkix-bks; Wed, 5 Mar 2003 10:49:55 -0800 (PST)
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25Inr307150 for <[e-mail]>; Wed, 5 Mar 2003 10:49:53 -0800 (PST)
Received: from tsg1 (121.sanfrancisco-12rh16rt-ca.dial-access.att.net[12.81.119.121]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003030518494811100dfit8e>; Wed, 5 Mar 2003 18:49:49 +0000
Message-ID: <020b01c2e347$ede7f4a0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Jean-Marc Desperrier" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]> <005a01c2e25f$74576410$020aff0a@tsg1> <[e-mail]>
Subject: Re: RFC3161(TSP): doubts about whole thing...
Date: Wed, 5 Mar 2003 10:49:07 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jean Marc - TST's are only valuable if you can do something with them? so
what is it you would do with them and why? And then tell me why is that any
better than how it (time representation in transactional receipts) is done
today?

And then -  I ask you, if you replaced the timestamps in the massive DB
based applications with these particular TST's -

o-    would it (the use of the RFC3161 TSA/TST)  make the
        sanctity of the data models better?, and if so how?

        x-  would you add them (TSTs) to the record structures?

        x-  would you replace the standard Time Data blob with the TST?

o-    would it (the use of the RFC3161 TSA/TST)
        x-    Would TST use speed up any parts of the processing model, or
                not?

        x-    Would TST use slow down the processing model and if so how
               much? and for what gain?

        x-    Would TST use allow for the data models to stand up in court
                better and if so why (i.e. what is the legal-armor value add
                of using these TST's)

- PLEASE BE VERY SPECIFIC -


Todd


----- Original Message -----
From: "Jean-Marc Desperrier" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, March 04, 2003 11:04 AM
Subject: Re: RFC3161(TSP): doubts about tcp protocol




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h25FnqR25143 for ietf-pkix-bks; Wed, 5 Mar 2003 07:49:52 -0800 (PST)
Received: from hubie.hubbardind.com (mail.hubbardsupply.com [65.245.100.65]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25Fnp325138 for <[e-mail]>; Wed, 5 Mar 2003 07:49:51 -0800 (PST)
Received: by HUBIE.hubbardsupply.com with Internet Mail Service (5.5.2653.19) id <1JGDBHL5>; Wed, 5 Mar 2003 10:49:52 -0500
Message-ID: <[e-mail]>
From: Roger Younglove <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Trivial PKI Question
Date: Wed, 5 Mar 2003 10:49:41 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E32E.D608B1D0"
Sender: [e-mail]
Precedence: 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_01C2E32E.D608B1D0
Content-Type: text/plain

Anders, comments inserted IMHO

Roger Younglove, CISSP, IAM
Principal Consultant
NetWorks Group
O. 810.225.4800 ex. 2245
M. 810.599.0879
E. [e-mail]
www.networksgroup.com
 

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]] 
Sent: Wednesday, March 05, 2003 6:54 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: Trivial PKI Question


Chris,
Thanx for your answers.  Here are some replies.

>> Question:  How should the identity as expressed in the document
>> relate to the identity as expressed by the signer's certificate?

>There may be no relationship at all. Their identity as a private
>individual may be irrelevant, subjugated by their role as the person
>in Big Buyer Corp who authorizes such payments digitally. Also,
>the creator of the order may not be the person who is authorized
>to digitally sign it.

This "works" in the paper-world as people are "flexible".  Automated
receivers OTOH are very unlikely to be able handle arbitrary schemes.
Using a business system as a mid-tier eliminates the need to move the
arbitrary-ness of the paper-world into the e-world.
**RY it will also work in the e-world as only specified digital signatures
will be accepted on order forms from specific companies.

Taken from another field:  I'm pretty sure that no e-government program
will ever consider accepting anything but a one-to-one match between
a citizen's ID (as they see it) and what a citizen certificate contains.
But
they also have to build special purpose RP software (due to the dys-
functional X.500 naming system) in order to do that.  In addition to
requiring CAs to follow their _hard-coded_ naming conventions.

<snip>

> The two are likely to contain different certificatePolicies.

<CertificatePolicyRant>
It is interesting to note that CPSs are frequently mentioned in this context
in spite of the fact that none of the major crypto-packages (Windows
and Java) offers any way to specify CPSs as a part of a CA trust acceptance
process.  The reason for this is simple: Computers don't understand
legal matters and CPSs are deployment-wise anything but standardized.
Peter Gutman's term "Kitchen sink extensions" is a fair description of
the value of CPSs for practical purposes.  Do "SysAdmins" ever
bother about the CPS of their VeriSign web-server certificates?
My Thawt web-server cert does not even have a CPS extension and
I haven't missed it that much. 
**RY CPs and CPSs are not written for electronic review and system ADmins
are not required to see, review or understand them. 
 CPSs were designed by lawyers for lawyers. 
**RY Not totally true. A CP is written for the Relying Party to understand
and agree that the operation of the CA provides the RP the ability to rely
on the certificates. The CPS ensures the RP that the CA meets the operating
requirements of the CP therefore ensuring the reliability of the certificate
used.
 But lawyers do not run e-business systems, write application
software packages, or know how to handle a Java keystore.
**RY that is correct however lawyers are responsible for the liability
incurred by CAs and RPs.
</CertificatePolicyRant>

<snip>

>> To create a foundation for more frictionless PKI-secured e-business,
>> I think that there *long-term* should be a one-to-one mapping between
>> [basic] business message identities and certificate identities.

>A kind of time-stamped intersection entity that comes between person
>and process ? A signed transaction ? Isn't this what Notaries were
>supposed to be for ?

<snip>

As as final note, I would like to express a whish that the S/MIME and
PKIX WGs start looking a bit above the ASN.1-level, to also address
deployment issues and shrink-wrap SW support. 
**RY If I understand the role of the IETF WGs correctly it is not with in
our area to do those things.
 There must be more than
one reason why practically no app outside of e-mail offer built-in PKI
support.

Regards
Anders R




------_=_NextPart_001_01C2E32E.D608B1D0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Trivial PKI Question</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Anders, comments inserted IMHO</FONT>
</P>

<P><FONT SIZE=3D2>Roger Younglove, CISSP, IAM</FONT>
<BR><FONT SIZE=3D2>Principal Consultant</FONT>
<BR><FONT SIZE=3D2>NetWorks Group</FONT>
<BR><FONT SIZE=3D2>O. 810.225.4800 ex. 2245</FONT>
<BR><FONT SIZE=3D2>M. 810.599.0879</FONT>
<BR><FONT SIZE=3D2>E. [e-mail]</FONT>
<BR><FONT SIZE=3D2>www.networksgroup.com</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Anders Rundgren [<A =
HREF=3D"mailto:[e-mail]">mailto:anders.rundgren@telia.c=
om</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, March 05, 2003 6:54 AM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Trivial PKI Question</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Chris,</FONT>
<BR><FONT SIZE=3D2>Thanx for your answers.&nbsp; Here are some =
replies.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt; Question:&nbsp; How should the identity as =
expressed in the document</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; relate to the identity as expressed by the =
signer's certificate?</FONT>
</P>

<P><FONT SIZE=3D2>&gt;There may be no relationship at all. Their =
identity as a private</FONT>
<BR><FONT SIZE=3D2>&gt;individual may be irrelevant, subjugated by =
their role as the person</FONT>
<BR><FONT SIZE=3D2>&gt;in Big Buyer Corp who authorizes such payments =
digitally. Also,</FONT>
<BR><FONT SIZE=3D2>&gt;the creator of the order may not be the person =
who is authorized</FONT>
<BR><FONT SIZE=3D2>&gt;to digitally sign it.</FONT>
</P>

<P><FONT SIZE=3D2>This &quot;works&quot; in the paper-world as people =
are &quot;flexible&quot;.&nbsp; Automated</FONT>
<BR><FONT SIZE=3D2>receivers OTOH are very unlikely to be able handle =
arbitrary schemes.</FONT>
<BR><FONT SIZE=3D2>Using a business system as a mid-tier eliminates the =
need to move the</FONT>
<BR><FONT SIZE=3D2>arbitrary-ness of the paper-world into the =
e-world.</FONT>
<BR><FONT SIZE=3D2>**RY it will also work in the e-world as only =
specified digital signatures will be accepted on order forms from =
specific companies.</FONT></P>

<P><FONT SIZE=3D2>Taken from another field:&nbsp; I'm pretty sure that =
no e-government program</FONT>
<BR><FONT SIZE=3D2>will ever consider accepting anything but a =
one-to-one match between</FONT>
<BR><FONT SIZE=3D2>a citizen's ID (as they see it) and what a citizen =
certificate contains.&nbsp; But</FONT>
<BR><FONT SIZE=3D2>they also have to build special purpose RP software =
(due to the dys-</FONT>
<BR><FONT SIZE=3D2>functional X.500 naming system) in order to do =
that.&nbsp; In addition to</FONT>
<BR><FONT SIZE=3D2>requiring CAs to follow their _hard-coded_ naming =
conventions.</FONT>
</P>

<P><FONT SIZE=3D2>&lt;snip&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&gt; The two are likely to contain different =
certificatePolicies.</FONT>
</P>

<P><FONT SIZE=3D2>&lt;CertificatePolicyRant&gt;</FONT>
<BR><FONT SIZE=3D2>It is interesting to note that CPSs are frequently =
mentioned in this context</FONT>
<BR><FONT SIZE=3D2>in spite of the fact that none of the major =
crypto-packages (Windows</FONT>
<BR><FONT SIZE=3D2>and Java) offers any way to specify CPSs as a part =
of a CA trust acceptance</FONT>
<BR><FONT SIZE=3D2>process.&nbsp; The reason for this is simple: =
Computers don't understand</FONT>
<BR><FONT SIZE=3D2>legal matters and CPSs are deployment-wise anything =
but standardized.</FONT>
<BR><FONT SIZE=3D2>Peter Gutman's term &quot;Kitchen sink =
extensions&quot; is a fair description of</FONT>
<BR><FONT SIZE=3D2>the value of CPSs for practical purposes.&nbsp; Do =
&quot;SysAdmins&quot; ever</FONT>
<BR><FONT SIZE=3D2>bother about the CPS of their VeriSign web-server =
certificates?</FONT>
<BR><FONT SIZE=3D2>My Thawt web-server cert does not even have a CPS =
extension and</FONT>
<BR><FONT SIZE=3D2>I haven't missed it that much. </FONT>
<BR><FONT SIZE=3D2>**RY CPs and CPSs are not written for electronic =
review and system ADmins are not required to see, review or understand =
them. </FONT></P>

<P><FONT SIZE=3D2>&nbsp;CPSs were designed by lawyers for lawyers. =
</FONT>
<BR><FONT SIZE=3D2>**RY Not totally true. A CP is written for the =
Relying Party to understand and agree that the operation of the CA =
provides the RP the ability to rely on the certificates. The CPS =
ensures the RP that the CA meets the operating requirements of the CP =
therefore ensuring the reliability of the certificate used.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;But lawyers do not run e-business systems, =
write application</FONT>
<BR><FONT SIZE=3D2>software packages, or know how to handle a Java =
keystore.</FONT>
<BR><FONT SIZE=3D2>**RY that is correct however lawyers are responsible =
for the liability incurred by CAs and RPs.</FONT>
<BR><FONT SIZE=3D2>&lt;/CertificatePolicyRant&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&lt;snip&gt;</FONT>
</P>

<P><FONT SIZE=3D2>&gt;&gt; To create a foundation for more frictionless =
PKI-secured e-business,</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; I think that there *long-term* should be a =
one-to-one mapping between</FONT>
<BR><FONT SIZE=3D2>&gt;&gt; [basic] business message identities and =
certificate identities.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;A kind of time-stamped intersection entity that =
comes between person</FONT>
<BR><FONT SIZE=3D2>&gt;and process ? A signed transaction ? Isn't this =
what Notaries were</FONT>
<BR><FONT SIZE=3D2>&gt;supposed to be for ?</FONT>
</P>

<P><FONT SIZE=3D2>&lt;snip&gt;</FONT>
</P>

<P><FONT SIZE=3D2>As as final note, I would like to express a whish =
that the S/MIME and</FONT>
<BR><FONT SIZE=3D2>PKIX WGs start looking a bit above the ASN.1-level, =
to also address</FONT>
<BR><FONT SIZE=3D2>deployment issues and shrink-wrap SW support. =
</FONT>
<BR><FONT SIZE=3D2>**RY If I understand the role of the IETF WGs =
correctly it is not with in our area to do those things.</FONT>
<BR><FONT SIZE=3D2>&nbsp;There must be more than</FONT>
<BR><FONT SIZE=3D2>one reason why practically no app outside of e-mail =
offer built-in PKI support.</FONT>
</P>

<P><FONT SIZE=3D2>Regards</FONT>
<BR><FONT SIZE=3D2>Anders R</FONT>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C2E32E.D608B1D0--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h25C4Dg12001 for ietf-pkix-bks; Wed, 5 Mar 2003 04:04:13 -0800 (PST)
Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25C49311996 for <[e-mail]>; Wed, 5 Mar 2003 04:04:09 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailf.telia.com (8.12.8/8.12.8) with SMTP id h25C47cP004500; Wed, 5 Mar 2003 13:04:07 +0100 (CET)
X-Original-Recipient: [e-mail]
Message-ID: <00b501c2e30d$d9d28e10$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Trivial PKI Question
Date: Wed, 5 Mar 2003 12:53:34 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Chris,
Thanx for your answers.  Here are some replies.

>> Question:  How should the identity as expressed in the document
>> relate to the identity as expressed by the signer's certificate?

>There may be no relationship at all. Their identity as a private
>individual may be irrelevant, subjugated by their role as the person
>in Big Buyer Corp who authorizes such payments digitally. Also,
>the creator of the order may not be the person who is authorized
>to digitally sign it.

This "works" in the paper-world as people are "flexible".  Automated
receivers OTOH are very unlikely to be able handle arbitrary schemes.
Using a business system as a mid-tier eliminates the need to move the
arbitrary-ness of the paper-world into the e-world.

Taken from another field:  I'm pretty sure that no e-government program
will ever consider accepting anything but a one-to-one match between
a citizen's ID (as they see it) and what a citizen certificate contains.  But
they also have to build special purpose RP software (due to the dys-
functional X.500 naming system) in order to do that.  In addition to
requiring CAs to follow their _hard-coded_ naming conventions.

<snip>

> The two are likely to contain different certificatePolicies.

<CertificatePolicyRant>
It is interesting to note that CPSs are frequently mentioned in this context
in spite of the fact that none of the major crypto-packages (Windows
and Java) offers any way to specify CPSs as a part of a CA trust acceptance
process.  The reason for this is simple: Computers don't understand
legal matters and CPSs are deployment-wise anything but standardized.
Peter Gutman's term "Kitchen sink extensions" is a fair description of
the value of CPSs for practical purposes.  Do "SysAdmins" ever
bother about the CPS of their VeriSign web-server certificates?
My Thawt web-server cert does not even have a CPS extension and
I haven't missed it that much.  CPSs were designed by lawyers for
lawyers.  But lawyers do not run e-business systems, write application
software packages, or know how to handle a Java keystore.
</CertificatePolicyRant>

<snip>

>> To create a foundation for more frictionless PKI-secured e-business,
>> I think that there *long-term* should be a one-to-one mapping between
>> [basic] business message identities and certificate identities.

>A kind of time-stamped intersection entity that comes between person
>and process ? A signed transaction ? Isn't this what Notaries were
>supposed to be for ?

Before PKI (I mean as things are today...), business systems authenticated
outgoing messages using various techniques (leased lines, VPNs, shared
secrets).  Why should this time-proven principle be changed due to the
introduction of PKI?

Although some believe this is "unethical", even the EU are now actively
discussing how automated processes featuring legal-entity-only certificates
and keys can legally sign invoices etc.  Several countries including Sweden,
now fully support this idea.   I.e. there is no point in making a one-to-one
translation of the paper-world into the e-world, as then you only inherit
the disadvantages of the paper-world, as well as being unable to exploit
the possibilities offered by the e-world.  However, it took the
EU ten years (!), to realize that "digital signatures" have many other
qualities, outside of replacing the hardly readable ink-blobs that you
occasionally have to put on various papers.  The majority of "manual
signatures" are BTW not made with more "intent" and "consideration",
than when hitting the OK-button of a typical business application!

<snip>

As as final note, I would like to express a whish that the S/MIME and
PKIX WGs start looking a bit above the ASN.1-level, to also address
deployment issues and shrink-wrap SW support.  There must be more than
one reason why practically no app outside of e-mail offer built-in PKI support.

Regards
Anders R






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h25BYN710262 for ietf-pkix-bks; Wed, 5 Mar 2003 03:34:23 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h25BYM310257 for <[e-mail]>; Wed, 5 Mar 2003 03:34:22 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26562; Wed, 5 Mar 2003 06:32:18 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-proxy-04.txt
Date: Wed, 05 Mar 2003 06:32:17 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Proxy 
                          Certificate Profile
	Author(s)	: S. Tuecke et al.
	Filename	: draft-ietf-pkix-proxy-04.txt
	Pages		: 49
	Date		: 2003-3-4
	
This document forms a certificate profile for Proxy 
Certificates, based on X.509 PKI certificates as defined 
in RFC 3280, for use in the Internet.  The term Proxy 
Certificate is used to describe a certificate that is 
derived from, and signed by, a normal X.509 Public Key End 
Entity Certificate or by another Proxy Certificate for the 
purpose of providing restricted impersonation within a PKI 
based authentication system.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-proxy-04.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-proxy-04.txt

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h258S1W18618 for ietf-pkix-bks; Wed, 5 Mar 2003 00:28:01 -0800 (PST)
Received: from mcs.anl.gov (cliff.mcs.anl.gov [140.221.9.17]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h258Rx318614 for <[e-mail]>; Wed, 5 Mar 2003 00:27:59 -0800 (PST)
Received: from VON-TP-T30 (terra.mcs.anl.gov [140.221.11.103]) by mcs.anl.gov (8.9.3/8.9.3) with ESMTP id CAA69022; Wed, 5 Mar 2003 02:27:53 -0600
X-Mailer: 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid (via feedmail 10 I); VM 7.07 under 21.4 (patch 11) "Native Windows TTY Support (Windows)" XEmacs Lucid
From: "Von Welch" <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <[e-mail]>
Date: Wed, 5 Mar 2003 02:28:21 -0600
To: [e-mail]
Subject: Proxy Cert draft (04) submitted - request for last call
Sender: [e-mail]
Precedence: 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 have submitted a new version of the Proxy Certificate draft with
changes based on feedback we got at Atlanta, mainly the change of the
path validation section to be additions to 3280 PV instead of
modifications.

At this point we believe we addressed all the detailed comments on the
document and would like to request a final call for WG comments.

The document is available at the url given below and I've appended the
changelog from the previous version.

Von
--

http://www.ietf.org/internet-drafts/draft-ietf-pkix-proxy-04.txt

Changes in draft-ietf-pkix-proxt-04 (February 2003) 
              
Rewrote section 4, Path Validation, to be additions to 
RFC 3280 path validation instead of changes. 
                 
Added Appendix A with ASN.1 module. 
                 
Added oids for Impersonation and Independent policy 
languages to section 3.9.3. 
                 
In section 3.6: keyusage extension in a proxy 
certificate only has to be marked critical if marked 
critical in the issuer's certificate. Previously it 
always had to be marked critical. 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24J35S11923 for ietf-pkix-bks; Tue, 4 Mar 2003 11:03:05 -0800 (PST)
Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.28]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24J34X11913 for <[e-mail]>; Tue, 4 Mar 2003 11:03:04 -0800 (PST)
Received: from free.fr (193.137.62.62.9velizy1-0-ro-as-i3-2.9tel.net [62.62.137.193]) by huva.hittite.isp.9tel.net (Postfix) with ESMTP id E3C8A9BB4A; Tue,  4 Mar 2003 20:03:22 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 04 Mar 2003 20:04:42 +0100
From: Jean-Marc Desperrier <[e-mail]>
Organization: totalement desorganise
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030129
X-Accept-Language: en-us, en, fr, fr-fr, ja
MIME-Version: 1.0
To: todd glassey <[e-mail]>
Cc: [e-mail]
Subject: Re: RFC3161(TSP): doubts about tcp protocol
References: <[e-mail]> <[e-mail]> <005a01c2e25f$74576410$020aff0a@tsg1>
In-Reply-To: <005a01c2e25f$74576410$020aff0a@tsg1>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

todd glassey wrote:

>So then the real issue is what are you trying to do with the timestamp?  is
>it a piece of evidence and if so how is it sanctified?
>
This is a completely unrelated question, isn't it ?

It can be a piece of evidence, if you have a legal context that defines 
what is required for this.
Or a contract that defines what must be accepted.
The legal context does not exist now, but the "Policy requirements for 
Time-Stamping Authorities" document gives quite a few elements for 
constructing a trusted authority, and I have reasons to believe that at 
least in Europe the legal context will finally exist and have 
requirements rather similar to what is described there.

The timestamp itself is just a piece of data, and will have no more 
value than a qualified certificate profile conformant X509 certificate 
has if the required environment around is not there.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24IF2n07355 for ietf-pkix-bks; Tue, 4 Mar 2003 10:15:02 -0800 (PST)
Received: from hubie.hubbardind.com (mail.hubbardsupply.com [65.245.100.65]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24IF0X07350 for <[e-mail]>; Tue, 4 Mar 2003 10:15:00 -0800 (PST)
Received: by HUBIE.hubbardsupply.com with Internet Mail Service (5.5.2653.19) id <1JGDBF6L>; Tue, 4 Mar 2003 13:15:01 -0500
Message-ID: <[e-mail]>
From: Roger Younglove <[e-mail]>
To: "'todd glassey'" <[e-mail]>, Jean-Marc Desperrier <[e-mail]>, [e-mail]
Subject: RE: RFC3161(TSP): doubts about tcp protocol
Date: Tue, 4 Mar 2003 13:15:01 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2E279.F8BB4D60"
Sender: [e-mail]
Precedence: 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_01C2E279.F8BB4D60
Content-Type: text/plain

Todd,
The time stamp is a piece of evidence applied by a third party to a signed
document to show the time the document was digitally signed. This provides
evidence that the digital certificate was applied prior to its expiration
date and/or prior to it being revoked should that happen.

Roger Younglove, CISSP, IAM
Principal Consultant
NetWorks Group
O. 810.225.4800 ex. 2245
M. 810.599.0879
E. [e-mail]
www.networksgroup.com
 

-----Original Message-----
From: todd glassey [mailto:[e-mail]] 
Sent: Tuesday, March 04, 2003 10:05 AM
To: Jean-Marc Desperrier; [e-mail]
Subject: Re: RFC3161(TSP): doubts about tcp protocol


So then the real issue is what are you trying to do with the timestamp?  is
it a piece of evidence and if so how is it sanctified?

Todd

----- Original Message -----
From: "Jean-Marc Desperrier" <[e-mail]>
To: <[e-mail]>
Sent: Monday, March 03, 2003 4:31 PM
Subject: Re: RFC3161(TSP): doubts about tcp protocol


>
> Peter Gutmann wrote:
>
> >Peter Sylvester <[e-mail]> writes:
> >
> >
> >>after more than 2 weeks of no response, it would be nice from the editor
of
> >>3161bis to indicate a procedure to get whatever kind of answer to this
> >>question as a possible clarification into the 3161bis document.
> >>
> One possible solution would be that errors that can be detected at TCP
> protocol level without decoding anything in the data should receive a
> TCP protocol level error in return (errorMsgRep : 06).
> 3161 is restricting errorMsgRep to be only an answer to an invalid
pollReq.
> Is it really intended that it would be it's sole usage ?
>
> In my opinion, it would make sense in a layer oriented handling of
> message to do that.
> If the data didn't make it through the TCP protocol layer because that
> layer detected an inconsistency, then it will get back a TCP error.
> If  the data makes it through up to the TimeStampReq decoding layer,
> then that layer will format a TimeStampResp message as an error response.
>
> But for implementers, using only answers of finalMsgRep with the error
> inside the TimeStampResp would convert more directly to what is done for
> the http protocol (but you could map errorMsgRep to "Status: 403 human
> readable error\n\n" in HTTP).
>
> >[...] my code just strips the TCP header out and uses the
> >ASN.1 data.  This means it works with any implementation, whether they
get the
> >TCP protocol wrapper right or not (I think some do it via memcpy() of a
> >template, based on values I've had returned).
> >
> What happens if the data is a human readable error message as ought to
> be the case for errorMsgRep ?
>
> >(I simpler alternative is just to forget about it and use HTTP transport,
> > which has well-defined semantics).
> >
> I agree.
> In addition to other disadvantages, it's not necessarily easy to get
> access to port 318 enabled through firewalls.
>
>
>

------_=_NextPart_001_01C2E279.F8BB4D60
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: RFC3161(TSP): doubts about tcp protocol</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Todd,</FONT>
<BR><FONT SIZE=3D2>The time stamp is a piece of evidence applied by a =
third party to a signed document to show the time the document was =
digitally signed. This provides evidence that the digital certificate =
was applied prior to its expiration date and/or prior to it being =
revoked should that happen.</FONT></P>

<P><FONT SIZE=3D2>Roger Younglove, CISSP, IAM</FONT>
<BR><FONT SIZE=3D2>Principal Consultant</FONT>
<BR><FONT SIZE=3D2>NetWorks Group</FONT>
<BR><FONT SIZE=3D2>O. 810.225.4800 ex. 2245</FONT>
<BR><FONT SIZE=3D2>M. 810.599.0879</FONT>
<BR><FONT SIZE=3D2>E. [e-mail]</FONT>
<BR><FONT SIZE=3D2>www.networksgroup.com</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: todd glassey [<A =
HREF=3D"mailto:[e-mail]">mailto:todd.glassey@worldn=
et.att.net</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, March 04, 2003 10:05 AM</FONT>
<BR><FONT SIZE=3D2>To: Jean-Marc Desperrier; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: RFC3161(TSP): doubts about tcp =
protocol</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>So then the real issue is what are you trying to do =
with the timestamp?&nbsp; is</FONT>
<BR><FONT SIZE=3D2>it a piece of evidence and if so how is it =
sanctified?</FONT>
</P>

<P><FONT SIZE=3D2>Todd</FONT>
</P>

<P><FONT SIZE=3D2>----- Original Message -----</FONT>
<BR><FONT SIZE=3D2>From: &quot;Jean-Marc Desperrier&quot; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>To: &lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, March 03, 2003 4:31 PM</FONT>
<BR><FONT SIZE=3D2>Subject: Re: RFC3161(TSP): doubts about tcp =
protocol</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Peter Gutmann wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Peter Sylvester =
&lt;[e-mail]&gt; writes:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;after more than 2 weeks of no response, =
it would be nice from the editor</FONT>
<BR><FONT SIZE=3D2>of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;3161bis to indicate a procedure to get =
whatever kind of answer to this</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;question as a possible clarification =
into the 3161bis document.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; One possible solution would be that errors that =
can be detected at TCP</FONT>
<BR><FONT SIZE=3D2>&gt; protocol level without decoding anything in the =
data should receive a</FONT>
<BR><FONT SIZE=3D2>&gt; TCP protocol level error in return (errorMsgRep =
: 06).</FONT>
<BR><FONT SIZE=3D2>&gt; 3161 is restricting errorMsgRep to be only an =
answer to an invalid</FONT>
<BR><FONT SIZE=3D2>pollReq.</FONT>
<BR><FONT SIZE=3D2>&gt; Is it really intended that it would be it's =
sole usage ?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; In my opinion, it would make sense in a layer =
oriented handling of</FONT>
<BR><FONT SIZE=3D2>&gt; message to do that.</FONT>
<BR><FONT SIZE=3D2>&gt; If the data didn't make it through the TCP =
protocol layer because that</FONT>
<BR><FONT SIZE=3D2>&gt; layer detected an inconsistency, then it will =
get back a TCP error.</FONT>
<BR><FONT SIZE=3D2>&gt; If&nbsp; the data makes it through up to the =
TimeStampReq decoding layer,</FONT>
<BR><FONT SIZE=3D2>&gt; then that layer will format a TimeStampResp =
message as an error response.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; But for implementers, using only answers of =
finalMsgRep with the error</FONT>
<BR><FONT SIZE=3D2>&gt; inside the TimeStampResp would convert more =
directly to what is done for</FONT>
<BR><FONT SIZE=3D2>&gt; the http protocol (but you could map =
errorMsgRep to &quot;Status: 403 human</FONT>
<BR><FONT SIZE=3D2>&gt; readable error\n\n&quot; in HTTP).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;[...] my code just strips the TCP header =
out and uses the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;ASN.1 data.&nbsp; This means it works with =
any implementation, whether they</FONT>
<BR><FONT SIZE=3D2>get the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;TCP protocol wrapper right or not (I think =
some do it via memcpy() of a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;template, based on values I've had =
returned).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; What happens if the data is a human readable =
error message as ought to</FONT>
<BR><FONT SIZE=3D2>&gt; be the case for errorMsgRep ?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;(I simpler alternative is just to forget =
about it and use HTTP transport,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; which has well-defined semantics).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I agree.</FONT>
<BR><FONT SIZE=3D2>&gt; In addition to other disadvantages, it's not =
necessarily easy to get</FONT>
<BR><FONT SIZE=3D2>&gt; access to port 318 enabled through =
firewalls.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C2E279.F8BB4D60--


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24F5kV22263 for ietf-pkix-bks; Tue, 4 Mar 2003 07:05:46 -0800 (PST)
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h24F5fX22259 for <[e-mail]>; Tue, 4 Mar 2003 07:05:42 -0800 (PST)
Received: from tsg1 (95.sanfrancisco-12rh16rt-ca.dial-access.att.net[12.81.119.95]) by mtiwmhc11.worldnet.att.net (mtiwmhc11) with SMTP id <2003030415053111100devdme>; Tue, 4 Mar 2003 15:05:31 +0000
Message-ID: <005a01c2e25f$74576410$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Jean-Marc Desperrier" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: RFC3161(TSP): doubts about tcp protocol
Date: Tue, 4 Mar 2003 07:05:10 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

So then the real issue is what are you trying to do with the timestamp?  is
it a piece of evidence and if so how is it sanctified?

Todd

----- Original Message -----
From: "Jean-Marc Desperrier" <[e-mail]>
To: <[e-mail]>
Sent: Monday, March 03, 2003 4:31 PM
Subject: Re: RFC3161(TSP): doubts about tcp protocol


>
> Peter Gutmann wrote:
>
> >Peter Sylvester <[e-mail]> writes:
> >
> >
> >>after more than 2 weeks of no response, it would be nice from the editor
of
> >>3161bis to indicate a procedure to get whatever kind of answer to this
> >>question as a possible clarification into the 3161bis document.
> >>
> One possible solution would be that errors that can be detected at TCP
> protocol level without decoding anything in the data should receive a
> TCP protocol level error in return (errorMsgRep : 06).
> 3161 is restricting errorMsgRep to be only an answer to an invalid
pollReq.
> Is it really intended that it would be it's sole usage ?
>
> In my opinion, it would make sense in a layer oriented handling of
> message to do that.
> If the data didn't make it through the TCP protocol layer because that
> layer detected an inconsistency, then it will get back a TCP error.
> If  the data makes it through up to the TimeStampReq decoding layer,
> then that layer will format a TimeStampResp message as an error response.
>
> But for implementers, using only answers of finalMsgRep with the error
> inside the TimeStampResp would convert more directly to what is done for
> the http protocol (but you could map errorMsgRep to "Status: 403 human
> readable error\n\n" in HTTP).
>
> >[...] my code just strips the TCP header out and uses the
> >ASN.1 data.  This means it works with any implementation, whether they
get the
> >TCP protocol wrapper right or not (I think some do it via memcpy() of a
> >template, based on values I've had returned).
> >
> What happens if the data is a human readable error message as ought to
> be the case for errorMsgRep ?
>
> >(I simpler alternative is just to forget about it and use HTTP transport,
> > which has well-defined semantics).
> >
> I agree.
> In addition to other disadvantages, it's not necessarily easy to get
> access to port 318 enabled through firewalls.
>
>
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h249of203106 for ietf-pkix-bks; Tue, 4 Mar 2003 01:50:41 -0800 (PST)
Received: from mail3.consignia.com (mail3.consignia.com [144.87.143.83]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h249odX03100 for <[e-mail]>; Tue, 4 Mar 2003 01:50:40 -0800 (PST)
Received: from postoffice.co.uk (unknown [144.87.146.16]) by mail3.consignia.com (Postfix) with SMTP id C745118F8AC; Tue,  4 Mar 2003 09:45:11 +0000 (GMT)
Received: by postoffice.co.uk(Lotus SMTP MTA v4.6.6  (890.1 7-16-1999))  id 00256CDF.003598F2 ; Tue, 4 Mar 2003 09:45:25 +0000
X-Lotus-FromDomain: POSTOFFICE
From: [e-mail]
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail]
Message-ID: <[e-mail]>
Date: Tue, 4 Mar 2003 09:44:32 +0000
Subject: Re: Trivial PKI Question
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> A "TRIVIAL" PKI QUESTION
> -----------------------------------

> Assume that you have a business message like a purchase order

   <Order>
       <From name="Big Buyer Corp.">
          <OurRef name="John Doe"/>
       </From>
       <To name="MegaCar International"/>
       <Item>10 Medium-sized SUVs</Item>
       <Comment>Make it quick please!</Comment>
   </Order>

> Now assume that "Big Buyer Corp." is an advanced organization
> using digital signatures.

> ==============================================
> Question:  How should the identity as expressed in the document
> relate to the identity as expressed by the signer's certificate?
> ==============================================

There may be no relationship at all. Their identity as a private
individual may be irrelevant, subjugated by their role as the person
in Big Buyer Corp who authorises such payments digitally. Also,
the creator of the order may not be the person who is authorised
to digitally sign it.

> Among the complications we find

  > 1.  The PKI-identity is presumably "strong" as it is vouched for by a
  > CA, while the identity in the business document is only "claimed"
  > by the entity itself.  ==> The PKI identity is governing?

In being authorised to digitally sign the order prior to dispatch it
behoves the signer (the risk carrier) to validate the order and the
identity of the creator of the order prior to sign and send

> 2.  The hierarchical naming system used by PKI (X.500) is completely
> different to the various naming schemes used in businesses.

That only affects the publication of the certificate into a browsable
location. It can still be revoked and will be present in whatever CRLs
the CA issues. The trust therefore remains.

> 3.  Some PKI-folks claim that signatures should be tied to individuals.
> Does this mean that the signer's certificate in the sample should
> identify John Doe of Big Buyer Corp.?

Only if John Doe is both creator of the order and authoriser of the
purchase. John is also more likely to be using the certificate issued
to him by Big Buyer Corp or its CA rather than his government (or
whatever) issued personal identity. The two are likely to contain
different certificatePolicies.

> My own conclusion is that PKI was created to support e-mail where
> these questions do not arise.

As a basic mechanism whereby you can identify an individual I believe
certification and PKI work very well. Mistakes are made in trying to
build application specific knowledge into the PKI.

> The drawback is that this will be found out by a *human*, and usually
> only *after* a malpractice has been performed.

All security can be undone by bad practice and PKI wont prevent this.
But then PKI is not a security mechanism, it is an identity mechanism
that can be used to support a security mechanism, automating some parts
of it and making others easier to implement


> A LONG-TERM REMEDY
> -------------------------------

> To create a foundation for more frictionless PKI-secured e-business,
> I think that there *long-term* should be a one-to-one mapping between
> [basic] business message identities and certificate identities.

A kind of time-stamped intersection entity that comes between person
and process ? A signed transaction ? Isn't this what Notaries were
supposed to be for ?

> As the business community is never going to adopt X.500 naming, as
> well as having their own naming problems, this will likely require
> changes on both sides.  A possible scheme using the currently only
> globally functioning naming system (DNS/URIs), is that entities are
> uniquely defined by two elements:

> - A naming domain (name space) based on a URI like: "http://www.visa.com/cc"

Microsoft use DC components to do this. I would prefer to see
one of AIA or CDP made a standard certificate component. I agree
with your implication that the cert MUST have something in it
that allows the relying party to trace the physical address of
the issuer. At present is does not.

> - A local identifier in that domain like: 4555-5555-2244-8888

Microsoft presume a unique MS domain email address. Not a bad
idea but hardly reliable beyond the edge of the MS network. But
then it is also unrealistic IMO to expect us to wander through
the eUniverse with a single identity when in the course of everyday
life we perform more than one role

I don't think that there is any problem with someone using a
multiple certs or even certs with unpublishable DNs. The fact
remains that the CA should have issued such certs under Policies.
The Policy describes what weight the relying party should give
to the signature when they encounter it. The technology itself is
not the be-all and end-all solution to true eBusiness. It is
merely a part and should always be there to support real-world
processes with a legal foundation.

Chris




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h24421a00899 for ietf-pkix-bks; Mon, 3 Mar 2003 20:02:01 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2441xX00892 for <[e-mail]>; Mon, 3 Mar 2003 20:01:59 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h2441sx8002414; Tue, 4 Mar 2003 17:01:54 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h2441sB18718; Tue, 4 Mar 2003 17:01:54 +1300
Date: Tue, 4 Mar 2003 17:01:54 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: RFC3161(TSP): doubts about tcp protocol
Sender: [e-mail]
Precedence: 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 <[e-mail]> writes:

>>[...] my code just strips the TCP header out and uses the
>>ASN.1 data.  This means it works with any implementation, whether they get the
>>TCP protocol wrapper right or not (I think some do it via memcpy() of a
>>template, based on values I've had returned).
>
>What happens if the data is a human readable error message as ought to be the
>case for errorMsgRep ?

This is a wonderful circular argument: You need to have the TCP header in
order to return information about problems with the TCP header :-).  The
solution for this is obvious (and TSP has its own facility for returning error
information at the TSP-protocol level).

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h2428M027809 for ietf-pkix-bks; Mon, 3 Mar 2003 18:08:22 -0800 (PST)
Received: from ratatosk.pdc.kth.se (ratatosk.pdc.kth.se [193.10.159.41]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h2428IX27805 for <[e-mail]>; Mon, 3 Mar 2003 18:08:18 -0800 (PST)
X-Rcpt-To: unknown
X-Mail-From: [e-mail]
X-Client: [211.132.181.14] (211.132.181.14)
Received: from fiololle.pdc.kth.se (14.sub0.181.132.211.in-addr.arpa [211.132.181.14] (may be forged)) (authenticated bits=0) by ratatosk.pdc.kth.se (8.12.6/8.12.6) with ESMTP id h2428Euh075683; Tue, 4 Mar 2003 03:08:16 +0100 (CET)
Reply-To: <[e-mail]>
From: "Olle Mulmo" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
Subject: RE: Trivial PKI Question
Date: Tue, 4 Mar 2003 03:08:05 +0100
Message-ID: <001501c2e1f2$e4c1b330$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-reply-to: <035501c2e1ce$1c5e2640$0500a8c0@arport>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

For S/MIME, the problem you state was circumvented by putting the
email address in SubjectAltName::rfc822Name. In the case of Kerberos
and PKInit, they added the Kerberos principal name in SubjectAltName
as well. Same thing with Microsoft and their smart card login.

So why not just create another such circumvention for XML-based
naming? Something like an OtherName of type

  XmlName ::= SEQUENCE {
     identifier        UTF8String,
     nameSpace  [0]    UTF8String OPTIONAL }

/Olle

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Anders Rundgren
Sent: den 3 mars 2003 22:45
To: [e-mail]
Subject: Trivial PKI Question



A "TRIVIAL" PKI QUESTION
-----------------------------------

Assume that you have a business message like a purchase order

    <Order>
        <From name="Big Buyer Corp.">
            <OurRef name="John Doe"/>
        </From>
        <To name="MegaCar International"/>
        <Item>10 Medium-sized SUVs</Item>
        <Comment>Make it quick please!</Comment>
    </Order>

Now assume that "Big Buyer Corp." is an advanced organization
using digital signatures.

==============================================
Question:  How should the identity as expressed in the document
relate to the identity as expressed by the signer's certificate?
==============================================

Among the complications we find

1.  The PKI-identity is presumably "strong" as it is vouched for by a
     CA, while the identity in the business document is only "claimed"
     by the entity itself.  ==> The PKI identity is governing?

2.  The hierarchical naming system used by PKI (X.500) is completely
     different to the various naming schemes used in businesses.

3.  Some PKI-folks claim that signatures should be tied to individuals.
     Does this mean that the signer's certificate in the sample should
     identify John Doe of Big Buyer Corp.?

4.  The receivers (relying parties) are automated processes supposed
     to securely handle similar messages from numerous business parties.

5.  Current e-commerce standards like ebXML and Web Services does
     NOT address this basic question.

My own conclusion is that PKI was created to support e-mail where
these questions do not arise.  For other types of messaging, PKI in
its current shape does not scale well, or at least creates as many
new problems as it was meant to solve existing ones.

Regarding #1, I believe that most business systems ignore the PKI-
identity due to #2, #3 and #4.  Although a bit weird, the logic behind
that is that if an entity having a known key/cert is "lying", they will
sooner or later get in trouble anyway.  The drawback is that this will
be found out by a *human*, and usually only *after* a malpractice has
been performed.

A LONG-TERM REMEDY
-------------------------------

To create a foundation for more frictionless PKI-secured e-business,
I think that there *long-term* should be a one-to-one mapping between 
[basic] business message identities and certificate identities.
As the business community is never going to adopt X.500 naming, as 
well as having their own naming problems, this will likely require
changes on both sides.  A possible scheme using the currently only
globally functioning naming system (DNS/URIs), is that entities are
uniquely defined by two elements:

- A naming domain (name space) based on a URI like: "http://www.visa.com/cc"
- A local identifier in that domain like: 4555-5555-2244-8888

Although the example identified a credit-card, the scheme works for just
about any kind of object or entity.  An advantage of using HTTP URIs is
that you usually can get further information "by clicking on the link".

Anders Rundgren






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h240Twh25636 for ietf-pkix-bks; Mon, 3 Mar 2003 16:29:58 -0800 (PST)
Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.28]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h240TuX25632 for <[e-mail]>; Mon, 3 Mar 2003 16:29:57 -0800 (PST)
Received: from free.fr (251.130.62.62.9velizy1-0-ro-as-i1-1.9tel.net [62.62.130.251]) by huva.hittite.isp.9tel.net (Postfix) with ESMTP id 744849BCBB for <[e-mail]>; Tue,  4 Mar 2003 01:30:13 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 04 Mar 2003 01:31:32 +0100
From: Jean-Marc Desperrier <[e-mail]>
Organization: totalement desorganise
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030129
X-Accept-Language: en-us, en, fr, fr-fr, ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: RFC3161(TSP): doubts about tcp protocol
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:

>Peter Sylvester <[e-mail]> writes:
>  
>
>>after more than 2 weeks of no response, it would be nice from the editor of
>>3161bis to indicate a procedure to get whatever kind of answer to this
>>question as a possible clarification into the 3161bis document.
>>
One possible solution would be that errors that can be detected at TCP 
protocol level without decoding anything in the data should receive a 
TCP protocol level error in return (errorMsgRep : 06).
3161 is restricting errorMsgRep to be only an answer to an invalid pollReq.
Is it really intended that it would be it's sole usage ?

In my opinion, it would make sense in a layer oriented handling of 
message to do that.
If the data didn't make it through the TCP protocol layer because that 
layer detected an inconsistency, then it will get back a TCP error.
If  the data makes it through up to the TimeStampReq decoding layer, 
then that layer will format a TimeStampResp message as an error response.

But for implementers, using only answers of finalMsgRep with the error 
inside the TimeStampResp would convert more directly to what is done for 
the http protocol (but you could map errorMsgRep to "Status: 403 human 
readable error\n\n" in HTTP).

>[...] my code just strips the TCP header out and uses the
>ASN.1 data.  This means it works with any implementation, whether they get the
>TCP protocol wrapper right or not (I think some do it via memcpy() of a
>template, based on values I've had returned).
>
What happens if the data is a human readable error message as ought to 
be the case for errorMsgRep ?

>(I simpler alternative is just to forget about it and use HTTP transport,
> which has well-defined semantics).
>
I agree.
In addition to other disadvantages, it's not necessarily easy to get 
access to port 318 enabled through firewalls.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h240DMJ25361 for ietf-pkix-bks; Mon, 3 Mar 2003 16:13:22 -0800 (PST)
Received: from webo.vtcif.telstra.com.au (webo.vtcif.telstra.com.au [202.12.144.19]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h240DGX25357 for <[e-mail]>; Mon, 3 Mar 2003 16:13:16 -0800 (PST)
Received: (from uucp@localhost) by webo.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA24843 for <[e-mail]>; Tue, 4 Mar 2003 11:13:11 +1100 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by webo.vtcif.telstra.com.au, id smtpd0BPX88; Tue Mar  4 11:12:51 2003
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA07261 for <[e-mail]>; Tue, 4 Mar 2003 11:12:49 +1100 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0d.klD; Tue Mar  4 11:12:11 2003
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA00787 for <[e-mail]>; Tue, 4 Mar 2003 11:12:10 +1100 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: RSA: 00: draft-ietf-pkix-rsa-pkalgs-00.txt
Date: Tue, 4 Mar 2003 10:11:43 +1000
Message-ID: <[e-mail]>
Thread-Topic: I-D ACTION:draft-ietf-pkix-rsa-pkalgs-00.txt
Thread-Index: AcK2YFPkqMGhILE6QFiPOQyHziK1EgrdMBuw
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h240DLX25358
Sender: [e-mail]
Precedence: 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 want the PKI standards to become stable, permitting development and deployment.

draft-ietf-pkix-rsa-pkalgs-00.txt does not offer stability.  By defining new public key alg ids for 2 algorithms (RSASA-PSS signatures & RSAES-OAEP encryption) it immediately means new versions of every other existing public key alg id need to be defined so they also support the algorithm constraint concept.  A precession of new public key alg ids (for existing keys and existing algs) can hardly be called "stability".

> [can] PKI components more easily accept a new algorithm OID or a new extension definition

The question should be "can PKI components more easily accept a procession of new algorithm OIDs over an indefinite period or a new extension".

A new extension should be easier to accepted as the rules for processing unrecognised extensions are already well defined, understood & implemented.

> an impact on certification path validation logic  ..  LESS ripple impact

I am not sure what you mean.  Could you give an example?

> the algorithm OID is "fail safe."

Marking an extension as critical is just as fail safe as using a new public key alg id.  The extension approach gives certificate issuers the option to choose (on a per-certificate basis) to enforce algorithm constraints in a fail safe or more lenient manner.  This is a benefit of extensions, not a disadvantage.


Sensible security policies might be:
1* Any application or protocol must be able to support multiple algorithms (in case weaknesses are discovered in one).
2* Any particular key should only be used with one algorithm.
The policies should be independent.  However, the approach of draft-ietf-pkix-rsa-pkalgs-00.txt ties them together.  If you enforce policy 2 the only available signature algorithm would be RSASA_PSS.

RFC 3279 (published less than a year ago) would have to be completely rewritten as none of the public key alg ids that it specifies allow support algorithm constraints.








> 	----------
> 	From: 	Russ Housley [mailto:[e-mail]] 
> 	Sent:	Wednesday, 26 February 2003 6:41 AM
> 	To:	Manger, James H
> 	Cc:	[e-mail]
> 
> 	James:
> 
> 	This is a matter of crystal ball gazing as well as risk assessment.
> 
> 	I want the PKI standards to become stable, permitting development and deployment.  So, the question is whether one believes that PKI components can more easily accept a new algorithm OID or a new extension definition.  My view is that an algorithm OID is much easier.  These OIDs do not ever have an impact on certification path validation logic.  This is not true for extensions.  This observation leads me to the conclusion that the introduction of additional algorithm OIDs will have LESS ripple impact.
> 
> 	FURTHER, when the certified public key is an end-entity key, the application is impacted.  If the algorithm OID approach is used, the application may be unable to use a "constrained public key" until it is modified to understand the OID.  If the extension approach is used, then the application that is unfamiliar with the extension, assuming that it is non-critical, could ignore it.  On the other hand, a critical extension, has the same end result as a separate algorithm OID.  In my view, the algorithm OID is "fail safe."
> 
> 	Maybe there are other dimensions to the trade off discussion, but these are the two aspects that I considered before writing draft-ietf-pkix-rsa-pkalgs-00.
> 
> 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23LtMU19922 for ietf-pkix-bks; Mon, 3 Mar 2003 13:55:22 -0800 (PST)
Received: from mailg.telia.com (mailg.telia.com [194.22.194.26]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23LtJX19918 for <[e-mail]>; Mon, 3 Mar 2003 13:55:19 -0800 (PST)
Received: from arport (h245n2fls31o1122.telia.com [212.181.142.245]) by mailg.telia.com (8.12.5/8.12.5) with SMTP id h23LtGxs001592 for <[e-mail]>; Mon, 3 Mar 2003 22:55:16 +0100 (CET)
X-Original-Recipient: <[e-mail]>
Message-ID: <035501c2e1ce$1c5e2640$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Trivial PKI Question
Date: Mon, 3 Mar 2003 22:44:47 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A "TRIVIAL" PKI QUESTION
-----------------------------------

Assume that you have a business message like a purchase order

    <Order>
        <From name="Big Buyer Corp.">
            <OurRef name="John Doe"/>
        </From>
        <To name="MegaCar International"/>
        <Item>10 Medium-sized SUVs</Item>
        <Comment>Make it quick please!</Comment>
    </Order>

Now assume that "Big Buyer Corp." is an advanced organization
using digital signatures.

==============================================
Question:  How should the identity as expressed in the document
relate to the identity as expressed by the signer's certificate?
==============================================

Among the complications we find

1.  The PKI-identity is presumably "strong" as it is vouched for by a
     CA, while the identity in the business document is only "claimed"
     by the entity itself.  ==> The PKI identity is governing?

2.  The hierarchical naming system used by PKI (X.500) is completely
     different to the various naming schemes used in businesses.

3.  Some PKI-folks claim that signatures should be tied to individuals.
     Does this mean that the signer's certificate in the sample should
     identify John Doe of Big Buyer Corp.?

4.  The receivers (relying parties) are automated processes supposed
     to securely handle similar messages from numerous business parties.

5.  Current e-commerce standards like ebXML and Web Services does
     NOT address this basic question.

My own conclusion is that PKI was created to support e-mail where
these questions do not arise.  For other types of messaging, PKI in
its current shape does not scale well, or at least creates as many
new problems as it was meant to solve existing ones.

Regarding #1, I believe that most business systems ignore the PKI-
identity due to #2, #3 and #4.  Although a bit weird, the logic behind
that is that if an entity having a known key/cert is "lying", they will
sooner or later get in trouble anyway.  The drawback is that this will
be found out by a *human*, and usually only *after* a malpractice has
been performed.

A LONG-TERM REMEDY
-------------------------------

To create a foundation for more frictionless PKI-secured e-business,
I think that there *long-term* should be a one-to-one mapping between 
[basic] business message identities and certificate identities.
As the business community is never going to adopt X.500 naming, as 
well as having their own naming problems, this will likely require
changes on both sides.  A possible scheme using the currently only
globally functioning naming system (DNS/URIs), is that entities are
uniquely defined by two elements:

- A naming domain (name space) based on a URI like: "http://www.visa.com/cc"
- A local identifier in that domain like: 4555-5555-2244-8888

Although the example identified a credit-card, the scheme works for just
about any kind of object or entity.  An advantage of using HTTP URIs is
that you usually can get further information "by clicking on the link".

Anders Rundgren





Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.6) id h23IJbm08516 for ietf-pkix-bks; Mon, 3 Mar 2003 10:19:37 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.6) with ESMTP id h23IJaX08512 for <[e-mail]>; Mon, 3 Mar 2003 10:19:36 -0800 (PST)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h23IJKx8019717; Tue, 4 Mar 2003 07:19:20 +1300
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h23IJJ318414; Tue, 4 Mar 2003 07:19:19 +1300
Date: Tue, 4 Mar 2003 07:19:19 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: RFC3161(TSP): doubts about tcp protocol
Sender: [e-mail]
Precedence: 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 Sylvester <[e-mail]> writes:

>after more than 2 weeks of no response, it would be nice from the editor of
>3161bis to indicate a procedure to get whatever kind of answer to this
>question as a possible clarification into the 3161bis document.

Well, as a non-editor of 3161, I guess I can provide an implementor's comment
to help the original poster out: Since the TCP protocol in RFC 3161 serves no
identifiable purpose, and since I've seen implementations put all sorts of
weird stuff in there, my code just strips the TCP header out and uses the
ASN.1 data.  This means it works with any implementation, whether they get the
TCP protocol wrapper right or not (I think some do it via memcpy() of a
template, based on values I've had returned).

(I simpler alternative is just to forget about it and use HTTP transport,
 which has well-defined semantics).

Peter.


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h23HEsf06136 for ietf-pkix-bks; Mon, 3 Mar 2003 09:14:54 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h23HEqY06131 for <[e-mail]>; Mon, 3 Mar 2003 09:14:52 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA16605; Mon, 3 Mar 2003 18:14:47 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.6); Mon, 3 Mar 2003 18:14:47 +0100 (MET)
Received: (from sylvest@localhost) by champagne.edelweb.fr (8.7.6/8.6.6) id SAA05228; Mon, 3 Mar 2003 18:14:46 +0100 (MET)
Date: Mon, 3 Mar 2003 18:14:46 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: RFC3161(TSP): doubts about tcp protocol
Sender: [e-mail]
Precedence: 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,

after more than 2 weeks of no response, it would be nice from the editor
of 3161bis to indicate a procedure to get whatever kind of answer to this
question as a possible clarification into the 3161bis document.

Peter

> From: "Pere Fiol" <[e-mail]>
> To: "ietf" <[e-mail]>
> Subject: RFC3161(TSP): doubts about tcp protocol 
> Date: Thu, 13 Feb 2003 17:47:55 +0100
> 
> Hi,
> 
> I've developed a TSA but I have a doubt in TCP protocol: if a client
> sends a request to TSA with invalid TCP message (for example with a flag
> different of '00'H, with wrong number of bytes in length,...) What must
> do a TSA in this situations?? RFC3161 mustn't talk something about it??
> 
> Thanks and Best Regards,
> Pere Fiol


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h23FTDV28053 for ietf-pkix-bks; Mon, 3 Mar 2003 07:29:13 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h23FTBY28047 for <[e-mail]>; Mon, 3 Mar 2003 07:29:12 -0800 (PST)
Received: (qmail 29970 invoked from network); 3 Mar 2003 15:28:57 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.38.62) by woodstock.binhost.com with SMTP; 3 Mar 2003 15:28:57 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 03 Mar 2003 10:29:07 -0500
To: Denis Pinkas <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-acpolicies-extn-02.txt
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

Sorry, I misspelled the the name that I assigned to identify this 
extension.  Here is the corrected entry:

    id-pe-ac-policies            OBJECT IDENTIFIER ::= { id-pe 15 }

Russ

At 01:48 PM 3/3/2003 +0100, Denis Pinkas wrote:

>To the WG,
>
>I have re-issued a new version of the
>Attribute Certificate Policies extension document.
>
>The intent is to fully align the content with the equivalent extension
>policy for Public Key Certificates (i.e. certificate policies extension,
>id-ce-certificatePolicies): the additions that were initially proposed 
>have been removed.
>
>You will (certainly) notice that there is an error in the ASN.1 module 
>which omits to import the PolicyQualifierId from RFC 3280. This will be 
>corrected once the web server is re-opened.
>
>The new OID is proposed in the arc for attribute certificate attributes
>id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
>
>Denis



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h23DWKi23005 for ietf-pkix-bks; Mon, 3 Mar 2003 05:32:20 -0800 (PST)
Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h23DWJY23001 for <[e-mail]>; Mon, 3 Mar 2003 05:32:19 -0800 (PST)
Received: (qmail 25126 invoked from network); 3 Mar 2003 13:31:53 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.32.92) by woodstock.binhost.com with SMTP; 3 Mar 2003 13:31:53 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 03 Mar 2003 08:31:46 -0500
To: Denis Pinkas <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-acpolicies-extn-02.txt
Cc: [e-mail]
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>

Denis:

The document defines an extension, not an attribute.  I have assigned the 
following OID to identify this extension:

    id-pe-acPolicies             OBJECT IDENTIFIER ::= { id-pe 15 }

Russ

At 01:48 PM 3/3/2003 +0100, Denis Pinkas wrote:

>To the WG,
>
>I have re-issued a new version of the
>Attribute Certificate Policies extension document.
>
>The intent is to fully align the content with the equivalent extension
>policy for Public Key Certificates (i.e. certificate policies extension,
>id-ce-certificatePolicies): the additions that were initially proposed 
>have been removed.
>
>You will (certainly) notice that there is an error in the ASN.1 module 
>which omits to import the PolicyQualifierId from RFC 3280. This will be 
>corrected once the web server is re-opened.
>
>The new OID is proposed in the arc for attribute certificate attributes
>id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }
>
>Denis
>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h23CpU121937 for ietf-pkix-bks; Mon, 3 Mar 2003 04:51:30 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h23CpTY21933 for <[e-mail]>; Mon, 3 Mar 2003 04:51:29 -0800 (PST)
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA18974 for <[e-mail]>; Mon, 3 Mar 2003 13:53:52 +0100
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id MAA05871 for <[e-mail]>; Mon, 3 Mar 2003 12:45:05 +0100
Message-ID: <[e-mail]>
Date: Mon, 03 Mar 2003 13:48:51 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-acpolicies-extn-02.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

To the WG,

I have re-issued a new version of the
Attribute Certificate Policies extension document.

The intent is to fully align the content with the equivalent extension
policy for Public Key Certificates (i.e. certificate policies extension,
id-ce-certificatePolicies): the additions that were initially proposed have 
been removed.

You will (certainly) notice that there is an error in the ASN.1 module which 
omits to import the PolicyQualifierId from RFC 3280. This will be corrected 
once the web server is re-opened.

The new OID is proposed in the arc for attribute certificate attributes
id-aca OBJECT IDENTIFIER ::= { id-pkix 10 }

Denis



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h23Bojd15413 for ietf-pkix-bks; Mon, 3 Mar 2003 03:50:45 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h23BoiY15403 for <[e-mail]>; Mon, 3 Mar 2003 03:50:44 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18758; Mon, 3 Mar 2003 06:48:43 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-acpolicies-extn-02.txt
Date: Mon, 03 Mar 2003 06:48:42 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Attribute Certificate Policies extension
	Author(s)	: C. Francis, D. Pinkas
	Filename	: draft-ietf-pkix-acpolicies-extn-02.txt
	Pages		: 6
	Date		: 2003-2-28
	
This document describes one certificate extension to explicitly 
state the Attribute Certificate (AC) policies that apply to a given 
Attribute Certificate.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-acpolicies-extn-02.txt".

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h236k9205321 for ietf-pkix-bks; Sun, 2 Mar 2003 22:46:09 -0800 (PST)
Received: from mx4.pacifier.net (mx4.pacifier.net [64.255.237.184]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h236k8Y05317 for <[e-mail]>; Sun, 2 Mar 2003 22:46:08 -0800 (PST)
Received: from smtp3.pacifier.net (smtp3 [64.255.237.173]) by mx4.pacifier.net (Postfix) with ESMTP id F0CF86AA13; Sun,  2 Mar 2003 22:46:12 -0800 (PST)
Received: from revelation (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id DFDA66D62D; Sun,  2 Mar 2003 22:46:11 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt
Date: Sun, 2 Mar 2003 22:43:37 -0800
Message-ID: <001401c2e150$388af7e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

As an implementer, I think of dealing not only with the parameters but
the "data" value associated with the OID as being dependent on the OID.
This means that the following items are indexed on the OID.  The
parameters structure, the public key encoding and the signature value
encoding.  In the case of RSA the signature value encoding is really
simple - i.e. just the bytes - but for some signature algorithms this is
not true.  The fewer tables that I have to do lookups on the easer it is
to write general purpose code.  I would be perfectly happen to assign a
different OID for each different way that the encodings and mathematics
are done.  

A different question is whether the parameters should be different
between the different locations.  I agree that there should be a
restriction on only using PSS with a signature key, however I think
there is an interesting question about the requirement for different
certificates to be assigned if you want to use both SHA-256 and SHA-512
with the PSS key depending on the question of necessary duration of the
signature.

jim

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]] 
> Sent: Monday, February 24, 2003 1:28 PM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: Comments on draft-ietf-pkix-rsa-pkalgs-00.txt
> 
> 
> Burt & Jim:
> 
> Clearly there are some choices.  I believe that use of the 
> same object 
> identifier is the best we can do given the current state of 
> the world.  The 
> solution that we devise needs to be backward compatible.  I 
> do not think 
> that assigning two OIDs for each possible use of an RSA or 
> Elliptic Curve 
> public key is desirable.  We already need to assign one OID for the 
> signature validation (or key management technique).  
> Assigning a second OID 
> for use in the subject public key info to say that the key 
> can only be used 
> in a particular manner is only useful if the parameters that 
> are already 
> associated with the currently assigned OID do not support the 
> necessary 
> information.
> 
> Russ
> 
> >[JS] 7.  Section 3.2.  I would like to see a different OID used for a
> >signature value from that used to encode the public key.  
> This makes it
> >easier to process for encode/decode as there are not two 
> structures with
> >the same OID.
> >
> >[BK] The OID is not used to encode the public key directly, 
> but to encode an
> >AlgorithmID; the AlgorithmID is used to describe the public 
> key. So, the
> >AlgorithmID has two meanings, one for the signature, one for 
> the public key.
> >I agree this is potential problem, and am open to alternatives.
>