What does the 'S' in SCVP stand for?

["James Jing" <[e-mail]>]

Looking at latest draft of SCVP (14), one starts to wonder whether the
letter 'S' in SCVP stands for 'Simple', or it has mutated into
'Superfluous'.

We implemented SCVP for one of our customers way back when SCVP was in
draft 8. Then and now I see the reason for the existence of SCVP is that
a client application wants to defer to the server to make the decision
on the validity of a certificate which has been presented. With the
request object becoming as complex as it is now, one wonders whether the
client application is actually better off doing all on its own. 

If the purpose is to provide validation logic to another application, I
would argue that one is better off using a library, rather than a
client-server proposition with a complex protocol. Maybe I am the only
guy feeling this way.

James






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4V6N3Ni024388; Sun, 30 May 2004 23:23:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4V6N3tP024387; Sun, 30 May 2004 23:23:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from figg.securenet.com.au (ns2.isecure.com.au [202.125.4.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4V6N0rC024246 for <[e-mail]>; Sun, 30 May 2004 23:23:02 -0700 (PDT) (envelope-from [e-mail])
Received: from iron.securenet.com.au (iron.isecure.com.au [202.125.4.94] (may be forged)) by figg.securenet.com.au (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4V6Mki3020344; Mon, 31 May 2004 16:22:46 +1000
Received: (from uucp@localhost) by iron.securenet.com.au (8.12.6/8.12.6) id i4V6Mk0o005684; Mon, 31 May 2004 16:22:46 +1000 (EST)
Received: from nodnsquery(10.11.3.10) by iron.securenet.com.au via csmap (V6.0) id srcAAAhPaygl; Mon, 31 May 04 16:22:45 +1000
Received: from cbrms01.securenet.com.au (localhost [127.0.0.1]) by gibbons.securenet.com.au (8.12.3/8.12.3/Debian-7woody) with ESMTP id i4V6MiPP022998; Mon, 31 May 2004 16:22:45 +1000
Received: from AMALTHEA.securenet.com.au ([192.168.100.30]) by cbrms01.securenet.com.au with Microsoft SMTPSVC(5.0.2195.6713); Mon, 31 May 2004 16:21:52 +1000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: What does the 'S' in SCVP stand for?
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Mon, 31 May 2004 16:21:59 +1000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: What does the 'S' in SCVP stand for?
Thread-Index: AcRG148f9iN5fwkKTh6oSg3eWk25Ng==
From: "James Jing" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 31 May 2004 06:21:52.0232 (UTC) FILETIME=[90136680:01C446D7]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4V6N3rC024378
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Looking at latest draft of SCVP (14), one starts to wonder whether the
letter 'S' in SCVP stands for 'Simple', or it has mutated into
'Superfluous'.

We implemented SCVP for one of our customers way back when SCVP was in
draft 8. Then and now I see the reason for the existence of SCVP is that
a client application wants to defer to the server to make the decision
on the validity of a certificate which has been presented. With the
request object becoming as complex as it is now, one wonders whether the
client application is actually better off doing all on its own. 

If the purpose is to provide validation logic to another application, I
would argue that one is better off using a library, rather than a
client-server proposition with a complex protocol. Maybe I am the only
guy feeling this way.

James





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4T1lMHh090528; Fri, 28 May 2004 18:47:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4T1lMNd090527; Fri, 28 May 2004 18:47:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail10.atl.registeredsite.com ([e-mail] [64.224.219.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4T1lM3V090520 for <[e-mail]>; Fri, 28 May 2004 18:47:22 -0700 (PDT) (envelope-from [e-mail])
Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail10.atl.registeredsite.com (8.12.10/8.12.8) with ESMTP id i4T1lRcb006264; Sat, 29 May 2004 01:47:27 GMT
Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Fri, 28 May 2004 20:47:26 -0500
Message-ID: <[e-mail]>
Date: Fri, 28 May 2004 18:47:23 -0700
From: Ed Gerck <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Tony Bartoletti <[e-mail]>
CC: Dave Engberg <[e-mail]>, PKIX <[e-mail]>
Subject: Re: New ID: draft-gerck-pkix-revocation-00.txt
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tony Bartoletti wrote:
> Should the RP desire certifications that limit the "window of 
> opportunity" to 5 minutes, they must reject certifications made by CA's 
> that do not support sufficient timeliness. 

Yes. This can be easily automated by the RP by using the freshestCRL field,
for example. If the CRL was issued more than 5 minutes ago, wait for the
next CRL and decide within 5 minutes of its publication.

 > "Let the RP beware".

Yes, "Let the RP beware" because RP reliance is that which can break the RP's
security policy (Section 2 of the ID). The revocation status of a cert depends
both on processes that the RP CAN verify and processes that the RP CANNOT
verify. The latter defines the limitations of RP reliance. The lesser the
limitations of RP reliance, the lesser the risk faced by the RP that RP
reliance might be broken by factors outside RP control.

Cheers,
Ed Gerck



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4T1ZvwP088323; Fri, 28 May 2004 18:35:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4T1ZvLY088321; Fri, 28 May 2004 18:35:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail9.atl.registeredsite.com ([e-mail] [64.224.219.83]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4T1Zurc088305 for <[e-mail]>; Fri, 28 May 2004 18:35:56 -0700 (PDT) (envelope-from [e-mail])
Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail9.atl.registeredsite.com (8.12.10/8.12.8) with ESMTP id i4T1ZxtU002030; Sat, 29 May 2004 01:35:59 GMT
Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Fri, 28 May 2004 20:35:58 -0500
Message-ID: <[e-mail]>
Date: Fri, 28 May 2004 18:35:56 -0700
From: Ed Gerck <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dave Engberg <[e-mail]>
CC: PKIX <[e-mail]>
Subject: Re: New ID: draft-gerck-pkix-revocation-00.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave Engberg wrote:

> 
> Ed -
> 
> Thanks for putting together this revocation memo.  This provides a very
> useful philosophical analysis for PKI architectures.

I hope it's more practical than philosophical ;-)

The  philosophical aspect might be that because similar issues can be recognized
in other areas, the memo benefits from their solutions. For example, when
verifying the revocation status of a cert for a given time T, what does it mean
to require that two different RPs shall come to the same result for the same time
T? It means that the revocation status shall be an objective reference. Which
introduces some requirements, one of which is observability.

> To paraphrase one of the central arguments (section 3.1.2):  the
> objective revocation of a certificate is (basically) defined as the
> first instant of publication of a corresponding CRL (or Delta CRL, OCSP
> response, etc.) by the cert's issuer.  You separate this definition of
> revocation from the more ambiguous processes of checking revocation
> through all of our non-transactional PKI protocols.
> 
> I'm interested to hear why you chose to define "objectively revoked" in
> terms of the completion of publication rather than the moment of
> notification to the CA.

First, we need to distinguish between "notice" and "status" (perhaps a new
item to be discussed in the ID). The moment of notification to the CA is a
notice. For example, a request for revocation sent by the subscriber. A
revocation notice is NOT the revocation status, and is also NOT that status
available as an observable entity. The certificate's status changes NOT when
the notice is received but when the CRL is published. Moreover, in  order
to be objective, the revocation status needs to be observable -- for example,
the published status must be readable by an RP.

> Consider:  I'm familiar with a large PKI that used to require a few
> hours to produce a CRL.  If the CA was notified of a revocation at 9am,
> the first external communication about this revocation would only be
> available in the afternoon.

As defined in the freshestCRL field, for example.

> If you asked the administrators of this PKI, they would have intuitively
> felt that the cert was "really" revoked at 9am, and that the latency
> between this time and the first publication was just a propogation delay
> for the objective reality.

This is exactly what the ID clarifies: the cert was not revoked at 9am. The
event that can be observed by any RP is the first external communication
about this revocation, which would only be available in the afternoon
according to your example.

> Obviously, this is an extreme example, but there will always be some
> latency between a CA's notification of revocation and when that
> information propogates to Relying Parties.  

Yes, this is discussed in section 4.6, "Increasing Reliability",
which also discusses how the latency can be reduced or, at least,
bounded.

> I'm curious why you put part
> of this latency (production of the CRL) before the "objective
> revocation" and parts of it (distribution to LDAP directories, OCSP
> responders, transmission to RPs) after the objective moment of
> revocation.

Because the latency that corresponds to the "notice" process (including
production of the CRL and the delay for its publication in the next update)
cannot be reduced by any efforts of the RP. The RP is entirely at the
mercy of the CRL issuer for this part. OTOH, after the objective moment
of revocation (i.e., the revocation status "revoked" is observable by
any RP), additional efforts by an RP should increase the ability of the
RP to make a reliance determination of a certificate's revocation status
in less time.

Cheers,
Ed Gerck



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4T0H46j069821; Fri, 28 May 2004 17:17:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4T0H4Yc069820; Fri, 28 May 2004 17:17:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-3.llnl.gov (smtp-3.llnl.gov [128.115.41.83]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4T0H4wA069789 for <[e-mail]>; Fri, 28 May 2004 17:17:04 -0700 (PDT) (envelope-from [e-mail])
Received: from mailfe-1.llnl.gov (localhost [127.0.0.1]) by smtp-3.llnl.gov (8.12.3p2-20030917/8.12.3/LLNL evision: 1.15 $) with ESMTP id i4T0GxS7014621; Fri, 28 May 2004 17:17:00 -0700 (PDT)
Received: from catalyst.llnl.gov (account [e-mail] [128.115.222.68] verified) by mailfe-1.llnl.gov (CommuniGate Pro SMTP 4.1.8) with ESMTP id 640585; Fri, 28 May 2004 17:16:59 -0700
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22
Date: Fri, 28 May 2004 17:16:19 -0700
To: "Dave Engberg" <[e-mail]>, "Ed Gerck" <[e-mail]>, "PKIX" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: New ID: draft-gerck-pkix-revocation-00.txt
In-Reply-To: <[e-mail] eet.com>
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>

At 01:12 PM 5/28/2004, Dave Engberg wrote:

>Ed -
>
>I'm interested to hear why you chose to define "objectively revoked" in
>terms of the completion of publication rather than the moment of
>notification to the CA.

Dare I speak for Ed on this matter ... :)

I may feel I have notified my CA of (compromise, revocation desire, etc) at 
time T.

The CA is free to take this into consideration, according to their own 
processes.  Those processes are (and perhaps should be) quite opaque to 
outsiders.  The world of RPs who may rely upon that certificate must, of 
necessity, depend upon a notification made by the CA.  From a strictly 
formal standpoint, the certificate is not revoked when the CA "feels" is it 
revoked, but only when the CA SAYS it is revoked.  They are the only 
authority in this matter.

It might be "nice" if such notifications included "reason", indicating 
(perhaps) "report of compromise at time T".  But really, what CA would want 
to open itself to such (potential) liability?  Of what other value (except 
to put the CA into hot water) would one desire to learn that a certificate, 
revoked this moment but relied upon 1 hour ago, was reported compromised 2 
hours earlier?

 From the RP standpoint, it was reasonable and "right" to rely upon it 1 
hour ago, in any case.

Should the RP desire certifications that limit the "window of opportunity" 
to 5 minutes, they must reject certifications made by CA's that do not 
support sufficient timeliness.  "Let the RP beware".

Cheers!   ____tony____


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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4SKCYh5045463; Fri, 28 May 2004 13:12:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4SKCYEC045462; Fri, 28 May 2004 13:12:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com ([68.162.232.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4SKCWFm045454 for <[e-mail]>; Fri, 28 May 2004 13:12:32 -0700 (PDT) (envelope-from [e-mail])
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: New ID: draft-gerck-pkix-revocation-00.txt
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Date: Fri, 28 May 2004 16:12:25 -0400
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New ID: draft-gerck-pkix-revocation-00.txt
Thread-Index: AcREUHbWUw/iEEzeSG68FsP0J5IfPgAnCssQ
From: "Dave Engberg" <[e-mail]>
To: "Ed Gerck" <[e-mail]>, "PKIX" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4SKCXFm045457
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ed -

Thanks for putting together this revocation memo.  This provides a very
useful philosophical analysis for PKI architectures.

To paraphrase one of the central arguments (section 3.1.2):  the
objective revocation of a certificate is (basically) defined as the
first instant of publication of a corresponding CRL (or Delta CRL, OCSP
response, etc.) by the cert's issuer.  You separate this definition of
revocation from the more ambiguous processes of checking revocation
through all of our non-transactional PKI protocols.

I'm interested to hear why you chose to define "objectively revoked" in
terms of the completion of publication rather than the moment of
notification to the CA.

Consider:  I'm familiar with a large PKI that used to require a few
hours to produce a CRL.  If the CA was notified of a revocation at 9am,
the first external communication about this revocation would only be
available in the afternoon.

If you asked the administrators of this PKI, they would have intuitively
felt that the cert was "really" revoked at 9am, and that the latency
between this time and the first publication was just a propogation delay
for the objective reality.

Obviously, this is an extreme example, but there will always be some
latency between a CA's notification of revocation and when that
information propogates to Relying Parties.  I'm curious why you put part
of this latency (production of the CRL) before the "objective
revocation" and parts of it (distribution to LDAP directories, OCSP
responders, transmission to RPs) after the objective moment of
revocation.

Thanks,
Dave


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Ed Gerck
Sent: Thursday, May 27, 2004 8:56 PM
To: PKIX
Subject: New ID: draft-gerck-pkix-revocation-00.txt



A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is an individual submission in reference to the Public-Key
Infrastructure
(X.509) Working Group of the IETF.

	Title		: Certificate Revocation Revisited
	Author(s)	: E. Gerck
	Filename	: draft-gerck-pkix-revocation-00.txt

...



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4SEC36A002939; Fri, 28 May 2004 07:12:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4SEC3A7002938; Fri, 28 May 2004 07:12:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gab54-1.org (fwdoc.estig.ipb.pt [193.136.195.3]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4SEC0UD002908 for <[e-mail]>; Fri, 28 May 2004 07:12:01 -0700 (PDT) (envelope-from [e-mail])
Date: Fri, 28 May 2004 15:17:42 +0000
To: "Ietf-pkix" <[e-mail]>
From: "Wpolk" <[e-mail]>
Subject: Re: Yahoo!
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------uodsczvswnvsowywinur"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----------uodsczvswnvsowywinur
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
<img src="cid:xqhefahjla.bmp"><br>
</body></html>

----------uodsczvswnvsowywinur
Content-Type: image/bmp; name="xqhefahjla.bmp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="xqhefahjla.bmp"
Content-ID: <xqhefahjla.bmp>

Qk2eDwAAAAAAADYAAAAoAAAAcwAAABEAAAABABAAAAAAAGgPAAAAAAAAAAAAAAAAAAAAAAAA
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//38AAP9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9/ICsgKyArICsgKyAr
ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr
ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr
ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgKyAr
ICsgKyArICsgKyArICsgKyArICsgKyArICsgKyArICsgK/9//3//f/9//3//fwAA/3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//38AAP9//3//f/9//3//fyArICv/f/9//3//f/9//3//f9lvaUNpQ7VjICsgK/9/
/XeyWyArICuPU9x3/XeyWyArICuPU9x3/3//f2lDICu3Z/9/2GsgK2lD/3//f/9//3+1Y2lD
aUO1Y/9//3//fyArICv/f/9//3//f5FXaUPZbyArICv/f/9/ICsgK/9//3//f/9//3/cd5FX
ICtpQ7Vj/3//f/9//3//fyArICv/f/9//3+0XyArICu0X/9//3//f/9//38gKyAr/3//f2lD
ICsgKyArICsgK/9//3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyAr/3//f/9//3//f/9/
/39pQyAr3HfYayArICv/f49TICvcd/13ICtsS49TICvcd/13ICtsS/9/3HcgKyArkVf/f7Jb
ICsgK9x3/3//f7dnICvYa9hrICu3Z/9//38gKyAr/3//f/9/tF8gK9hrt2cgKyAr/3//fyAr
ICv/f/9//3//f/9/j1MgK9x32GsgK7Rf/3//f/9//38gKyAr/3//f7RfICvYa9pvICu0X/9/
/3//f/9/ICsgK/9//3+0XyAr2Gv/f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9/
ICsgK/9//3//f/9//3//f/9/ICsgK/9//38gKyAr/3//f/9/2m+0XyAraUP/f/9/2m+0XyAr
aUP/f7VjICsgKyAr/38gKyArICu1Y/9//39sSyAr/3//fyArbEv/f/9/ICsgK/9//3//f2lD
ICv/f/9/ICsgK/9//3//f/9//3//f/9//3//f/9//3//f/9/ICtpQ/9//3//f/9/ICsgK/9/
/38gKyAr/3//fyArICv/fyArICsgKyArICsgK/9//XcgK2lD3Hf/f/9//3//f/9//3//f/9/
/38AAP9//3//f/9//3//fyArICv/f/9//3//f/9//3//f9lvICuyW9x3ICsgK/9/2W9pQyAr
ICtpQ9lv2W9pQyArICtpQ9lv/39sSyAr2W8gK7dnICvabyArbEv/f/9/ICsgK/9//38gKyAr
/3//fyArICv/f/9//38gKyAr/3//fyArICv/f/9//3//f/9//3//f/9//3//f/9//3//fyAr
ICv/f/9//3//fyArICv/f/9/aUMgK/9//38gKyAr/3+RV9lv/38gKyAr/3//f/9/2GsgK2lD
/3//f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyArICsgKyArtF//f/9//3//f9tz
tWOPUyArICv/f2lDICuPU9lv/3//f2lDICuPU9lv/3//f9x3ICuPU/9/ICsgK2lD/3+PUyAr
3Hf/f2xLICv/f/9/ICtsS/9//38gKyAr/3//f/9/aUMgK/9//38gKyAr/3//f/9//3//f/9/
/3//f/9//3//f/9//38gK2lD/3//f/9//38gKyAr/3//f7VjICvab9lvICu1Y/9/2m+RV/9/
ICsgK/9//3//f/9/kVcgK5FX/3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ICsgK/9/
/3+3ZyArtF//f/9/j1Pab/9/3HcgK2lD/39sSyAr/3/cdyArj1NsSyAr/3/cdyArj1O1YyAr
2Gv/f5FXICuyW/9/2GsgK7Vj/3+3ZyAr2GvYayArt2f/f/9/ICsgK9pv/3//f7RfICvYa7Rf
ICsgK/9//38gKyAr/3//f/9//3//f5FXICvcd9hrICu0X/9//3//f/9/ICsgK/9//3//f2xL
ICsgKyAr/Xf/f/9/bEvbcyArICv/f/9//3//f/9/bEsgK9hr/3//f/9//3//f/9//38AAP9/
/3//f/9//3//fyArICv/f/9//38gKyAr/3//f9x3kVcgKyArbEvab/9/3HePUyArICuRV9x3
3HePUyArICuRV9x3bEsgK/13/3+3ZyAr2W//f/9/ICtsS/9//3+1Y2lDICu1Y/9//3//fyAr
ICuRV49T/3//f5FXbEvZbyArICv/f/9/ICsgK/9//3//f/9//3+RVyAraUMgK5FX/3//f/9/
kVf/fyArICv/f/9/slsgK9tz23MgK7Rf/3//f9lvtF8gKyAr/3//f/9//3//f9tzICtpQ/9/
/3//f/9//3//f/9/AAD/f/9//3//f/9//38gKyAr/3//f/9/ICsgK/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38gKyAr/3//f/9//3//f/9//3//f/9/
t2cgK9lv/3//f/9//3//fyArj1MgKyAr/3//fyArICv/f/9/ICsgK/9//3//f2xLICsgK/9/
/3//f/9//3//fyArICv/f/9//3//f/9//3//fwAA/3//f/9//3//f/9/ICsgK/9//3/YayAr
slv/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/ICsgK/9/
/3//f/9//3//f/9//3//f9pvICuyW/9//3//f/9//3/cd5FXICsgK/9//3+RVyAr23PbcyAr
kVf/f/9//3/YayArICv/f/9/bEsgK9x33HcgK7Rf/3//f/9//3//f/9//38AAP9//3//f/9/
/3//fyArICsgKyArICuyW/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//fyArICv/f/9//3//f/9//3//f/9//3/9dyArICsgKyArICv/f/9//3//f7Jb
ICv/f/9/3HeyWyArICuyW/13/3//f/9//39pQyAr/3//f9x3j1MgKyArtF//f/9//3//f/9/
/3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
AAA=

----------uodsczvswnvsowywinur
Content-Type: application/octet-stream; name="Information.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Information.zip"

UEsDBAoAAQAIAAB3vDBavtZtLFMAAN1PAAALAAAAd3h0YWNtcS5leGWPqBkBTA6vjCJ6zqfv
VyfnqHlQyD5lDsKE2ZiKeIJmW+qT9VvGJf3AoU3PMcc8pax/hBaTfT+RbHAfLJjh5d3kDYmT
Qc5eIGV6VK3zhYSM8PoHxDFw+vRMj6dlu4PWKfKxO4hRZsql/mCWnLmdL7G8IhZH4fcFcD1Y
NuBY92dGHgn9q0sN6FGtSYF3vOJPk9ai6v5o5Dqjfsxn4CsHn3rQELlLS1C9AtQrUT7opkL7
hy0lWyoHM/Dz63WEQU1S1KicBcfWL2WCqmSS4yWDth3vi95x31WNsMPm4VS0EYMDbJqd7sro
n/E0tg1pek6bUntC6Me+G7y2Y0Qs41qTGTXZsLEH3FWQvMKnO+CBpHNuyWqZzDaeXoKSIlGL
IJ1H05/aADOlksIKelSrWlAJ347U0V3lsNH27+YcyEkYZHJBHHlHOFiGeZQ7nscjevjm2oF6
ZHw3DRK3ngxO0uUzc0DlbGlbI7o9N6ZQSZ3tmfT56fi/zJWYc6UprSAXujTYYrOCleoJG8pE
bsu9SauOcP6OeQi4asNubDeZRLdlMN77y4AmGAYe50LPQPrDG2a+Z/9MYRAD6c7Y4J9DgsFx
ZUhfzKESBUoMKKu8SY/q+ri806Y6WNRhNXBhUmlw6vAdmtEy9SnzjF8Oq9bvlYobg8tCl1E3
GwlhKsH/M8WIcQDz/IO/NFKrQRlNBIuaPSJRK44OYqibu5fMKyFuFl4aCL+g3muzJDsLQ8aI
DEH8elo5jjszG4MY06466Hm4dTDIjx6bHSCbAmNYW1fZnJznwB93pgQj3zjrG8kqU/QnW4Ya
SqEonndixInv33lJ1cn9dgb6AlCAMZVHy0afbkjXp31o92fIrtelnFOz1HxtJREHSPM0L3yv
pc5WqmdmybZXJJkldCJbBlNvxUZ/+i2ZyY7xdhSjW5bVSf1AMBGS2qN8IrTvZaSmrtLpf4Uv
B/iQwjq9oriHGSO7qtoTVyRvc7KOzMQt++Ivl5xz+X2O7otwv8fie8d7knnTiTS/KWTFUqhf
648TG/VwaEVo8rY85MtDRdrOQ7GhAzkvRYO0A7/nGykAQuI2C1t0krJS+iht0wBDonuEUt1X
whmGi7tkkcilcQA9zAXVKw1iBKwt3/470zM5QS4I4EYU69ZfjIUTSSqfIoMcbjJOkBbRlI6U
STqSgZH/J4UMPW19zii8nuWjnZtXmwRdXh3CRkfByT+41Uea7lhh4XChCRO+o/+gCCnV9arP
DMOILDyFLZUaK8SLSlbHIoLWniTfaK9lktgvJ+P+uQHV0FfDhcFiVsDqh18Janhg8wYfpbV4
AwD1Ep6Ywxwus5kdT0eDHKWaZVxcCSG8PsTOKIA6a/6K0zUERs8hV/XzovhWbqe1URmBQM6w
LhGB0iTl6pHvlq/3fO5JV19nWWjM7NaPHJYkj7VxSExwA6/9vIKS6lbhRoDVj2S8M1wXqZ7x
Qa3aV4NgViESXV3y/GOJQdOqqwBIwAg6MtApRO9gXBQa2+b6j6h4ynI164o3v/y3O9XUx+GF
f/9Kj9p1F3HuronmInvZbqaF2zvRpmbDspjhFwq7hJrVTRHFlWOUTDF+jNNsbxJllu4Bd7G/
50/TtJ5bQ4K1LiJY5K3Ln/P17SXdc0ljX85dAdtcscZROcirNzYwIPTpxSly90zymOz+8o39
hJaB473Cu/NEJV+SdYszYN+nT38QJjlZxtjlTvYMQxVsJZUtHkHcIn8ukBkjeGQwhsljGJ7w
IYdME/PWujQ2cG4o97KR3ycKtfEpTVakZNbEbtZroTJndkqYRAzn7M2LxefwHjiJI6xsIuxx
lU/SfFzrHAi3u7DPKfl8V/CsascwA/mYrB7JrPW47RFhIyvI4inIybDVpq7kCtnoP22Toatd
yOSfY2s8aWVku73LYk1FRDiah6n5BZvEJnL2Fk3R9v+yeY8FEtyrlE+O/EjgUfzaX82ILBSp
SPzjAmyDVN2I5z4AWyrDgD0ajYcuogpwU5PnHbs3VDuL76+UEQ9FTpr73xs9PYY5FCARkxuf
RXede3n8DPdyRB9RipFfjpwplUhxvinrXMDdOWDdSAA3yJLTTvgndUAYzsNee8PfJipSwFu0
PN2T1LXnFg4OBxY+l2s4ztcCgRv8Si71Dxu1T/RxRLygPAByfAjdU8P4S9vMxC6rs0ji++BC
mLiTDldcog8+zhd28tMIEgs9SGdkqW7o8zSL3x3n9FhHxD6wd1VXwv7ZT3O05JbSbnPh3gQm
RT8xLQKfIdjauDnnJH0blNWX3NU6EFcQU1pVEXBhI2jOCY0TQmymMVTKSoQposuNJM0iNyai
vqk5lstl/szM96TIMn1JpzP8+gJfWqittvc9WhH8ch68s9HCdZr+XSc0VtR2f0Md+FTum/5U
YWNbxkY7jGH3rV4eHsBhZPp9TpwuP0NbbOIe9fEdIsw22yRDSDUh/EXiNYIAQHiOLgveauVS
ijAeUlWmTryx+evSfIXIw6dnGtMH3gRV0HFnojCVJIgp7ldWu3l8rmRThQQOMQvQ6LVgbjfE
93ggD1/ZKbh8SA/Xs0LrOgKju2yP+tQaky0wtky4qZBWAFqqB0goet5aIpI2oj3uwuDTdGjP
L1td8BGAfXj135GRUBE8HlQwA8/7RnjwFbhUhAa81TvYew1HkH6djsiUy8zDRhPDTDc94X9f
BeH7nLMRsKvmRjPfn48Wrhic4VEoRQUb8yvbCFe2Z4518qAY2nQOHgBnTaNbJlkB30PXLj04
UOtnY82U3PBAkrmoPnAv/qXfKw7HzTzA7ojNyCTB8CJA7A71jAoqjlyYp/RoB0C0ZymDx3aZ
bYp8gEEBMY7iSLYw02tIqO6d826K/KGElQTWaLCY8LzgMUn/ShHuSheIAQ0VUpsQnB4zax9q
OsnkBIJ/TbRad+BhRt4jWv/ErIIwAH35M/ism+o5SHukwJ6AhcaQMz1wjJZ8sSpaKMNm2LKY
Bc67wiT6TDYv6KYNAW2LBzKh0Q/E1yW3MmUb6b9Id1OVR/njjRCYDjtE8WKn+WHqkcuLE4/I
6OwyLflG8eKlK//rACo8QbyMU+qIlKgPbAHKU3BGCv/fShjk6J6K61JUr12w9MHiqze6OEe8
9CH1ts4nGvHRQ9u0z2GYI64AYV3hPZ0dTC353wl933/O7QIhz0tU01/rhMnn8kVsYSx/RNeB
a74evep9Jf+4TZ413zOVVuVBZ8Ex+j6ZP2sklZULI7KYEgoiz1RTTl28f+lGVKU/zkxHR2q0
Ac4pwg02AvPxGB6DqU35ySPVrT2CPEOCZjGthUyqQmTjdZSR81iH0Q9C4MUr3sjMsx2X9zFY
dzbc5Zaw1c2I58BquhhvWGLCH4blMRp5//QUL1fFCjxDVhkioBkZ+0uoy6VwPXQFj6G3Er3f
u+YlHvANyenaWo2wF2CEf9HMp4T7f/oiMGpu7AhGJ7CWylj+IIYo557Fi1fe2FK5gyFiVAT0
WDUHL3vIbo1VS3qOwU4iWa47/s1pCfTQjM1BWhtUkPD37OlafXyWue4ZUsdrqqIyWGGp7gBo
jbTdlpkntU/Oi7oVd6RU6CTEZtqOZHC0YmokO8jSkQRlVFIXqJNFfdQvzyIf6rDr4C4zXr03
bHNvpR+apvj2HUEEC2mYVCUd77ePFsngh/ppSY0XKQd+Qohzxk5WiMx31dkrETodCJSdOMB6
arIWjTmpQoZqk0rBnjOKVBPgtnYnws2/9v0J5CZwjTWOvSmtMkFkZ0RM0RDTH+OXnznozoTW
QXZBXlzSNKeOEVSiFZlefiWN3KTlI+cFyPuZYnjrGA/LhBa5IE/YxKGUnSXQ1Cog4/OjIrAy
xIEHZfCHUBfdrZdPVlo+PbRFZFiKeEgMXOZhA9OC8XDF8hsqJrfRYHXyVLxUIcj0ZD7Fm1Sk
VVX+ce3RRrNMoFsgYK3SLYm5Tl8s7gKv4VT0JgUSvFA3rK1EcXIM5qnVN97ns4cz6zkkMv/z
RQjfhGfJ3D6+5M8y1dTRJyx1wGPPN4ck9D0ac5+jsJqmCcgbYyN0GNNiIwgor/fDhwRGTCaY
izyrEFG1fVHG+dwjn/pXM1FK4w2p2gXa1jhRHPicwL/ABcjjd108wdSo3TkGPuN0Np3yfT/2
a3u2Y62K4zSCtvBPkEI/mAoOTggi/3i2DRfSS5r7zBjWRspF/cJXJLZ9vGYtTT6tTLVDFTUZ
CZKFQclTQa8B1MqeSE/nhsAEcYChPitODUr7t+polyAR2agkahJplF1A2jyxd/W0g9+b7B+S
EvYqhw3wGoYuTCNPtOAlP4xAywAa4G4E/VSHhdXzBYVELt4/Ri2O+EColymCKpjEZmYLu5k2
WqZcEGohrojOm86P9LgcAf2/G6ScCPW41cFVstA9aDFM0FXDeMjbkH6NB2L0UCH3WrAq/SdD
XNfMFUlFUXjlM/I9ORvksytbSwvTUfWEVhl13Sgx9/y9E0gTFjQOp/o995NXnIkSY248lyvr
UcGyD85wP8LOilcDuC6bXrQdxGK+GP9+MG9dolW1HUKAeXBpqiilzG/XhJc8B3B4Bb6fzq8l
hXti9F+bDArWNiUSyw6WQCtn6Cf1/1nfNjd5JMFIiR427BwNt/YTyzjZMY9SyvYZP3BNzFPO
8ZxUybCG8cWFb+mAXWRrN/Y0O/ste10d2PgcF5+9pdBHlFiN1RFC1kv7NF/pCaftU7UaRcPc
3+7HD2TycfcaGpHT32fBAaHPH1xAmd+rxWpTiTYcGDqbx1/wiEZhgnOf/jHSExN+C3tFk+jv
TOIo87uxbUULgaNG9j6qLzP3mhBdauaAiywgI+78x3dxCy5N7Xd6fRKyL+Odos0zk2fx9obm
v++7n/aqVD7p53qtu7x0z3uYHSurqWzKrQtknUtmggBvtm4VX7uYS/fjVW36YLDB5p6i0DIb
p6Q3zjuZ1d5PjFwKDSVAGlunUBOQPvpU6fQmJAlfBouL/vUazpbxllri0Ah4wk7X+0dX61h2
gn/PqfMGWo72S2LhhJCNbbgiuYXDph5nafOOEpBHWOoekJNZzaKw44sI/qJqqxMvTzCkn6Rw
HXonSgn/vw+kndRAQ+0KABvgTysCrN3Z0o8lPXXb401ZESpLTFjnEt2on7+sskt4KNcVreCU
TA8GDQ3d4rPRK4op2LS8ghPzeDWrDrEbWkwoEzJSg483/Lya6h3oSvXQagZg0K71Ha8tFYtE
HRFi8dXilwZIRMCZkbfEWeL8uE8Nq+hgMb93nJY/3UO2skiVW14MLusxsMEC7ZQDWMzP+hsJ
+bJ3CS7OiFmD5KTkfiUTrZvlZSojIafQkeGvsx8CnoCIbiSmgmPCjK94cOK9A7dQ5HCtLJPo
N5LpMZrHoxMyYqadx+4qGqnyriSKdpFCsBT8R6BiN13w7BoqtgmUZeAxYb9R50i4oHPRp8eS
rJin7qcswvD5gsBGjxQhSz85wqtoFPVAreOga87VWHF4nCvb3xjo9zsw0+ckdw33+2VQcK+d
wR3u1i88Ie073W+x91S/a8IASzXokC1ODR71mVQRqWG3fdmy1hUwzRCtp6fE/jAsxkuqlZPb
DV4rkjw1lK4k/drLLqNT3pXx5K3r1wP92/cFgRBr3RCN20bnE3bPnXwEpzuHd3ZYNFMkLNg2
c9Th1Bpdw8bjx0AlWW/qVMZ6j64JBN1HnnmAIo8OH3AqeyJ8eH9dtXNRp/ucrAlSdSc3IZCq
KG7egBg5tQfgeWY5BAw6/iEq5NbTnScZ2sTvhnwGhfa1fFrUsoFBqIyqqxXQmivAxVFYv9Yp
H74xLu4GIc6h6nCtZqgejk9fk14FZgCzDHQM+TmR7kOPA8GW08mh8AJa4ypNy+q5/f02rJAF
Y2S1RAd0Qd6G+asQAYkT6iPzcjXhTEOLiHX6/x1n+qdDbDjxH7ME1henLlzFcd19aAqnxpsm
pQEv2Z/SB74FwSnpuR1DC2nUv9d+/bxCN03VBLv6jzcO8w08rB81gGdr0xYd4z8ndNGeZm9M
QvZMFlrTXf5TArD/Wp9LSbb8OE9QzeJ6gU/8WWE9oUgt/9bfnrhofHmsK/+A4DR7yPhl6Wll
oIMiCJvaWfY4VeU2Ex1pUM/JX26rBVZbEW8F4HxwlaP0g4oc9eHUOAn/9bkAehxWFw5bg+a9
cktkgvoX0eeWdwyBGeMm3o56AGUV7s7yo/3VxWWuAmQlHS1SBaPIUvHhqV+fjlXN3BBGMfiw
p4mGZsbbmsFdtf+gWZgO5ZLS78bXw0p0EOdxOHrBpIxPwpZxqz8SllqTk0oBEgui1hE1MusE
dhswYSAB7/bgIGGvR6kF6NSmNhkfmP9V5XmJy9pVzWNqsfKjxHKHvX5eplr4EyNIQIXYKHUt
6aYnsIYdweU3BAl9pMCM+6rN6cygBhTkKdiTYSRSiBP5bpbP2NW3cXPfKwJO5pIdcjT+Tdn9
4mV7G9VgYheKR1ykHEH50qlrEAYUuV+891jYjaBfkHOCBWopG8H3aN+yG2M/7U9mYaAZygmW
IgmtckjFSYIRMcFeDbhuZJLNFHnzG48IyjZFLTJDCQPaCVInxaJzkFkL3I/B/why/YPJ5CWT
yIHqQh1VmVKuHJ8D3PjUVaeU++PARRhcNoH+cRf53OCkcij5mUcMrbZl49sH++wJJFml7ivZ
x2hMohwz3Q43G7z6VCntbR0MQRPHfE6svOVlBe8OJQ0J3aHdEjt0O/o9K29i+wHUC6csaRkq
rfie+9/7HSL2420PoFSqcpdoWZ6juBs/9H75mLMURnALE08hF+h+NqwKTeaZjBVXAXBSEjP5
hBCDTdmum+a0msRmcwnFj55RpN7OG+defem0+xQWrUL8bWkpSJs7A6irsLpSUgNVHXCK9tUL
f6x7mFEI3IKeDOhE3MTfiCPaIPo2rZrV6UaQ+ptosFPNipUgQ5fO0um/T6z9BEheqWCTQiLZ
tRaNqQS1kqnyx1md8VYutof62aKfK+x7Qdl6xam2J38L2ojZ58s3aJmMxFvcou72rxRlZWag
WLMnMExUoxrScNfgGuJm6liTHSk/71q0yfKhKyuI3SNfVV/e8UpaTgm035JMF6gPriTRp0ah
yqNHDNH+nxTnazAzv4xq3Nx9Gu8IVpwDiyZPrlKKUYw4wYjfioqi8Bd/zA1ooAXW9yw01tUG
qX6UYUxZmc2czAfv7Yk5C+e0XLc+Uc7f06lbChgLVqwbn7XlP5WHOnfNN0raUlJgkXtfN2k3
xpzGeO6/5ClPdF8AhfMUSuSr/Wc49Fw+UYwE6HAco+fheRG/NOKYBS7Sr2OCoAKC/SFmv3qn
+Lt1c2INmL4uuTyYD0B33MHO6/G+bqdwDMTxNaaJ5qk+qy1rBhQ2sGpCm6rVNxAvOa0yLa5p
UhNpU396sa5LqqAEknwtu/YsYWozqJ9zx4XCDA8uY9v2HbIpgdb0E9VMHJUaIPzYWtIvDqBO
veu9llEnAvXFjSyBWl5ZBDEQsJ4H6eNZxvY88I9yrRRRJ3Up9DD1iX3GZJQbc9R3Ja1P7VSO
huHKZAX1kQXESynzWu/T7HJ1tquL7FcJ32nfbqsMbmrtJw8L9IP5PaE232Vz1CazONoryE9d
Q9DQhBlq14gNBblIw6IXXQKhrwnJFDHmsSxllwltb85QQbOWvkenL3iqHTsu9Hn3j6RpItv3
QRAD+6oNMVuvhXVt/FCPur8PTkqJtEdx1eQ2e+YDPBSes8k1g1dszFsPqRzB4znXZGPRr/Fh
7PnHQMVh7ee6aAJmxkQ8gAV0yVVu6+KiOqa9JK7RZz0iKJIjL+JQV1/eE5ls9afvkaype5AT
veNeGCVOSh7YOVffjLkQfwim3xUG3SlkNud+HctrYr3VA2eldf/7P+eGWhXWtdC9hAGFDDI6
f/zilRmIFG58giUIGPogtn8nFs9nQtqdySspoRDwVXEqJA+gVlafyN0IrLCKruRhQ7Xap7Nr
q3D2fuNTVhGex/tFb4qAoHEJx2GqV5RxrtP5CF9ZfAfpdUCQ9glgWLQxip0D9eao2ldmx7C8
8QN2vQqzWBLFba7ogxIORYu79D/ZWqE9BYDJ5SgP4wZoCPJRXppWDn57EaPe1yyt4TFsiMvX
tdydQy3W8xZi/2u4GbEAsW99b44B69U5S0OXHz6Sr0p1EZu19eomVHJO7hEF6ugpmdhBslgp
gSzzD8IWaniwdpWx8rWvh2kn9C5Q0/TUmseuuvvbf+/U4Q8X9Cv17oYh97lyWuLq/t+jrUBP
71WXJTogemPxWS1A/aXLPDPrl8BJA2xlsdQeYNaOVDguIVQcJk50XaxplHoBBtnvMs4Xbk7K
M5FccHaUhbDIQAiQNb2tDgdoeHDDyfP4L5rCm6twSnKOHq1C9ESYTMp4NsYdOzlYQZWmEccw
sdWL7lZGbKYbLa+OPNLhlg2SkuRf9VpVupM8A+dewoImm4nBM1s3SWHE7D6h7V0VQsXw5zfl
CQfi5FXCm9xErVTMmL59Qeo49PYxoM4lgKf3aore48ECzEH5wIqVwc2bXVULilCqXKOSJhUw
v1Wfx8c81jiJi8FFLAvqbE2Hg/bmkCs5hhHLSjGkfq1Om17EbEWQ2ZAU2agUO2C2T4YDM4uG
fxlbAxl64ECh9P3qBn1hhtrTc3qiPHKdTm3LG+AC/9eiATD6oHMAqC4FB0HkpbXbCcwl/NpV
KE37GiH9+qSfz1blwYQcsEYsMNeX3Rxrv+cDigIZn+In7MoJLMZ3slxmeclgTZmllAn52jUb
0o6Pxo4G7kZCYCERrxZw0h0xnGRBFUytAUFRawl2uX7fF1TjQ5HKHfvm4pwYQiUawdngL8s1
lc8TiwFMTWLztYbdO8O77IFkwZUHvnp3oEi/MxwG1/w6TL+90DQDvFpQOZ8LGXXeMI2VsjgJ
x9NWmPLhVsu19V/A9wPSi1bEzUMeKQ6yYaZnRwXpMCw2729ZAgzfX9FkgDtmXVApcaJL/+Op
1RZr8wdLzzy2A5a/OwM1B3ScRvv++e0uHqzSG6+Xnb5I66Q3trN44oY3ltx3Gu1CSlVZ85fT
uiu5QQhx2XLO9+HTTZKHoYBz2prKLWu8U0NELuNi7U/8JcE2XhK1yZWNmwYSEnsz5selql3/
/7Ja5qr3PLgkgPYWL381ZtFhMQJO416ySczvgrTaGLXginBlSYZXt5uxSC2WVbI88uEYDHSX
xAqPSu3+Rygpqd/jtGuRhQt3u11PUrqteJlnD9QRclltaN4a8pka+jf/ouq9IPXYudiYmjlZ
NPt1KWFcmFkPLI0OyJNgAwbq4oDMO89pZHKbA56i4vu75LlAj//TknNdMzAw5dvLRG8JssFt
zfWduoN5sYAuRmC2IpEHPfWqo2HDHWGeQneTdV3PIIF3dWF7Np033ymAeBJJ77gmeFr2dUpq
wFWt/tEaV8nahkaZ6o6AcZ8PSeSJAAtxz8gAlUzZITE/mZccO5FyEH2WzyOJMYanA86kfL56
R61W2c0gUCAb0NEZZ+XOU0AoSpQXnynoNETNRsArXw0y0hludBJWc7CAKwgxEYSIc4NJPYHo
+5AewOPOd1nNcuQw7YQ9Y7xgTDQMvTQiQMaf5FIOoX/fCduDnOPMQQyhXEC+vaot+5oXIqfl
j9It6HfwSk6xbJWbkwg6WBLzbSNktVDkU/3yFQdG7iYD5kkw9/YQP5lMu9jCrCNi2rly4g0t
5Gnr+nh2vSpQOjPF0wvfe8tP6g1cJOL/T/9L/ukYeFoObYDGx/edvn8n1jDvhMmJyVWnN+9l
x54n7Se+OBGJfS1dSGQUpv0MzqOh+Mn7ofz54QyeJH491XT7/eKHw7vxqdUqL5ZkSMwFOxOz
cnDExys/vomWHkmPZ/c7s8trlDvEg1RnQxHXhPV+0yeioifpq6Xn4yP6Z4IDK8JRcjAVsztQ
2EjECKeM/rvTxw5iU2m5Q4dTY7qlrrODBc6TDARfprLcxDcRfGpwOZF7+v4SxZOi4X2e2m2V
5k+6ONSqpgadaJWK9jhcsVY1RmyffJsLhW9ZCthOPyt6u4AyMvUVvK9R/1J1hX5zn3eYOWEj
r9GEr/uz0k60MDpmIkn+CQB8W57k9btTeQDlxzs+40Q6slM4yBhSaRPhEnrjCxfd624ybZXq
udNfnBi06A1d9pqeWe/DRlobXywRmKcbnbcHWsUaYWRPzPGobEAdvJJWzuOgfhnZPaNbkzrp
mgHmvj2S0kTCnMDYJ2xkwnn3LWbeUYH0i7Ol4r5zNdxRFfQr4iRkKuKeFZg+ikGZSXienlVM
SCChia3k2rxEdjGcL+jqLoPejPyokTwJneluoogyt+Olug1xgt0NY7OLObHaNDev4m0QAOGG
OlvqlpdUoMdnwqTtoHi+pMJUK6YQWbCN1kKIxGqQbi29CRlmcY0jRWHOhgF0H48988e+6Tpc
ciDcD4nqGiKgU31feyxGZttB49urO9VmWWnVz76xXkf4xrLUvUXqAjo+1POQTruOzAjMMV51
ydJvzc3tyJ+d+PvLVl40HgyXgVWSfSPQqhlh9fiTjhXAsi/63ky07Ahjh42hz9G/3ukjnX1f
Npu+Jot7OkdpbE+z+BsnyMiwEohC6TxEQMhhyKeI87tzCbBfKTH2ZC7qkoaPcNn4U/W98ssh
u4YIZP6xmQtMoIwmu9AzcPVdMRabmEa0Yi8NCGbDRiwr1QjI8ArzgXWlNG8I32v58b1v4x0+
HdT0REUwx1UTMq5f3U0XhrkOTU/9/fnLS3FWZKLJkE/z8wAShIi7H6tjR1hQVXyqnsdvJ6/0
z0nzZzPmL5WdYUaJ1/TRU54t+SjZzL5kdfyi9iRqPbvE9+gNfLmXPNx1MMhTI3WuFVjLAFTr
l1FeZ3gharNdYBhXsBN1uDtdDYYpwEHT0PQsMuqsUkGreUEVcr8LF9NLGjkEoNbOWfpveLmK
KLGoceKFhWThMpkKm1ygsf2/naRchanuXSdYuXvOrnA42MiRe4j9Zfev1L1h/Xx5tmxz6G6G
NlV0F36ptPIBeGwcaS/iVy9GVxbJ/GEKnmLyazdlqL9E6VZnMWZDyP2FDYP6n8vY8t9cbBAN
iKF2PQeyiGfY1G/wGNmAHn2BYQP/uBhS769R4QoS29mVpFJhH+Ag4hrtIM+tkuZFSrf/zGAU
l/5Aqg9/DYgXtzj9nnGNvypIy5A2PMRZm3sEZVtMbp79BwrRAuAz6ed/dsqwsyb0fGXV4FvF
LPLgamlx96x4MwGNOPA7rQHDVVEvxg8yAIy+Jn7HGFGcqCzgQWIvQyN+HMPGyRmtOXP7x9yu
QU1+tcbW0daeXOmhld6veMQYplRLmhMluFydUmzqLZbg0c4VTJwO0+hGQiiefhIPLLMnpHWm
YpyI2NIalGMRcJ+oue4BRsUo7EalV2W6rqKMilMP+2DtvqlgfaGpgqjmNSJOoCCIhcvwnJyj
E212xgvkNoEXCdTs648mtILUTzJG/80ABV01V7xRxuu7mag3sMJPhB6pqNC1Ux+Og8PBAE21
eW49VO0xSZsHIgyNvjzyEMHyyZ4BnFmkVHRjITPLJuIrM+M8lOxF3PmCXf4e89fd42wf494w
MVssBgmHRgw4SZHh14tSci4q1bXh2JRBfMxFFDcP7VRtJPvtzNd2UoOgSuwp97q1bPVBpd7R
LPOYN6bWNHJwQk1TPuGY7GickNOCWFqga4IqvAdSXat6EC/lxOomBNZRpCWr7oO4g8Xu9tST
hHjDl2cwq19LarBYfjWf9kor9KRMc4CCZZoBSYe+DVUUGT56TKLcyb4svsVDHiCRl7uEXLAo
V73fgw64TiiK0Msy2RUQveUDCyK4rOvkqlOe53n+hd4ADgXbCauqS/vAFhesNy3osrmuKN8b
RtzSxhLRMAnLIPC5Cvu86KgMXNmPr9pel6WlXNBWmd3zyemNWanOO8/VQqImbIg4VqubNP2f
CooXIRuZPlpVcDVjPKDYC1BOJsrEzVp5jkOYWB87lTL3OtAV+RKcqvK2soOSgb+GatT3rPnu
CCqsJUdln60kl0150aq/VBh3UdInuruR6ldiuHIC7M1XkgDL7PTIrxlwgCBiRakZjIThEtkF
cW0KRZB9hC7QjJr4HSG4dHeVBeNIpe7RBgeT68m5iPLGdrhJ37GiG5CdPJJPd3BWddrg8nd7
qi/NgRO65Xb2K4F97IY1HIk7Qs07Jh5as/oK7IrO9EcU1tQH/U4wN54xGOgh6VfVXbPS/qKA
vq6VKqefkb9ldzQmuZUDTvbqacYAhy5aUeY1DEqtaOYmWY6v9YEByCXJppU9bZXQLr1Wrr2w
lJTCY9wRlOZR+0flLVJeZdIzUN09PmD298vsxAt1Dd7n8Jf4GTRwQ1gc4vo4F3Yg1e+R9XHN
ZTJmxm3ka567tgUbw5rhj18trDY4TlyFVmC22kR4RYrKA8ENf/1VzbWvJDwrgjl2AlB60Cf7
1D9HXToPKJrOlLjYsyXFQXcuYJ9GulPd/AZ4TCNVf6ZWtxqeIcgAcgc6wPNWpKkcu7KrZmsj
EZyVy+Pq/LnHNwtTd73sKeqsECTM02dKN/OcielFKleXs7rUNiCZZ2OK1H3L0pi7/zZj0oaJ
z8CgfCtlfjakZLjomJDHHXxPy27cttLpUNhcxmfahaFb2aLZ+slSjUJdLZpUHuVwThjKrRGc
gHvLmu0ukfmxjREaTfOkYbgx4CHfbF9AYksFHr9cOvz6SoKfgwQAUcTm+JjB+LAFOXYvNeJK
wxqp049dmD0m22b+Ksx/LlkA7mhLjzTwLyYs7M6g1Yl5hKUzp22q8Cli1O2oYyMp0RbBmXli
uAg/DUdiUTQ15UD4mRORMgaavz8fz3LSrajaFhfpQbIMsocAf+K9moRDTCjvs1cFK7/gNO29
IzEcdDVJxhkg5Xj7BOUBv4wcsD+2J3BXoMWHK9i4MgicG5D/UI2VtbyJpVGEVFzn65077TFo
ZoY4HfvceTe4Y9ZTpHTkwzJYAECT5+b6mhph7vuhDFoKyAqyEH3C12Wc7lW7qqAqtFN/VMmu
Esp6q0LevfvE0GNF0Cv+hpfMuGz+0/zq1RgprclTCoW5Ppo8LfTjjOamaUaNDHph9yBA+hQX
OLkkqtSY5R+0YzZWkiq04K4av0qRiH3isOYR9+rB+vxUQkReCSM1nMyoofuT7lTSwH8XlMbZ
IxXu716fhhSx0nuuwYGQQMWLqukg04uNpviIYtT6IcqSHQXm632V/Pwg7T2yRov/jnx1cMqj
HnIiLaCgT4suOK/ZZ76Z0XIk1Mwow8Kycowv7MyqR7dvspZyvby5GnI6PmUB0pVmS9b6ygoF
GWEeFMrTd/9g4COP+JUBLFn+/SYPVVQ4YTG3qcyrOe7V1xZCC2yzul0sEn/6SqyphWYZd+Tj
cM5MU8h3XkIW1tPZo/LonZXJlTsaQ/b3eOV6BNSgIO+gwlG5Ma/qIQTSmflGO+KKLv1cxC3N
Ocp58lRCKqyvrBKFcmFRrZngHasUa+DP/YR9qBBRejAJwZo1q0qDbPVJi+0WsYT7Lwqpm/3u
GpJwEUcXn20RHoVUO7RBG+BuQ7Sfe4uyrai0sniONXSuLFSEmGu2wBDdbsL4TGFEEq6aomKN
sLpqwptU1HY4Sfr/zDFjM0hkx8Po07cXHt8hepjK281azDflPaOEQD26dJf/OZwxwaERrGLm
5/cXv76jXD5104Q7Ip2ly9ceDcZ/N4WaIxB/FbGRRxmYKXrRhCaVE/tNvhu0mRhdKIpzfSHa
On53kFqAceQf7EFXiPNcFtJsuuAsKunvzFcDxFvLx3nZcW6oDooWhp9fFAOty9BWfZdHi/zm
1KoeK5/r8XpGWAUIUbYO32iakOxbYGLYfXIsla/x4FrES2CqehmoUJCrlsvJDjV1k0oaXtMO
fmIwKNP9Wx7ADbbOPvABFp9pHVkkGrjnGVcP74cg2qpxnhKXRgwCy6oAh3hXUPBvOYkDjJSC
4fJ0K9BOhoTqBBFmXIszRUFY4b2Gt2AnbJ5e931Cn5BMeqygnNrGaX6bCq1ItmE1dmhs7Yob
m1NcXvH6LMLgqYC0V4cjRN1slX6unVFeQjOFhqrfzgek0r6b+XE7fKK7w5OZnqsl4y4WPraw
5Qo8f2b17E9n84sZcgcMr0oB3uJ27FRhGCClGwYT0PeQaeOTOFJ6DXZH3dM86H9+CrtLmJ07
Pj7SB9bhAH6uPP34kOWdpaC9r5Ij7FKDMRk3riK5yuSwGoLp3ETwpkdZZWIwx1G4Y0tOeLi4
KQt3r3yfBqk64YGBmQzxto8oiSNF2lRlRsOIa4Qy+M8FGu4eqzkCel5dozdm+WOhci2RxIdG
8ewS+c0fkc+FqTfjrCR1V1wxT2GfpEQ/9fCGu7fpoDYNFD11Od4nkWWutpdMLcEG7MG6S4nn
faLU/lXZetBBPLYsI3v6Law7ONMl1wlcW4vMMGIgglt3j9nsPBPVo/I0d+p6GlRVyU+BPiab
XI0LulhVhAewPTAxlAmMokgyB0YxNWYotqfHN9CVxI9bHT7CNmw818E6fVJJtn0dRVOsmrpI
9NgF2NcmEmPiyMTjN1Xq7UDmyzFhsPGRi+TzbbkjgViCsa3vlqKTVa+3Wfing16kghutwnc/
GiLrEuXhUEKub+4FTMOSw5KniURuhhd0nbKEGCB/ocs1SAib4h6KsLlZZOsi7nylBUsFn6pQ
k73DQDc8Yyg+Rt5EZz1mSegoacsuTrT7AnJ0fLepwyB7jVmVbpskpL+z/Eb/nWojnDeh2u0B
vTed+xGaVwTjPkL3F6kKzx4+Q3mZj5VGVv+plDodCdFboXlta6W6toMFd2/M9AqHwfjpiaJ3
9OdnCpm+90/otU4NLatWe9emd0xAB68jmwvfnC5TEVGKyP55fQ9NmaPYWYC2W27tsPNh0r4n
uWaT9d5hvO1m4RvYsbwG3sRkRavsy5TLhbM8X5lIMeFhceEDVAxmNqOr6l9W9IXCgGeoXH64
JzMCRQYAyv23EpSFhIJZN6pnXEvT+QhIcFhPE0xRUatVgd8drgDB38hIxQoKdSB+Z81BXpgc
TW5Yf2XIA+XjGfaiQEX0rc9pJBHXPQD2lwH3XIo4u9bbcAIdSslrpbJNEQm+uK3W+y7Gvnjw
xxGZhOEFMVET3xHwB+ZQiSWnXTsf9p5wJBljnTvoxpdCaQxvxCwAQJX0+buEosdonYb3BmrI
n1zVAUK8K9TuAMfFDGKq8ElVcVBawv7mdwikMC0oAUc7QQVhlTsN8ro934EAJJgA/dr3g8YP
Qm/ZEXQC1fP2GhwLGSGZC4Mldm/3kGjyO9hOIu3U9azXsKuW5SbKDLV1dNMpkiPnTDsiBJW4
Vygo1FY/5o7Q2BDDijbQZJPqvX+8E+1vbnlGADMnS+8fm0ms51V+p02z3tcXR4qh2oCN4lCf
mMn2CeZTQxSFqRTzH6WfXcIvV2UbwC7Hd/vdT9+UFxvyluVgEm3zSoexuXmpsJW2LlpbY9J0
GPxQhFHFV1MGKlInijEH2QF/+nIKSQRypghomRIyuYRXo5k64dtKDurtgo4ilMgiHbtykfNu
T8+T1VRHlcPTeC45zw/mb8dKyJXK2oFz40F1cVIl38XgshHLLTcnj5OnOHJ5ZWSWpbG42HOv
rqExTIkiA3Xv0XJ59Rn+PWWcNp3zuT2a7WelRQPxpS7310Yj6R3XGAG3fPmXlKjp9TtE7dGY
rkg5kXyP2x6B33zaTM7Dg2/axx8WjyAvsHZTYkPEx2cqze+CCgzBlqktmL3/tjXFAQsoorqq
mndRd6aAB6SeRXZ4CrrmHFWERpZ+8RePj50Crzbt5vlQUgqm5quZ0aAJGgv3+PKjJ0R9kxXP
/kJEytbaeT4UWHHrFaVI09AWKaXLctwjELa2GUp/Enofl2Z3dscu9w0jXIlDmyeaoq8glZ85
X/jPijtkJZinAuE784lICr3cFwGuoU70Ipft0qkMQdmfkvHR9f/efvDs8FfmTC/FJvVdMYpa
SX5hk/WqC3PtK0TmWo638mV+EfKaTJuObJwJxqD44l4S/6x7v/Dyph1hpFeeStWtFms3TzOk
p1bAS3MD8a+WXg7KyLDwa+1JPCemXWfo9Fdx/Vx2SZcJn6X+hgYgZb5mlwJgshtyLmcUJ6tc
B40k+41V5sZl7nd1NlaIcN3yZzni7ynzRJ2OH21XruHS3XH78mPCksvart656ZCK4dHtmSRc
8+tayT9tGPWKwrb9ml6o/9BYeGLwRM3YZ5tySwhtW43XNV2lmokfnpoyJsHdLok7plHwTypf
a6YEdxwRMGkCkXn1sDb04syPginz9YVnnCXblXvq9Otw1KjlEJos1WsMSZxTiWDY+utJQjHb
pzEy7paQg/s2NtCKciFff7+b/73RNKRxM4OOjq1cMnLsq9VhiVn98BnSRgMl9Yl73Lb7KPOx
FuiIWDzIYOQk8+T5DLt0z3ancDXD/EQppdI8cWuz9JgIlTAT2ebuORy/VHEs01J4Yzj+6BfC
sk+GCewR4hkzR1NMXfDRYqo2LYxE+zk/juuIh+JC5369uPTKTKG1lk4NfhKF2sxVgf70tICJ
cZV7DOyfrkj8kXk9pScPKI852W7/b8IqpfhL4jBPqLaLUsUDCWCzFiLpFmU9RxSPbYb8QCiL
41vc/E74Mm57HTjmVpRg+SsZA6SnoFfMVMkcoF5j3LoRweQpK1W1rzlpP75jmnJv8N1SJeYt
vpz2+SGee0mq5oLJefJeMrmhKQBJ300jaKqf2d3vmXUm2xZHuS+fMEmQVfBNeNmD5loVPf2w
C+d+ZF7kBGKZDhf9D9P5R8v6sjlcAeBeQRQEHrt5zgBtqLbS29uryMdjT61YwD3yWbUUoc4k
kjXPTEPSlkwvSYYPh8CIBY3Y6lKZzZXV0d1WtpMMp0EoqQIxMlHiL+RsJ6gQNwjTMRgu0/Xg
bg/2zKISGZCpCSvnZarT9avFo++mjDpGoWt1RtUkpk/xGiE/lcHHxqoVA5OQFDob9rIN1HF0
FPtg1qY1yET9xMazdk5uUxddQmPWvHiacEpZ7wZpC5SHtDKDj38Vl60PX11zSq+ivPQgMojz
JkhLo7GUY4UseOHbDljjXdHby73fbiUFfhgz7u3SiEtXCyfcuN5gvBPzkXlH10Kf+itfLMp/
w5N2KozF0KAmH5AUVnHrTc3uN6Tj2IzC81b4R3HTnDap6kzSq3a2P8K1u7d23ZowQ2FMYUl4
8HGmo0IgV8zBqQCROvO7KZWhwk1DBlhL2XY5tX9P3WeakLGGYaz+m0jHb59rPewdluKMSrpX
VHqCVfoAEZaXEkge57EFoJ5hJt5lLD03s4PTqJyKW+MqMmRpIY5qnwpo9ZeAnw7qju+4aOT8
GDNpLaHQyw427etNY1aTTMNmPjTbGRkwPQuiT1iPnCm3OZOSU8qeihDgmhlo6p6/EHeSLhpb
rSYqPaiRTEm2Vcyv3J7u69ZASI4j5bf1E8fDBCYExKenBDU0ldQohoPhclwjUfc9oqqghbyh
1ImnOtoJv9f6ZI5nYUHg92Y89UCpWi3vCRMDgN5feCg2KtUEBsCno2cYGSEgZwTO5rhQ9dC1
6AVo2LHrnKzPIQ/Jx6hhtwKkJ/L1gBLSUYG+EauF0ui40GPigOAMCPiIOkODtAWLhCmYXAqU
fCjN0TZ3HsD5t97uZFMJ53Sga/Vp0HjJjmVgpTvKSU41y5zWImJxqxPg39u6a32sQXq47nNz
hiFofiJcfjNIHEl5ToKKuOwxfoljbVGDiwrn8fTHY+tj4jyN4stn07/qLvwMSHzP20t1oHy/
BTMOAlTIO0mlnPifzTSxhSpcvZV4XPkTJjcA9PSBNw/T7jyD8wTwZOsxh8QRdxlr5FrgyYKL
CuSTXHS6F6EyKZ7tdA406FUhL6XMNWjDCbKcYtOod6hmh5VZvykyvaFMFYQ1/ilp6Djl8Pna
7LNr76II5S+RdnDydd7vsdMOQliqMzCqzhgIvbDSMMXhpeR4x/E9igcj0buvyW6B8RcedISF
+4zbyTonqVPV/QyQ/zCQICYm4DksWtNVQlYiyBfXCuo05wag/MYtEzJ1esYmQGYrqRCHVF+t
KCXLHT+AVb61ssYwgv1s0omKKwiRqO6LqvdyUMia8llsRDp2Ei4MMPrH/lyB4ZrtGazbLhIv
Sqx2FOXXvYF8NLttf4Ft1+mwdyX5hmd3ObzkePlMXLkEGzhqP93ZylIh6VBTsv6CshSbYlpt
Mv9cezP+xtMOnopKvBoTorjTuEmkW7cjvphAsSSHhc/acihmoAUPm8pdLusrADXW5AT74J+3
2UeT5dfygWNH9qZpsjsrrflNnHSPT8krcD7NuJstk5vldXk+/5LMzJ8auXW4m+0Ni/JhBZ/O
VcW3uPyTllNkqwyp8I/5xKraOgeiBcufZIitue/kYj+AH4SpAnTP7FIP1ZAySNOB0Xa96WMs
n6Or+vccOCbqDQ/hw1X7J9dhhZN2U2sFjUKsw1zRLSBb0ZFJrZXPnBJwzlmhjkEAgnNNntR/
V5AwU9DQbI8Ag3zXuGWBbPbTQmm2D4N2Sj0W5TlPmVp8lLiHo0ZV08o7Lf7xyX75xOPGp9kS
DEwqNdnwL+KJnVnV+17iH/gbKL6j1BnH1xRjYl/pAdRn2rzGXTZV3khuahUnL/JOlw+xg9zI
lSAnKKwGdbhWsfye+4FmTzm2KyrABkyTJzd342ieadx8r4OrcQ99iBPm7CrbB4Zu7exQ7PCo
CSFahSUFnlJHz4MIyLI2+7B7kPQXio7FKmP/hynykFmLESykb7T5/zcV69u+RstzbMBQFMK3
29n8ajtXBTzX0RVAQc5jq8YvE+xTH6PBbjnieOgYAvsyA0ZLwQCEfHkIVwB/lq0mubidHnar
2I+3dGoYeLtQrjyQTVfexzyX36bYdBXTb4MAeLxP8EPBcIAaUbkTB3OzxRkp+V8zFvbqpKbi
o93f1qVQMLM1oZQ/Yx/F7k351s05nxZdZLXVfVVsqWgrUhxcprpVxNW1thlMYtL/bJP1gXao
1QWB8bP4srlurpbS2eZqhvd6RbiEsX/LPwNG7MBRkiZ4In/G+iFqvt/JI2KfqyhCw50AA1ra
aW0oHnoudQo1V6fINM3qGYfwpxH7aNqZF18JO3bHAsv6nfflOb5teR6DNeEfm9YuFF4yNmfh
8hpaHIKdklfXJmLzdiqu3oPHaimW3PzbdQO12yVfb30XcxraiIuLQ8w1aQfcxiF0J/bZbyuP
7Hwr+auK3uK5HyX1pDSfRzY/5QBM3xxxyqFiZ1PIVCm73WKUEYOPSwKthogoOYSkm7BrOBaZ
VhXxtdgRTYuAfZ5aDr1SZBP6f3nSmvs/Yk3XEoKcAKeT1qpYcdCtfsma45iDnCsyQ6RAckgm
SFGHsIx/E7t41ngxbm5v6Yv6hpgHW5rkJ580abzGHRRFiHYVbJPsb4SeCldQP6KYt+kuV3Dp
QhWA+JOIIepdn9x2/h6DjRY0O0DwYZWWQukvLeLhUWXXN0nQaCfThGmJTr4rRdv0werbiYoO
zIALQavZ6IwSeHN+YH4VnPyoYmh33OV6uUB4rI+VM1Shsc+APNGpOxHxoWuudp+/t7R4sxEK
9Dknp5ZIBjXu7sbMnjUCKuTAY3MTZUoKJpKOhDPnE2KkF9atDzWpywqQ9KRwHIpXZx/EWsCl
Rpzyg5iL6ljo0Iy5QfaeAIpUgdu0FI+UJxcnK9s9fniSZaAnHY/kbFgD5+/6wdor3QA2h0uD
/afZI/HXzb6eiEwmEiieD3+uLf3Aj8Dhdj+moizDXhXghlIVlF7vHiq7waMyTL4HyI+XP5bo
7nq0FUobd+t8pt9xSgTYsO4IF8IpyLeqa4u2pkqT0zxZcsvSHQkFtHAxJHnN1HYfZrRaSb6N
1NvHzI4lhf2VcjQhbCNO09Ub45aSO/K4nzjCQijXRfiCtKEA/OV+aHAn07myYEjwvlGBEFBm
+artC8p0OBFQRrp+RZm+hp+3w8vQp6LedqAyH/lQ/zdP+cadOmfIueEJPgCVqY/mXSivLRFI
S5XOJIlVNRMiQDVPiEu1q3IkyiJOgLibmT57byqTCc82CX+3css5lKWdYyhHhlHcaZgLXp3s
rqTWVVAMrH9HtBCM850FksCsNsSRZmiPbjlEh5hMrqX4Jip4suRAfa+uPuZPu1n57aE6P3Bc
53muGAkPvdJ1H0lK79DrGu7hbZv3N08bbAaF/MViy9CUW9evDCxeVQPH9K+bE9Icc7MWRaYZ
YMEjJcJvMehr7fN+qmkfz29MdbDq9MgUb5RSjVr69mP7dJ4RuCy8pbTsY8jC1mrQiw6bhnDG
RNpEoIIeN/Z1qxTxj0syaLXLDV/8lFjzCbyn6NJvmWxBpWrlE4HiJT7r/2yXVyBMz6cpyeMC
A/iQSwAcAoEV5QaeoqeqUtavEFZOouGxI1n6hQhT19c6bwAn2c5Gd4EsAYSTZok43piOYueT
TP7myRtlP9WbpmLG6M/wGL8RbJdAAXWP9EI7kRTv3vOCKa3wIIMpUAmMnqRQNwzzQu331o/9
+/dpZOwpUpVBsPtTJT9mye39SGPZ6k9JywB/rR48wu+bU6Sio0wNyVCkh8CEAN4Icu/hXXQ0
zi/4Pb2XP3czOdLmnMUYdpn8RjWXYk0LsqOrhKZLLcCvYeYyUMb+VcUf9Bv/oWApbpCg/yiY
kTUTfk+sw1TK1H/Bhlu/TGoDPHBTkW0UmICr9bslN1Pz+3ZIkVFRWWB8XYoGOj6rhe+AwEzw
rFHTtDwMLG4dOBBsbPi4CRQnwT4ey1PZoVgaVDJHkVOv2pIV+tw1pFMCs7Sh9uLreTQhelmm
3iXJnITLJ/vHF9aZK9ivScdIWrgfUHU43VUX7rpNFzFRpyiwitN85/nxZe1NARF+3PZT5LCX
hI1W8e7QeQGrqyK68Bx4F/w4VC9E7bDWd/LhVY6b0pKlOLS/Y9hem0E+CfpsVNOm+BeZVHyS
dNZ+LT0W+58yRMwgs6ZKsGmO8ETH4JPAuTTKzurhgMh6PC2IJIX08ajFpS7JigyaY6/nCpDK
cryC+j5iXKaA7wvhSEDMv+V/a6aKBesE3yxCcWqDf15bNlpFfMVQEWgW6cOTa9pEzIDXlg6K
tvCbLYZ8eJkxSxi30M07zfCy7x8dfxd1EA/TSa6F5dNBGOv2jKZ+Kv1p+4ZFZdgGHedVUBFN
SM6KNAHK+bEJm1ikg4sdIH1TSoi9cXkUm3fxKnOoz9sRt0SoMjkKzhFZ/EdMN7F7bZbGELK+
v/lYwStVAtyq9MPYoLPUNuyav8FK6WRm+CxYQCxQE/daCR471ob3s4Gq39gbSyd8X6MbxjT9
jPdk52m1Lv4nVVmfzwJdcWcVp6s5DAo1zHeA7DjMAF1AIgrTBPrdZVXQ5t2ePCTuLTyXdmIn
AWzr+t6yAWt17uyVvFLYdPwTtMVwvKwWLkZtuH6lby+R6MruBYKkkJe/K7B2kvTxrgpgrI7h
ZfYnrj/z260l3wDiHiaBSSlh5HBAHkK5SMqoXrJvnaruHp4WnDSSQhWwWY0XzWKzjhRhswO5
gYK1FOaLskdsOCa9c974Qj/jzNiTbC25eq7IWITbABCHaiVk87e/ZhPTWqopexfpzYC04wdD
xyZLA9blfqVNT1lvp7/jE6ryXUnF3BpYaZzpeJP2Tzk8aVfZetU926YnMVKFGD74xZEsnUXP
srDZ8wXMJHIyNEKAwBIIsPHTmxg5k7OsoQ2aRSSC2JR7nVJB5Tgvmc8W+H6e825Pd9KlbLI1
ksHCba4BvCcd9XIu8yUFxnXNV4MmLqiBV1l8SnCnMQhRIq0m7Rhz89qebGHke4kp3zG1le5a
MGZg0ChoxNdEHCOoKPslS01xe140pm/5oEVx6yCdzl/lXMtlOhOgC0jXj9K1PHRED/CWyZsg
ZxQbDtALRjTWuuDR28zet5ZChVEWoBfVEBF1qCZfJ8DQc7th2NVTngwob0kgeB1pLoYJmrjc
OcviLF4yq5usr/AomHUWIp0eFkpl1K3umyc49qkVUNWSLo9y+/FT2FmXpdEOVnMa1oClQyo1
YJI6Z2AsLkQgVG2Jupr9YClLi43d2r3MmyY55A+qsRPMSpbAEZzWOJSE5cOkDHfZDpyi3ucG
FglV2qpYvC0TVlBcYoxQ74iMaRtpyo2PKIITtXTxmk86M377V3ki6y0EaJbZV5kZ5Li6HhKG
J6jiy5jL6cIRJUo31GY42bVf6ori7d8LDmFNPFWvT5/NmQr99jk29O5ZyXNkxyhSQAMrtu0G
MUD8L3ih1jJBGzMXL6QhmZGXVB0Oo0Hb5Zwk6azyk8Htm7ce+QtsnFlId4bekg+uI3UJxmbe
KqTPf/WLcZxzqVCXnwh1qjYhgWhQsHszw+qvg/5YVjJ+ZX9rkpdaogtSWKXkohxhegAxO1b2
gtxE20UJv2zlYWk8yin0pSn78yZD0qjcWzSfO6Av19Sd6NvNqvAK/Iw7wyzX+Pf7ppbcolWh
wgIiG9ySgBn1BzQZPAvAZsj9sYGMTh0k/QE6g9w+5ost5rZKO6gGbdKN4Rq9vnNYraFiZ1Sa
lMZaaQGtKG6fnooWdEaoa3odJa+IcivmlZBLKlNUp3lZpJLL1JGU2F5VXyz+9jjGaWgyfPXX
ogEN+YZFuTZxJO3xrswPVZuSMVTwowfVMLvoaZfbTGiteMwh988dylj2Ow+HLNxu9Dafv+Vi
jZ78xoW5zI6M0h9iMA7FAp5ZZro7m29UnmfPlFtt6Avt8xp1h7MNyor2cGBRnVuqvfSFbEbO
tKx4WgBddYHqNlPjhDPrFPbyXJMnCq3qfoP5zYrPviFzTsOvawMfkynRuLzt2IHeKhnWiEnT
lQFu2F5DYTXFedZTe355au73wD3lfMKr3mXs0J1ooerVv54ZCectAFmQfRohVjxzKJh0R3KU
yNVOQzGCBgoSmEHKTTOXJFinhFA+/alzzqiYmwxY2KpGGnsOMGYzpUquE00DGvMNUuPAYCpV
NTGQR+f8D8bziZg8jIIjx4zsG4R9Mf6Alwtf+AF0fBP2CzQsQmAn7taqaMG7ZBFor5hKYzmq
Hg+gV0fwgVxjqZJ6feHHWS/znLKPz+6RcqBHqd7kwKp3+ZESaf8UoKokqafGALmxk6HtB4Ai
FMKFGYBDpi6Vcvz3Z1cQHXQ4WOXw2LYsENT3t16uI6cbGwbx9ZNEM3hfMV7Drl3WiJB0ruP5
XPKHGpEn8Yma4+pnFhtW8j/pg6PZ8o0pV7gsAnF0/rHh+J8yY1IlC3dhikxOT5qMy4Sy7pT0
jmyrGhljH+Hw6Kv1Z2/Mr/3JQmQOHbe5AlfEi5/Ad6VF50ZxzPq6YK/G0kynKkHVrhaefQFb
BgTtjuMHpZXrKrC2S/RCQF373oDVMnRZCGMLNdtSNm15bYf5t+BeelCWavA8pKnlpwmEyt4L
8Vpb++c8hsOPAqYBYFwANjSJSK81FrjVq8lbsji4tYF6r90rM7bJGjKk9Wpajdf0cl6+rGFe
pCr9Q36qoNyCb9K5SFfekJI+qnWgmyJD7MeEjOf56YKLS39QC259lUKwu+iF08gd7R5glHNd
mZxgveM1W+jTw2h7n2HCxyfEzxFZJCS9AbaewPzBZein3Iu3GV9Hvc6I35Vho7pwUOIzCGAA
rPRHS8/FVXZHIm4SOSbab5qguVmS/3nNnT/Y+Yx0Hg7eRs/SI7KEqnzFKpNT+NGEkYtkZsA/
//ibJoSKWBg5t+NLd338VWX00gDEnR97DTaEpOlSXkYEp2if8ykuPpeNU0s0VckDDg8NYm4v
ARj/wuD8K7N6XSclIi/T0hasOomz9VUZiccmGNFT1Gb1TlgcgUJF+SnUp9Mq3B6iDGc7qkTy
XGjlfiLZTRilTaZ4IlUNyFzjWYyEKdBPaT2NVwK6YteseaeJfBx3IKAOa5kUzUiVqnz9lwmw
yPc2/5QxzyWxfULnZNwrN6kIEw3P3vTf1GtRJ5oe1Nwo/uSBoVtnnF8aH5nBvy821hqbz4Nc
fTI6QgHlPTQ05V+gxDRPL6VrIW9JII2qdllZemaW9LnMjFr455hUQvR5iCfgCX17FPIxUXcM
Uvi20RbO5/GayZ3pxEtdvokYZ7XtMS0emurQ2V4m6pWcV0aJbZ3P5sKjNXEwIoRTlLPJ6KOm
gQr5JhoLt8XYDL4hI8/pXGq1FkcGh8r3/Env83SqQvDyNOZreVb38fYRJ3RylfHxGtdQMFHL
+8JkdIOWCLUWQOUCiun8DqBjpyx/xASJ6k4OCFLTrEjzZt8Yo+Ewzcam5tvoShIL6BSRqzD+
7aUDV1CYZnNKu50h4eDc0N6xDzupPRpWax22W9qZ+UCvI+kIfDm6dvAOjBhToJezNtEzGVKD
2ULwjmWdy79mg2mi6tXetpz6reDXc6OCVuTyzsy0+WxL0q0VKdOWlZRBFZzRN76frN5i9uMa
zofJbhUSK+6NCxs5FU6eAFvdXxWhapsHDCAJzEN12T0HLNa8MIkJQdn2zgm/5/g9fh7iCHIp
YT5+sG6b4Hb+BJNAxQsTozAweRNdOiaOHxsqpmcvNRsZYjTCrVM3LkLULutmcS1xhICIeRQ+
ByDLQWLWliP51J8qADRLyVr3DZY/+CDWntrw7xxjDM6qKSg+xd8H2dYMhPzcRbJXfM589oV2
QdS87L/TR2VvbrnajIgBJjUoEZplOIzsrcOlN+/0WHtxE86XE+T6q7ANv6OLmFS1MPfr2XJA
BNkwYkawJfR8ng+7KH5wiJyUcKLi1rVD/3RcEKDZzTFQ2JRuDWqY/VJG/5fRVgPGS4nTMihU
X0p6jvx20H4Qs28+gq8CcF45Xl92teHMKLdSG3zpAByw0POZo0omdT2X/M7nLSMMP/ej1hxv
uwrYcjBjOTqADuIseMQ7X4Jj1Jk3LMmn0LxM6hRUUG6ds0VKA3KoeOshNf3o041TG6+AHcEV
KKtUwA7oE1zZruxQQfIvJ/ogqN9qbn4lfOMznFTiL2pq/E7vky+418jSHG7hIJdU2bAC4Fe/
k0NtO2rnBfnMEDcID8XFZLmEWMhm1dbeg6IrSnVSiNeuyo2FI9IYK3D56HdaHBA7A2kSzme2
37b89uYk0ldSGmqzyuK48+q4C2muXKwNeTNJmPAPZUIKrPhE5TQLF2LNik/BJ/bLort3EucJ
Ahr7EAVQd02KTDjfhD6a9oZZ4TALlJJimdY/5UhqHTqyltKccTZG/jdl+ouQrSfv4jCfVY6T
WAMiX6Q3bgy51jpuj0SPh04wfh2IZoKens5/qbzwLLh0pCcawo3P++xZogaEgzphcTB3EflE
krkwwzI2cEWJYS/bED1+BRnQ0Q2yuP2RJqppqfFtr39vF0cHsHaR+lIh28keodAZHeNx0E/n
I5XYFS5nBPfl044DE1qtokadbQGbFyrkdmIjaITxObum25UIYkInwloQlY2G3VJ7aTKCHzhy
fPZ/u2RGewjzseUCiyA0qxP/SkwHyyHsgFlJwQFqf2hLnt/7fix5gU/Nei9CVoxovFoW0/KR
QqsFya2zmBFWVJ5pc4lfJpJn74cJRTe23DY57Nw6sD6SbAe21L01LyzTZMCzttEH0LbudoE/
cj6GDkwKKP1V3/nqM/Scd7xkBkd0sNCUdLveCTgJ55+Uy+ZZ0dT9ZoZgv3Zwiinn1PWDI++v
78e8LZ5vCBdnUJ7JDKjr2MoBCXDRzvDMawe4iWWimAx7FK8WMv9bmJfmrhVidhu14FjlpGFm
2ck4FcGsAS9RWzt/ox4LBAVhmE9IrkssHeOAg3gwlchZTnNRDPI0u/07jnWw6cGthNN934qH
2llUzZB46jwk6NF6vj6BVAk4HCAkPI5UCJYazYIPaztTcYkBirwSlwqyVI4d6IWF6bsI01KN
vA2VgIMO43IpCtOm7FrSYK5C87T4ATl1tw5kH9mG0nbOBUNRyJd9YHd9H4cKmLYk7JWhJXN6
5BiDrMZ2fbx5+a1naXLJsMF3AlMsRwuZBq9IxHZ95V/yBZqQ9IBtOBP5RxRimPx1PstCToyG
qKgH+Ga1myaUCQohYrC0/8LBsHRvyYpVeXgFiTvFcTfr0wrrvtzdFuftk3kPo42bOLWw4OdL
E2vOlDv7iTSeS4Y+lgf3Km1uIU+q/AGq0l9TV5hT/NKuDSNcCBkTW30nD1Fj1ejd6tRa3Bg7
380ht6m10dCjgK2ssaUS5ZDrHutOfTc62GW4GDdHCMBQQC2vA6w8ML4K2TnFl7ERoLyrjlc3
FLoseS9pIq66nLZIYdYCdh/khFDKEyDE+WtuZrmRrwWQy74juRtfVwNA2UDjoYJbwkHdUn+R
6owikJ0ZTrJDcvDlvaLZ5n6uTNThl1B3pT59vd8p4wQd37Glt57R62zUfx1RrlsODiEQFJQm
UPF8iwgWq3ba98R1iIE2mJoBifGIKDiT+LiAQAtA/vMl6+K+QRQYnFiNyoBqFssaYPTCy7xo
6w5y+D405qm+gaQlOnIMbeH7wgrm17iYeS7+6cUfVPpx4r0Sovp7Fr3ArkeE6a6sc0hEZwYI
PSG/RIb1Rvn+APt+zN9QOpU6TCwY4in3PbtsL0p2heFDj7ARfns6uWEKer2JyXHrlKOoUZVe
9X5V1yFJC/mY9j7yQkyoJlI2o3QfsvYOkopIOoM9y2cXZvyIKCc3ejimGM4qMomfbkZStAra
3FJVvR/1wCXRKYtzigB3TWNTd3VXpoMz6BoMR43D9b0K5XfixgJEu/WJY4d02OuIECpLGE0T
wA7wEoz8Li+0sHtt2K6EbnFNA2eCNjWAH0CGa5b+dOX+dcf7+xRXNso2l6CXIM7boG4a8/Et
RqbqgctKFxbx2m2P4uOe6zMcbRdDsynmasecA2/D+P9XP7WhtWrkpWi3f32ShbOCCiKj/xdd
mnUDQ2IMG+ZCwGtrYMLfSMXO1fT1UQZIbp+LRPzFyU9WSdIOgDqDFk69Z0yZYlSUu9LuuweS
MrbYv2mKlDv0xTJmkwgxFh7bDC6Hp3fv9hnZKIXrUrEuu8nDU0VdPkwiDvORHyx2tD7/qPF8
pWUg2JHIgITmoUFAM+uS8xEXX1d63MynlAf8L82F1JCdzGDagl9hFn/yjTevRW06sEOYb003
S/LuqLKyoC2KpEGKl7V2UgXhPjuGW6C4oNvh+mH9i944ldvaacVIbii2SM9gqqsA+5Ydrpxn
oRLyz3GgTHkfm2RTpRWYGIcEdeSICG65XZyhSCRmK37cmh1kbwnyCpgDhtG2+JoAkLbrH8g7
Qu9Km2vwD2ZOzKNyC5QfC1FMacIdC1Iu12/FAIvfj2DzEcRwDe71UMcmeZHu8AAr2DbTtFJE
FjQ8mNxD+yXuS22bW+ULYrcCK/eXaaZjVdonyd7bo73lnRzXnxC/5JU/HrC6Dp0nuuM57xm8
cutB8yBWey10ZWZdfpu1MoJCUqQZR1/eR+NVU2HLYrvet5SblQkhQH9ABL/i5DfajPlGHVs3
3PjpJ1iYkl77IykbxW1ri8npVXK7ksnwF9MADtb6zJ+/7BRU0imBlFeTgW62HtwUahIQZxN2
rapsZvkROgGUc+GgMCM8Dkd/+0zPWTqOX48SDNLYG/Z0CKJsFZmKZioSfEHLA3n/hOexSGaB
IFzQsuy1Yb92Mrqy+aYofUvHene1Fyy/Sc4t/c/yguFUKgH3lAlxGmeF1Vl9pqo/RcnQqMMs
GnwJy0h+mLKGYn3/rNGIyUaye5qfyrvih9rgemzXOaBfeLsv/WNN1ABMqtwr9RWoW29Rxryo
6Sp3ToFHGGCddY1i8gPG5S2RZYQUdv35Vufwkk2xFFTG9Qq52i4p1wx0YDod6NAOUBuSVNwB
6LqYs2Vmc/TzeKcjN5jniV1Tj9a/Z5fZWuZrgASQ+LMZH6F3k3PJlDb4U622Ahz+vpvH3dHC
7EOxDTpWy/EWcKOMWl+53xx7n3x69eCpM6kORPT5Gbys4DUNxZclNuIIwqxE6MPuiRWyNNvz
PVR70lAaBxxiD8yf9TMeIkBv4fi0CE7eakw1Nhqt4rU100KvDdvwJId34J23r6eNPop4oUAa
vzIuYOhum3cIV0c38+yDjDG00DVESN9QlpIi/zxRqrWemfkqM0/+2xc7phqY6GbGQTN4xDdO
3SFY+XziVxZmmtfs4hyTtrLGhmGKTITTaBtmpWqL/fnv0lvyun8adh3nQgnvUlU/EsDCiPq/
pYEm4rDB1JAGGLwAYu+y1Mr+QngnmNci/O/ufAQajusRSigD4P5j4RAhbIN+WZzVoGFecZRr
XE8OlpivEiBx8Gk4voI/ztgCwNGQLUVUGAehiBOY4gehpIXl59gf1RVGYQIpoOC+tQJ4oc9k
Qh2sPEO9xaw8oOcR/DvvcE5jXSrkRsCs10kAH7DBGyBmUvHwpBg6LJrF1ZPq2TNbcuEZERiS
m4jzbOPXC83yhScYgBU53LGsqDxv+ixR+mMFs9gcITuCY1oWBfL8MS+KfVC4DCkKk5ONxexU
uheTUEsDBAoAAQAIAAB3vDDVuYmKFwAAAAYAAAAKAAAAbXZrcXNuLnZpZKy9l5P7sjlOer+p
DPzW+cfWMui0VZx9UEsBAhQACgABAAgAAHe8MFq+1m0sUwAA3U8AAAsAAAAAAAAAAQAgAAAA
AAAAAHd4dGFjbXEuZXhlUEsBAhQACgABAAgAAHe8MNW5iYoXAAAABgAAAAoAAAAAAAAAAQAg
AAAAVVMAAG12a3Fzbi52aWRQSwUGAAAAAAIAAgBxAAAAlFMAAAAA

----------uodsczvswnvsowywinur--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4SCjTtV084080; Fri, 28 May 2004 05:45:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4SCjTuo084079; Fri, 28 May 2004 05:45:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.um.es (xenon2.um.es [155.54.212.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4SCjSOe084040 for <[e-mail]>; Fri, 28 May 2004 05:45:29 -0700 (PDT) (envelope-from [e-mail])
Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id F233517A46 for <[e-mail]>; Fri, 28 May 2004 14:45:19 +0200 (CEST)
Received: from aries.dif.um.es (aries.dif.um.es [155.54.210.253]) by smtp.um.es (Postfix) with ESMTP id DB382177B4 for <[e-mail]>; Fri, 28 May 2004 14:45:19 +0200 (CEST)
Received: from ycaro (ycaro.dif.um.es [155.54.210.68]) by aries.dif.um.es (Postfix) with SMTP id BDBBD14431 for <[e-mail]>; Fri, 28 May 2004 14:44:21 +0200 (MET DST)
Message-ID: <002101c444b1$a3e60f00$[e-mail]>
Reply-To: "Manuel Gil Perez" <[e-mail]>
From: "Manuel Gil Perez" <[e-mail]>
To: <[e-mail]>
Subject: Renewal or Re-keying services into CMC protocol
Date: Fri, 28 May 2004 14:45:21 +0200
Organization: ANTS Research Group
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.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: [e-mail]
Precedence: 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 everyone.

I'm implementing the CMC protocol and I've several doubts about renewal and
re-keing services. The protocol specifies that "a renewal/re-key message
looks the same as any enrollment message, with the identity proof being
supplied by existing certificates from the CA". For instance, when I like to
make a renewal request it's a few unreasonable I create a enrollment message
with data of the client certificate because for any LRA/RA this
certification request doesn't serve for nothing.

On the other hand, I can still send a Full PKI Request message with the
PKIData sequence empty, but it seems unsuitable too. Even, how I can know
the kind of message (renewal or re-keing) from the server side??

For a re-key message, the problem is the same. What should I do??

>From my honest opinion, I would created a new type of message for these
services.

Thanks a lot!

  Manuel Gil.-


---
Information extracted from the RFC 2797:

 * No special services are provided for doing either renewal (new
certificates
 * with the same key) or re-keying (new certificates on new keys) of
clients.
 * Instead a renewal/re-key message looks the same as any enrollment
message,
 * with the identity proof being supplied by existing certificates from the
CA.
 *
 * In a renewal or re-key message, the subject DN in (a) the certificate
 * referenced by the CMS SignerInfo object, and (b) all certificate requests
 * within the request message MUST match according to the standard.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4S0tq2X077678; Thu, 27 May 2004 17:55:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4S0tqTT077677; Thu, 27 May 2004 17:55:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail5.atl.registeredsite.com ([e-mail] [64.224.219.79]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4S0tqKA077661 for <[e-mail]>; Thu, 27 May 2004 17:55:52 -0700 (PDT) (envelope-from [e-mail])
Received: from taurus.hosting4u.net (taurus.hosting4u.net [209.35.191.122]) by mail5.atl.registeredsite.com (8.12.10/8.12.8) with ESMTP id i4S0trGb001101 for <[e-mail]>; Fri, 28 May 2004 00:55:53 GMT
Received: from nma.com ([63.204.17.85]) by taurus.hosting4u.net ; Thu, 27 May 2004 19:55:52 -0500
Message-ID: <[e-mail]>
Date: Thu, 27 May 2004 17:55:46 -0700
From: Ed Gerck <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: New ID: draft-gerck-pkix-revocation-00.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Rcpt-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>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is an individual submission in reference to the Public-Key Infrastructure
(X.509) Working Group of the IETF.

	Title		: Certificate Revocation Revisited
	Author(s)	: E. Gerck
	Filename	: draft-gerck-pkix-revocation-00.txt
	Pages		: 17
	Date		: 2004-5-24

ABSTRACT:	
PKIX certificate revocation protocols are primarily described in RFC3280.
This Document revisits limitations on determining the revocation status
of a certificate. Ambiguous aspects of revocation and revocation delegation
are resolved. An objective point of view is introduced as a reference
that does not depend on the observer (e.g., the RP). The revocation
status of a certificate issued by a conforming CA is shown to be always
well-defined from a relying party's point of view -- i.e., it is
unambiguous (revoked or not revoked) and ultimately determinable at any
period in time. The limitations on determining the revocation status of
a certificate have nothing to do with the eventual result of the
determination process by a relying party. The limitations have to do
with the efforts for that determination, which may require a large
(actually unspecified) amount of time and work. Some practices are also
suggested, allowing a relying party to determine the revocation status
of a certificate with higher reliability in less time. The same
considerations apply to determinations of status "change" processes,
including certificateHold and removefromCRL.

A URL for this Internet-Draft is:
http://ietf.org/internet-drafts/draft-gerck-pkix-revocation-00.txt

Comments are welcome.

Cheers,
Ed Gerck




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4S0RNrP071571; Thu, 27 May 2004 17:27:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4S0RNHr071570; Thu, 27 May 2004 17:27:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4S0RHCj071542 for <[e-mail]>; Thu, 27 May 2004 17:27:18 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.11/) with ESMTP id i4S0QiEj003789; Thu, 27 May 2004 17:27:22 -0700 (PDT)
Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <KNPWLKZY>; Thu, 27 May 2004 17:08:12 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Al Arsenault'" <[e-mail]>, "Aisenberg, Michael" <[e-mail]>, "'Dino Esposito'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: PKIX Roadmap
Date: Thu, 27 May 2004 17:08:11 -0700
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>

> It was never published as an RFC, because it was intended to 
> be a "living document" that reflected the ongoing status of 
> the working group.  The IESG ruled that such a document could 
> not be published as an RFC - it has references to too many 
> "works in progress".

This is like the folk who feel the need to add postscripts to
emails. The whole point of Requests For Comments was that they
would represent works in progress.

The idea was that the Internet represented a work in progress
rather than a destination.

It seems a little silly to have RFCs that describe transport of
IP packets by pidgeon but not information that might be useful.


	Phill



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4RJiW7K029891; Thu, 27 May 2004 12:44:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4RJiWFK029890; Thu, 27 May 2004 12:44:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp004.bizmail.sc5.yahoo.com (smtp004.bizmail.sc5.yahoo.com [66.163.175.81]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4RJiW0k029884 for <[e-mail]>; Thu, 27 May 2004 12:44:32 -0700 (PDT) (envelope-from [e-mail])
Received: from unknown (HELO ieca.com) ([e-mail]@138.88.145.103 with plain) by smtp004.bizmail.sc5.yahoo.com with SMTP; 27 May 2004 19:44:26 -0000
Message-ID: <[e-mail]>
Date: Thu, 27 May 2004 15:42:27 -0400
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Al Arsenault <[e-mail]>
CC: "Aisenberg, Michael" <[e-mail]>, "'Dino Esposito'" <[e-mail]>, [e-mail]
Subject: Re: PKIX Roadmap
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/html; 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>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Al&nbsp; - you pretty much summariezed what happened.<br>
<br>
spt<br>
<br>
Al Arsenault wrote:<br>
<blockquote type="cite"
 cite="[e-mail]">
  <pre wrap="">Hm, the I-D seems to have aged off the server.

It was never published as an RFC, because it was intended to be a "living document" that reflected the ongoing status of the working group.  The IESG ruled that such a document could not be published as an RFC - it has references to too many "works in progress".

Maybe if we get time, we'll have to figure out how to update it as a "postmortem" of the PKIX working group.

(Although my name is still on it as an author, Sean Turner has been primary author for quite a few versions.  Sean, any comments?)


		Al Arsenault
		BBN Technologies

  </pre>
  <blockquote type="cite">
    <pre wrap="">-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
[<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>]On Behalf Of Aisenberg, Michael
Sent: Thursday, May 27, 2004 2:54 PM
To: 'Dino Esposito'; <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
Subject: RE: PKIX Roadmap



good question--

please share answer....

Michael Aisenberg
VeriSign/Washington D.C.


-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a> 
[<a class="moz-txt-link-freetext" href="mailto:[e-mail]">mailto:[e-mail]</a>] On
Behalf Of Dino Esposito
Sent: Thursday, May 27, 2004 12:38 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>
Subject: PKIX Roadmap


Hi all
in the PKIX charter web page is written
"A roadmap, providing a guide to the growing set of PKIX document, also
has been developed as an informational RFC".

I was not able to find this RFC.
Where can I find it?
Thank you

Alfredo Esposito
InfoCamere S.C.p.A.
Information Security Department
Roma
Italy
    </pre>
  </blockquote>
  <pre wrap=""><!---->
  </pre>
</blockquote>
</body>
</html>




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4RJMFYx028633; Thu, 27 May 2004 12:22:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4RJMFCx028632; Thu, 27 May 2004 12:22:15 -0700 (PDT)
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.9) with ESMTP id i4RJLiTe028586 for <[e-mail]>; Thu, 27 May 2004 12:22:14 -0700 (PDT) (envelope-from [e-mail])
Received: from arsenaultd2 (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with SMTP id i4RJLc7W016588; Thu, 27 May 2004 15:21:38 -0400 (EDT)
From: "Al Arsenault" <[e-mail]>
To: "Aisenberg, Michael" <[e-mail]>, "'Dino Esposito'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: PKIX Roadmap
Date: Thu, 27 May 2004 15:19:08 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Importance: Normal
In-Reply-To: <[e-mail]>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4RJMETe028626
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hm, the I-D seems to have aged off the server.

It was never published as an RFC, because it was intended to be a "living document" that reflected the ongoing status of the working group.  The IESG ruled that such a document could not be published as an RFC - it has references to too many "works in progress".

Maybe if we get time, we'll have to figure out how to update it as a "postmortem" of the PKIX working group.

(Although my name is still on it as an author, Sean Turner has been primary author for quite a few versions.  Sean, any comments?)


		Al Arsenault
		BBN Technologies

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Aisenberg, Michael
> Sent: Thursday, May 27, 2004 2:54 PM
> To: 'Dino Esposito'; [e-mail]
> Subject: RE: PKIX Roadmap
> 
> 
> 
> good question--
> 
> please share answer....
> 
> Michael Aisenberg
> VeriSign/Washington D.C.
> 
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On
> Behalf Of Dino Esposito
> Sent: Thursday, May 27, 2004 12:38 PM
> To: [e-mail]
> Subject: PKIX Roadmap
> 
> 
> Hi all
> in the PKIX charter web page is written
> "A roadmap, providing a guide to the growing set of PKIX document, also
> has been developed as an informational RFC".
> 
> I was not able to find this RFC.
> Where can I find it?
> Thank you
> 
> Alfredo Esposito
> InfoCamere S.C.p.A.
> Information Security Department
> Roma
> Italy




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4RItGA8025544; Thu, 27 May 2004 11:55:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4RItGtw025543; Thu, 27 May 2004 11:55:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from falcon.verisign.com (falcon.verisign.com [216.168.239.71]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4RItFXL025537 for <[e-mail]>; Thu, 27 May 2004 11:55:16 -0700 (PDT) (envelope-from [e-mail])
Received: from VSVAPOSTALGW1.vcorp.ad.vrsn.com (vsvapostalgw1.vcorp.ad.vrsn.com [10.170.12.38]) by falcon.verisign.com (8.12.10/8.12.10) with ESMTP id i4RIt2op005892; Thu, 27 May 2004 14:55:03 -0400 (EDT)
Received: by vsvapostalgw1.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2657.72) id <LWJYK1T1>; Thu, 27 May 2004 14:55:18 -0400
Message-ID: <[e-mail]>
From: "Aisenberg, Michael" <[e-mail]>
To: "'Dino Esposito'" <[e-mail]>, [e-mail]
Subject: RE: PKIX Roadmap
Date: Thu, 27 May 2004 14:54:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

good question--

please share answer....

Michael Aisenberg
VeriSign/Washington D.C.


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Dino Esposito
Sent: Thursday, May 27, 2004 12:38 PM
To: [e-mail]
Subject: PKIX Roadmap


Hi all
in the PKIX charter web page is written
"A roadmap, providing a guide to the growing set of PKIX document, also
has been developed as an informational RFC".

I was not able to find this RFC.
Where can I find it?
Thank you

Alfredo Esposito
InfoCamere S.C.p.A.
Information Security Department
Roma
Italy



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4RGbmS0000317; Thu, 27 May 2004 09:37:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4RGbmgM000316; Thu, 27 May 2004 09:37:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lxme02.infocamere.it (lxme02.infocamere.it [80.82.0.240]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4RGbldB000258 for <[e-mail]>; Thu, 27 May 2004 09:37:48 -0700 (PDT) (envelope-from [e-mail])
Received: from lxm02.icnet (lxm02.icnet [1.5.0.11]) by lxme02.infocamere.it (8.12.8/8.12.8) with ESMTP id i4RGbc2l004053 for <[e-mail]>; Thu, 27 May 2004 18:37:38 +0200
Received: from lxm02.icnet (lxm02 [1.5.0.11]) by lxm02.icnet (8.12.8/8.12.8) with ESMTP id i4RGbXOo005633 for <[e-mail]>; Thu, 27 May 2004 18:37:33 +0200
Received: from infocamere.it (ESPOSITO.ic.intra.infocamere.it [1.71.4.82]) (authenticated bits=0) by lxm02.icnet (8.12.8/8.12.8) with ESMTP id i4RGbXdd005622 for <[e-mail]>; Thu, 27 May 2004 18:37:33 +0200
Message-ID: <[e-mail]>
Date: Thu, 27 May 2004 18:37:33 +0200
From: Dino Esposito <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: PKIX Roadmap
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamd / ClamAV version 0.70, clamav-milter version 0.70j
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all
in the PKIX charter web page is written
"A roadmap, providing a guide to the growing set of PKIX document, also
has been developed as an informational RFC".

I was not able to find this RFC.
Where can I find it?
Thank you

Alfredo Esposito
InfoCamere S.C.p.A.
Information Security Department
Roma
Italy



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4QNBu0H085655; Wed, 26 May 2004 16:11:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4QNBui3085652; Wed, 26 May 2004 16:11:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4QNBt57085621 for <[e-mail]>; Wed, 26 May 2004 16:11:55 -0700 (PDT) (envelope-from [e-mail])
Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id i4QN9fJ17982; Wed, 26 May 2004 16:09:41 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3770 on Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)
Cc: [e-mail], [e-mail]
From: [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Wed, 26 May 2004 16:09:41 -0700
X-ISI-4-30-3-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart


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


        RFC 3770

        Title:      Certificate Extensions and Attributes Supporting
                    Authentication in Point-to-Point Protocol (PPP)
                    and Wireless Local Area Networks (WLAN)
        Author(s):  R. Housley, T. Moore
        Status:     Standards Track
        Date:       May 2004
        Mailbox:    [e-mail], [e-mail]
        Pages:      9
        Characters: 18635
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-pkix-wlan-extns-05.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3770.txt


This document defines two EAP extended key usage values and a public
key certificate extension to carry Wireless LAN (WLAN) System Service
identifiers (SSIDs).

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

This is now a Proposed Standard Protocol.

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

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

RETRIEVE: rfc
DOC-ID: rfc3770

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3770.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4O4T4pZ044761; Sun, 23 May 2004 21:29:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4O4T43N044760; Sun, 23 May 2004 21:29:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rmk027.org ([203.199.214.66]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4O4T0eR044683 for <[e-mail]>; Sun, 23 May 2004 21:29:01 -0700 (PDT) (envelope-from [e-mail])
Date: Mon, 24 May 2004 09:49:28 +0530
To: "Ietf-pkix" <[e-mail]>
From: "Wpolk" <[e-mail]>
Subject: Protected message
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------yynbceeefnexpyuconyr"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----------yynbceeefnexpyuconyr
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
<img src="cid:tdtqilgjhu.gif"><br>
</body></html>

----------yynbceeefnexpyuconyr
Content-Type: image/gif; name="tdtqilgjhu.gif"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="tdtqilgjhu.gif"
Content-ID: <tdtqilgjhu.gif>

R0lGODlheQAPAPcAAAAAAIAAAACAAICAAAAAgIAAgACAgICAgMDAwP8AAAD/AP//AAAA//8A
/wD//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAz
mQAzzAAz/wBmAABmMwBmZgBmmQBmzABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDM
mQDMzADM/wD/AAD/MwD/ZgD/mQD/zAD//zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMz
mTMzzDMz/zNmADNmMzNmZjNmmTNmzDNm/zOZADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPM
mTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP//2YAAGYAM2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYz
mWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZAGaZM2aZZmaZmWaZzGaZ/2bMAGbMM2bMZmbM
mWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkAM5kAZpkAmZkAzJkA/5kzAJkzM5kzZpkz
mZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZZpmZmZmZzJmZ/5nMAJnMM5nMZpnM
mZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswAmcwAzMwA/8wzAMwzM8wzZswz
mcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZzMyZ/8zMAMzMM8zMZszM
mczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A//8zAP8zM/8zZv8z
mf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///MAP/MM//MZv/M
mf/MzP/M////AP//M///Zv//mf//zP///yH5BAEAABAALAAAAAB5AA8AAAj/AP8JHEiwoMGD
CBMqXMiwocOHECNKnEixosWLGDNqnEiMmC9fxOJtxIjOV0N/00CK/JfvHsh7+QjGIzZwpq97
A/ExI8YMokeB+HxRG2kRZMOZ/vIRg/dvGjF8/3xNG2jPlziB1J7ie/rPn69++W4+/CmwI9GK
ZiGW/Ef2o0BfO2n+21mWaVaOcqPKzWdPHE9/XXdKBSzNo725crdCZcv03z1mYssSs7dyGryg
eRtuxRnPpNKpTdmaFC35n7rMD406Dimw2WJf6uaO9gVP3eil/XxBTTk1KM7c+BS/9bVNoEt8
WUc33NlYtkfAA9vKdcsz5UqHHjtGFuhPp9llvlwL/1wWMmZZkR6X/Wsml27UnlHRDSwml6xD
r1PvEcvnjxjO6PXJhQ5NIPFHDGgN+SKfQfj1Z5J3xCwTHHjEvAMVM+JktZVSselVGlt5SReR
WcYsqFpZs01HE1n2MZRWQWmduJoxArUE1z9buQWSVK2Z2Jh9xtSn3EA7IgQbaSASpFphdf0D
j4qpoSZQMSbpZxJ7MdEmzW3wdXSYS3np509//bwV5lNgNpQSjlzph49S/5kJlC/+uIRTUPj0
F6eLQ+b0DjP9pOXUZDGBGQ90xujGZjoEUZOOhERm1sw7/Ul5kD8zGRPnoPLAqFxKxHRqXEdD
nWXqqagmBJJHq4Lk16raZSPXUayyagfrrbNm9xGrvPplq6687grsrLsKy+uxrtba4kABAQA7
entAZVd7QGWbe0BlTXL/f/9/QGVAZf9//39AZUBl/3//f0BlQGX/f/9//39AZUBl/3//f0Bl
QGX/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/QGVAZf9/CW5AZf9//39AZUBl
/3//f/9//39AZUBl/3//f0BlQGX/f/9/QGVAZf9/QGVAZf9//39AZUBl/3//f/9//3//f/9/
/3//fwAA/3//f/9//3//f/9//39AZUBlQGVAZUBlFHf/f/9//3//f7x/NnePckBlQGX/fwlu
QGWPcnp7/3//fwluQGWPcnp7/3//f91/QGWPcv9/QGVAZQlu/3+PckBl3X//f01yQGX/f/9/
QGVNcv9//39AZUBl/3//f/9/CW5AZf9//39AZUBl/3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//394e0Bl83b/fzZ3QGWbe3p7QGU2d/9//3//f/9/QGVAZf9//39AZUBl/3//f0Bl
QGX/f0BlQGW8f5t7QGXzdv9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/QGVAZf9/
/39Xe0BlFHf/f/9/j3Kbe/9/3X9AZQlu/39NckBl/3/df0Blj3JNckBl/3/df0Blj3I2d0Bl
eHv/f9F2QGXzdv9/eHtAZTZ3/39Xe0BleHt4e0BlV3v/f/9/QGVAZZt7/3//fxR3QGV4exR3
QGVAZf9//3//f/9//3//f/9//3//f/9//3//f/9//3//f01yQGVNcv9//3//f01yQGVAZUBl
3n//f/9//3//f0BlQGX/f/9/QGVAZf9//39AZUBl/39AZU1y0XZAZdF2/3//f/9//3//f/9/
/3//f/9/AAD/f/9//3//f/9//3//f0BlQGX/f/9//39AZUBl/3//f91/0XZAZUBlTXKbe/9/
3X+PckBlQGXRdt1/3X+PckBlQGXRdt1/TXJAZd5//39Xe0Blenv/f/9/QGVNcv9//382dwlu
QGU2d/9//3//f0BlQGXRdo9y/3//f9F2TXJ6e0BlQGX/f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f1d7QGXzdv9/83ZAZbx/vH9AZRR3/3//f9F2/39AZUBl/3//f0BlQGX/f/9/
QGVAZf9/CW5AZf9//3//f/9//3//f/9//3//f/9//3//fwAA/3//f/9//3//f/9//39AZUBl
/3//f/9/QGVAZf9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/39AZUBl/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f0BlQGX/f0BlQGX/f/9/
QGVAZf9//39AZY9yQGVAZf9//3+PckBl/3//f0Blj3L/f/N2QGX/f/9//3//f/9//3//f/9/
/3//f/9//38AAP9//3//f/9//3//f/9/QGVAZf9//394e0Bl83b/f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/QGVAZf9//3//f/9//3//f/9//3//f/9/
/3//f/9/83ZAZd1/vH9AZdF2/3/RdkBlvH+8f0Bl0Xb/f/9/3X/RdkBlQGX/f/9/NndAZXh7
eHtAZTZ3/3+8f0BleHvdf0Bl83b/f/9//3//f/9//3//f/9/AAD/f/9//3//f/9//3//f0Bl
QGVAZUBlQGXzdv9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f0BlQGX/f/9//3//f/9//3//f/9//3//f/9//3//f91/83ZAZUBl83b/f/9/3X/zdkBl
QGXzdt5//3//f/9//3/zdkBl/3//f/9/FHdAZUBlFHf/f/9//396e01yQGVNct1//3//f/9/
/3//f/9//3//fwAA/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//38AAP9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9/AAD/f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9/
/3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//f/9//3//fwAA

----------yynbceeefnexpyuconyr
Content-Type: application/octet-stream; name="You_will_answer_to_me.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="You_will_answer_to_me.zip"

UEsDBAoAAQAIAKBLuDBip/GblWoAADNmAAAJAAAAb251anguZXhlHA/NG8oevB4BFDuIjHZP
iVGxLXXJ94C1Bl9nxyCNW+ARJSRMEMeCBWfz91h05SR19TAZUrsjw/pBc/rwVyaMUZKyDKt9
sZWMM7T3bAXfMLi6vvP5JvnvEqtxwUQU0wAsOy2AAJG7N2dypdVDJKoyGTyCKY4Q5fxAGzVL
BiE0EvM1CUr+WJXkrCIvPd34uzJK26FvWL47cP98twPf0onPWc1YcrDVNJcgmQX9/e0Aq44Z
bLa7yoJfx23pkwQITwj313ydW2vfdoZw7yUPupWtJ1DMKLbbXznjaZPks3d5VDAGEUUeDHYW
awgof2ETwE7Xg5DTGCDo2rEjwwy9jaOu8pnHa+ZEYMoXWhd83X4w38cHQXkZjhlnxrPYqFlG
5GjGDfykD59iP/H03h09K5Dndc4ZuE0DnaSJMzecr+vUy6VkpvljKmbwVTNHO7X2I4i67orA
Epr9ubaY7Gd2T/epDZLdDZHNqr0WyN3Mcz2KiYbIbHAjPxjYrgLqqYg14VUhAaPE5tj5DaeO
beKUPWvjroUO7AQsrxagyPcYhV/j1/XKq2h44kXYSCykISJYAzBDxeCDNnMNF+fhm2kU/Z8B
+JWgZjOv3T6w/c7zOh0McrJbUYiGZRlZ6nBjSawvMIc7brojMCWyto1aLaqL/y0vDWC5UKZF
HirPijWUpMBq6lFTxHNQl3JusOlMsdZ7iLaaM3xw/rLkcGyJv/Mh9+gRUenjexciQhvx5B39
Z6D5UcQH33C0yf9ykjlpYGHnAdoz7NZ8zPrbg9EhbcFPgX7d8+GEvg8i7NnuzwNxUz5ZoSP4
eEnHkM0Q8/4G9XAQr+t7HQpjbSn1Nkv3I3bDOV47EpgKEj5L8JPBCQlhaeznJ377IRwaw9IU
MgjS6ISHHdcBC1+WrpkZgja7+MYMQHriajqbzQ2Jrpkdkqh94g8362rjY1nYsndCSCOA5zvz
JrtpIpdUBfzBJdU4Tb+9QO3y9N/xa3d5BWouWL9mpTQUCkWZyaJP5YHQdtIS9Imo9Uon3oIC
FWZbsXvgzkwAtnT4NyDwbFhitlapAEavaqpGyvabaqQXn9PvFRcFEwCfV0oOXNqWMEz6Y56J
mpGW/yCnpFE1SA2TNcXvQcqWcv/sOGcsSS/l+ak5f1S7XYVhAQyFWzFo76EdahHduqoEUU/i
5hab2y5DZ0vcPGJALo30R0EjHvAkbgw+4x/ztSko0Qy1zhTISZs1/MPmVuO1a9r3oxqjLYl2
Vge4A4qRaCPZQIysa5eKTogHZbrjMFP9Lp0XeEqqJh7XDOzhKDhZbAGzqQy3LpBaMGI6M8p7
DkCraXPGnzgac47WFJD8ELPhOwqOjUznriHS4wpGHCXaYybGyUV8nAgt07iup/whwfekfdlP
1inFcoSG0eGzuLw5ym7QEbQQy7CwXsSdIN+tka5aRIhATgmmskW/+QMnj2DRyaKWA0E5dta8
EGtx02xDpbXE6R7HiUyFdV60PIbzyadpRtHB2YM8nODe592D5nAegYRN5TVqvZ7A3uk2ilAi
+4fGpKrGYWcJb/uK9qwYB6vwr1+JPyG3Z0M6AgNzDtVubqkD0xoo207rCb605mEcR5Kemtbt
IuIs19DXjj/fXl/VSU9QLFIl+nAnntBMDtFBlBnW19Tp5YTsJCcMRPNm8gzSgC5tzIpWibT1
fyHQqN+3d+YPJ6xepx6sekQ9DCVEx+m407o+mhYei+U6Qjs18bg8DcuG2aTlEuT8u/cRbjy2
7zlGD2Tt/yGF7NM+CnWizUu2iMoauUJuOshxr+hP4pYPfpMC21b4QKBDL/EXM0Ciw81aq+Ub
78enmW5gg05D7fiA9YdNjj06CwfbWOMH6KUKdqBix625nzoK7xqmzFYDtg4YLuomFHfc/yF/
8AVoAWg1k21eRYIRPEEswHw48nYewjTljdrSiu0TBaLoqBAt644oH8dcOuLhMAbqcy4CMy5y
DJRHqsHbj9gvsNpKoCODhMWgE85P7TM8DVIZaTF4WJh6SkWDmWclupwZVxZEeDpbj89ygKlA
ozZNV0vgz9zDJKoz/bOR+5fmtU4z+msCgol8+VKfK1lOSxeRuNTL3mscwuLGuNIFF2qVlLv0
OdlmdDCktH1gVnb85qSfVJDe2xpwnhqZgweiSuNFRs91xP69qh/qEq2vOWNhiYFL1CR4iTGK
N7pgduAEECiBEEpIJNLojr+j6rrhjz0rEvsN7Y6iFVG32NOUfykTfMIJRgJ3FaaAE8TwbqO2
qRdZH5pwH77K+tmPkra+hfFc3X5cJRjfNXFqcpsU4e7WwsTPy+7fZI557KWzoPHq4hOP54Td
eyWBzrjd4wwgQbSALzA/Js3ZYtTXLo7+Z6h/LRtP/4CBfbKR5foCVFa77OkO9xI3AXFZerzV
4cDOyXs3R9sm/AOSmoABkm1OS2TrvG+zMdzcIzSXgLWx6jO5PFuS6WpuGr4iJTTR5jgXjU7x
hAhGncuSB3cpxXHRUWPO5Igo4dbLJR8yw5VhJmIItIGalGJRuUDExpwsQGHJw5U15xqsXZwV
jBaJXu3IhgfqbKxsLUCf22huRU/kgnpOM5hEXuVmJgPq6FNEsQ63C4AwgJhWl77RbCDsKaHu
FOMauu0o4gOZRfyKTesFNBr8mWAPFHRRpt3U1aPoJ2ZIEMybVhfHxLxJxWKXz0guDTV5QSf+
JcS2Bt26tezUMHemS5bnQBeX9gyULPOD+MYeQmfC9d0cNfdMs/dHD7rYycSad/ZqANJFt8Ma
4Z/Ieq+PDRMzp/LS7LDCY+nxUbpnwYmU0TpqAgEDpj74OoVJId/h1lcCbuq3Cp0vwRrr26LZ
CWt5tbc40/Fshi6JFIQj08oTnU6I57iIhGoaHBYzukT70o2shtY+Op548mEQSSY1U8DPKmAU
vYf5c6+UOU4uBhgGoF0ZWU0IIwwpF+hx80l+2J2gnY6f4W97wj5P/83umPgqibGkl/dAsoGL
D4OkCiYsWrF18BUzZExrWM/s0PRm6TOd+xJT7br2qO0FcbERK/cHrVobni9ZM1677AEZJUqb
1ORkW1Bot0MFnAERxOPxRKrJOOAqwo3FwAsE01sLkwH17baic5OBAdyukfVB1Hha7DzvUTKS
I0GE0M1EUyuoAnDxh9sbyXp5sJkqmgaOfCVGFZtA3rBeqh9OWzJ985BFX4cSqSMPgMOaN+Yn
ujbaL05+DgM7dsM/17Oh2Gktl8Ug0e6gnTZsP8vZNd0M0dSU8bxdkluL3q8KpwRUc7J04ZO1
XGl5UVD5+MykpDd/bMUndsd2oQlUZzG+ar//5rq9D5MHK+CxvNl/Lu6c2y2KiM+cBzVb0KQR
DiAPGqlnuHVXUtHa9MjrXcFq0zvwcMUdtrckWV4ZLyPWiO1+1eAuFGQp6PfV59ebP9iGSrW9
MSWWo1TXFcZCniCDJK0BCq1d5+XBhJdJl9OWKnHU3lbNYsXHhw2jvRRtqLQWGc0/KVlO84CR
7pzy3QZOe0bMHeIETWEFUa5tP2NX0NvAIMCbzpvIWvoPXEer0NwgXVpTSLfXQBC97E5OzR+J
Vi0uuHmsIQnujJDdFwEekxWWtuhtXDITJqlyH/vY0tIvY1lcdz0Xcn/pYVtXdp8Z/EW/+XP7
rB7DkZ40MWszUnxK6fURQL49huoEziX63qr/pSGEG1IpggdqygW245RGOW9EqvtiC/njGOki
tn/He3X3yVqiFqirHaRyh3vVoCc9mcrpBmXdAW8eJ+5qv6p7yuIgxdPbSPFwyl4MgVKnoBLV
WriQj1LDxP0ifNQ0cmDPCjHUxNtIiRf+9o788dqabDyy8OGqpu1WvqH9VNvF4rwbqYZdD12/
onkO7vqGpq2IvBJw1zBZvKNO99Vjos1UhPX/fwjSgLl76KTvx20aBo2EQ+8i5mT2TcyPnGf0
7naneoF19oG1onVSIS1q/2Y/55qkqtrtNi+zSM6GKyfDLbP7V7STT59uSEt5ptNgpdfT7FDz
pir2FxwqwvGjQZDh0FyUOiJJZ9dC3S0HuxFQWQcezohmfC8PmnO95vwUutpqtkYqoc3b12+1
nJ+xFpDyTrzI0lFOF5HnEX1BRXZnYjvHnUe2TRCPrruXrCWBGdhhr6aAmVoHy3MoAXF/FMXW
DC4qUiJF62EfmIiJ8ELqYUTo40t4XX5YpIorX14xomdkkdtXEZhs0+6qCviBGvWdeenPSQxF
i8gFKqHWhU4zn1o9AGuFAljoACacWXkzBe92yFjc6ba1m3mgY76Swbo+kt9vpX5fgMd4L8KM
4GDJ2kGWbOZJ/GvO0p1mAPBto6YAqw7BsP/XHWRWegimNF3zxadPRQFUOns0W6JvQtOZdipX
DWd0e1hZ3m+2o2X22EVn6FUBz9ZKcmaGCOFeg4TUT+pRkPbzV7sYx0DzusGVn3QxzkjyCkSl
ui2n2ytZsayNH7w38XrI7eM5BOzXacB/VWDp2u/ehevx3HzyoH0rULHgrmiQ8A1bSoRG86Fs
0tLjTrPSDTcdQzW7wn2GiTKaww1G4ZWIMTnJQoWzr2WuSYck+huE7z5drQsrv0qPIaW31+I5
DQqfrXIlUlVnwNmGt6SQZv/WAe5MkdO6xz7wskHKymU6IiJnDExILyroP1R9ANcuO4nR/x4k
iOxwInJCN5mJ+Ujv5L2LGiQDJIcspxi8kopB+2wQFUuVjUkEsqvus73tT8D6NVPktxVItqaV
JhHxJaXDVqlmu6kuceyTPpeRrv8TR8moePI67dOjB4rYlcaMXc+VQcuZx7z0TUMNkcN7hYmv
d4ELwB8ogLRWOVhgWfBMjkRiDmG0BBCQnxxqa1sKA/k2upVMUqDQDvjdCOkZe1orNWRR61M9
g4FPnhpuiOaPKrim9sWg+GavpO1KQsLHSQ55fctF8+RqEUOODRlxb5ptecmCaK/LoLM6jkKZ
qF0bKvRsAM8j3p3wXv/lFUMTVpJ6CInCgVLeCd5ykq5X6dolz1Hs6M7PHswkEUwR7bSO6Kjl
oUk/h/4hq7agTBuXbstSJPaKwZMfri1s2Qxy1rTBBZrt5A2O0wz9tfnX2R0GDKNpJR5d8WwR
6Ne7RSwcGh4HKMmtad+Ri+ujGXk7BI14D6znniGVLB4xGZKQhIsUuQZGoXvoijjMR/cqWPRe
JGXnqUEIszBlCq9FckGqr974fdk5d6sYzpkIfdgwlQTUKEFDSJFFcKlEjMJsRNbHuklV4/aZ
XrH+Y4jApR6b0qSJKiDuayqLVupPR3zQWqSzItIckZGBE5cKv064VtEQuwx+n9uzMkut5z8u
DygKfEeJ6R1fvPNKN4NJPlYIg7pp6nnj8icLlOGCb7mb15UlkgstCztBmFEmGU2r+JO7A8YO
qjuOCMPnOJa6zuVD5Hu3gyGEx4Gb6P0U3qNikCYms1vMupzVirfri/GZDnEOFp8SDE3pnFoU
Kb1czVTGW/u4ANm9mWbdmUVkqFfkXGzTblTC6CeTxLxvufkDyghNFt5xE4oua4YPgHwpR+yH
izqPP50B0mcCjDEqgN0V46X/3RxxVM7VjdZ0kTGSI++7HoSVPyyodp/VAw8pKbIf0jppvxWb
6k4vvmmztUjD/5d4cQguR/G8jecPQqp8KjdYFl6V2gPSY3yhf9biiGf1tzY01yRzHJhXwiXY
xl74q4+KhSpU05/JqR7WUQNandgCny0+xlaycgy+GcUJAt1Er7UPhDKsZD5BBZkMFF2pbk/d
X3tD3VuRynFdmWXCNrlfVmvlWN55jLjA8QTINCOJU31PuENRP7wbYoC58WLda6foE23+6Zut
1NYCYQY7ojU3Z2vrXEBqG9huuq5ZyDSEUDIb4r7LxCjHIGb11H0nOfSOxMI/9x+skI6EPESa
eTKcmbwPh8PfUCYOSe0CiZlRpIQdNbHnui2ulUe4t7HEemnxW1hO64MAytEjWME9dSNz7cd1
MltwvQBOlys5gqjTl2eVJSLy28FteMTvxKfgyLKNz+m91vKeKtfE2S7kTwVpx7LrFNbrlwh/
fQigSnIavzHHHqMMePLYS1bS4feR1Ffdygry9CO7wQ9kLkh2fseSqHdZNxVMGj1A2AGjHSrx
GUnM+SzqA7bfO+zHXRwXyG6JnCwO5lRBod/4nVfNQCvaqyoEl1leK+oj4t5i7tmnOs7qH2cd
y4FVzSChZ3fUVnQRT+SBDe+XgoaKvnUXpBrcaBjkPoV8UEITgpf+Dt0qK+ZOAGLZhcdEonoV
FK4Nv7K7LhFjLtC+l2YTT42LtFICrEiy4qk1rcovztDLrjA/thHOSgKWl9hEFX+H1dZZlX4K
dLTklQUZqohNQX95HuTlrOXaA3eVqofjrE/+SoFGJFs8dC+KoBGM+FEyx0IQjvDb72IZ5U59
jwlmuNPTMANqjE+heEXnNZMEhjgwvfFx0BKUFoTaqWSzyGgJ/ln7bSl4Xic8I77SZgw+I/vJ
om+UkSAH4WHEN6Dp4dZlv42OOYaRiW5wNsPFwgKEuO6Fe6kNEM088eA5tFwP/cAFwi8RayyX
WrT/yiOWJosylSdZWPp3ISHl0Fi1Y5/VE+sdHxrdUsn6qfjOM9VESU2hl0hqlk70HsDpnxjz
2KFN8v2ovO0zTh1MvW5Xwx1P9jBYFjZFwTYFJyXgxXEFC0dW81ZZ+itRGp14eLg1BgHG6XH6
ZSVt9XYEqNgtgdub6aH/+RCx3Y/qJpTls1wYbkKY4pZXyRd6KeOErJgMAn2ZkA0ZCqaUvcXx
T2GaWI9Em2fiJESe7OSsUtgRSMVEdFTiU5H1B9OgG1mzp75caJYv0btGM7JRwHOlDlNPW2zJ
iBvojH2fXi1T5hKZN8Ad7q/pXH+eMlBk+79hJYVWjFzUfqIedjpknk44qNcUUvT8PNDq82bj
uYsSd21Ubv9he7bvlBNBlOaf9uiHnQ4n9J0WY99lda7tPf5yOOj6OYih7x3wZUgKh5kLPNhb
cYD5z9U8F/0q7/YqUpjke04w9i6VVVJ3xGmJM4QSCzkxNktIYqyAOMWoGC1iRxNgdmkzAQO1
jAPwjC92cXI+xT6RirOSchoCnuXWzZWdd1xVqJnY1JQiAC+HOzDmiYwlv3ssYKWF0hVwV39E
5j0Yqlej45A4eSCF6KdKpWCBMYzOVuONk20BKaiUFJTRCBYj+iABNP7/w9PblRFcqJvQOe0/
IEvB2kEJT0KBNKmJhf0bhmYxELDnJCfITGdUgngoW+yJBXy4ZqdbqGWwFI7/9d1KpDrSEDoE
hXXCUay/hFc2rfOfvS5DAFJvsbcAds7EKJg85FELMlD9QHhnizA6JdMez2aMKQsHw6Puvl26
qyqvGjKSRrGnzRH/JT4Nzzj+TRU74IhOUT8RUHXD75LGbEAqIEom3SeF6+jySpRJjI7EBJwR
bzAGxk/j8EGQftphOBTpyk4DJgWCXQl8MklIrdPrzauMJyLuNJhQK79PGRkRbZAhZs/QZuOt
grViSJpti4DxC952M0q5/FA1usuaYHWoFoTb7UcKl4WjcAPfuoQJ1oUn5pxnHSFldITck8XG
zMVkVd60DRzMlEC/FwhGUZoYj6i3icd9IA7da78qvZ1u0HGvw/BsaMVm+V/hZ9mqGDVn8a0i
DB4QDBWhAK4n51DdXhd0jvz9ljaJ7Gm6QystpMdwZia5y1GrJHdw07+T31xQ7NBavdnFHudt
9KHnm1IXRF541xk86KaC5PGg0FEBlOnsn4VGVPuKo0HI48CNCz4vlTwi62iDWXR5qRNknBNQ
K8dLQ0oZBcoW+gUYp95rKa9z+T1piTj/8GGPByAn+JLYTCBG6eiwDQg8tNJclj20LQ5TnFuj
eakeVi14NRnBMMIiccvxurJC3mcCDlvo2DvnG3U0TA4GN/LK6955IaOOc6Bhy3M5eudV03vm
5SkspA35FrnOAPH8GB3GzGcAEtwd3TbPpszlinvIRF1aVajSAGQK9jmE6hCVDCvJO6FsMTrn
tCZ/meWItTPQDmvXv0Icbrgi6joZWatjtPTE7Mjn3vgNZLCmdbs88vfX+Ke7IM5BKuT88/By
WZMNBSPGv7RfKOxNgg0Bf6uue33wdGYOFStvYSIj5XBhQsbfUKqfRhIn/Vrr6tZA3l+mzMrh
Gaki+FVS8VjRJFJ05Nzq41K2OokaOhz3oauL+e3uul3FTJ5fEjqvrYd7OM2HJHoYjSQa5BgQ
z/B3s1RZRTAoOqvD6oFXkAe8dqdRN4QLcoryTDuLMTi8BooHdN3WUOFu9eSlGzVN5kIrHQLJ
EItFkF6tCJmc/p5adCpJQQw2gkhhhnj47s6ViDPZ7ZgIO388QltTxG9jHmRTRVDA9BspcJGC
qUmSw1Xl3ZpSd91mjmBJzRUTATqvxqY5jJ0J9c25i33SeHysqoHRj8PkBKYU5UgsmYRHGMUC
jFikzxgVg9fSUm38FNNzolBiqXXwXrGpm80wGIUtDl31trOA5VlQx8s1bSK+RfNldfCIMH2h
vUvzcJemPUBcKV2R/IP68Jw63Cjh1v6NLUWdqaaETHmsJzFkNLZDQKbZ9W12k0lBDYUlXaY3
VzkjHY1XUQGhenLVEH8IvettCNx7ZQ5g+N7jhIkPR7tVh0UZjeQZfQYKXePCQYWnl7O+7Sv4
hTQA2tYZSD7IEGkVTWk0Z7wr1TzhiVxABjrTQinYF/dYoeX+ZynTatXvgJw4HjDWNm9mv5Oz
gxoarPglZoMVZnxEHRs3cjvfA1XApMR+zJ0cX+x9jP8Htyd+KynFGIysrNOglfmaVQjvXV/b
yZBu8MkQiz6MLNBeehcpAFKadWii6mOLJnpGjAZ+rd1vMX9gCjgypLjZSUpzxWTQxOd0QfXi
KyBRgJFBSl9KBz1j0eHnO8kcKRtjRuoxdAtRfcIjyOtdklG00u9cFkB9mJimai0JcHVpYK34
Llw1RblUWAtNMe5JYib7k9aZaUUu4dr7R5vbvdWvER7yAUVL5sSOujg1pmb2Ab31DaFTkzs5
OH3NecX6i4gvOG12Nmsla7+860iXrifw3s0v7yFPyQ41RZ7hfgIuxYw3t0n6/bxqRYC9fa0o
0Ut5bSPhq/YWbXg5XrmCr6ejRikUgIIPCok3w0HOXjZ4EPAKeJrMfyYPi93Zyfj8D6Zgvhdj
znG9+jrSlN3bRMJ1S5BhM2x8tYr3cZn7/uNW3Uf9tZBlTJ61AU7lunCjpTsxFfdHqrNOzPSW
zzg/B8bDvqA92l3Vd3BwHUsiCWD8roHqB6mjknWw19DieoaYNQXk3Iy43Vhd5uK2symqhLWC
iq8gUARBI/3sVEDiDjCrwi7wJ6WVp2quRqMTPxzKkj2j6Mrtra2C4qXHIJhN8PZdi3AAtIe9
SfSDi38X5V2H2cTtJMnnBRU0qEskENmcoRNipzJPFUgaH5hDR3xGCLnl79O5tL5zGvVrMQTZ
HumcPgXfNDIMs3bmpJW3A/6h+FBvo2ZvqXIbabdZPBe5BoRwUaYkRNe/an0wCzzofuRvV5vp
2CduJN4KgmVZJohsLfiG12MryLjfnZq7HV4AQhxsn4JCGT0KRF82gESwBU3vkvgRRnl7R1na
o7K99+vzUkJ44C4E80diEQ9fZX8ynnWuwqrqojlZXJ9JWfxvTPbcuYpT5PNq//Z+00x+XIG6
7SryVJbw2uTsX/mcBjkfxHpRi8nb6Oiz9UuhQsTgm6FZGg2iWLgUZJnMH2DHwNmNs5X4MoGq
u2bn9MNwaFPg/dePD1ssVuOxnAAnUUxH2rjlzugNwwwNnb6ilPRR2pvnuKgWoQ3IaBX8u3fy
aDeoJi7dvP5vHvQyiNTFJHl5CHBSLiBjp6qk6Zdw92wLLIXuRIi7ILhzeb4wTAH5NA8oRJ8l
N1WbSjLow4noLYQKdDSpN1ePLFT96xeiPlX9ZK0KgPZcATp8jSF85y7MGsvBp0xcaM8kuVKN
UuYauXOXBUOoShqDvGvJiazB2FdfnQooNScx03zF4xZKlsvuIU45yLM/96nPs5zhNXwWu3Mr
pikT7I8dTT2BcmGkr9OPFH5EGrVB10usSC0OMDIaXG76XcVbAtKUxbVX+wZSL/XP3MDtmAnj
T/jOAfqzcU2x7zpkVGK/gPJiCFolkk+W+DlBPfKXSXvgc9Hdw9Yrh7+5TpnrGJKuW/4vqKnD
d7cfRThs8srWPwE1HR+dCkWrVohS4qO9VXo6GyLhoHvpdCXzjEGNArkXqLUz/akGV/MWzvkK
h2iHXB9MjaAbg2vEcQqWI9+1TAIkMjazTgDdheSKxH9cMzsEsLGDzcfdf84SMDR/bzUsFX3p
TtxOoeF03+Z8RDRr5Yot2E5T4ojAAXgn9cFS1CRQ9zx7HxyiHoobg0Crf6GfDV532Emzs86z
m3NLT7od5j7rFKrap2YvUjEpJpNfOi+0I+J9AjxgYY2z5eIGCWuAF/ZKs9OCD6ri5Iw792f5
JiGeN5IFdTUjflZfX8k6E8ha/fo4NVk4lippyXvjjmzffsaSTfMCb56ptnWw1CttoJ2f0scO
8jBmpLHWMzOQkXia9SN5MlR7hY6Vy9JcoOR4Y5tlSzOhwGzhOt5S3+aQhgmrxWPEOEIAyRuD
1CjgeM1ro0jUH70nObG3zeSor+2Pt2i5DUIv+gQ9AtmzhhXPXKFFMEydinXjOiomAhKLOpc3
vteBhJS5vXoQC/vhZreDZE5KWpPPtshElzB14XeCfk8+f3YxapycAgrc01VNImom2e0k96Ii
sri/j7zrKEwmVYUr7j8x2PhrWGsxsK37UHn8oAabxYq70OQHqAZox/obsFsxder4ebNc9gr3
qi0GSyRFhn+z8nBHtv4BjsM6aRtNqXvDZxgCbjP2Bh01ndDIkuvMZpaiXNthD6FlbfcDhAug
uenrPcGVBc8vY36ihbBFQ9cuNdyKp+osNftmsnvkE2+90YkZWBjq8jEDPiXix4z/mpXhS9Md
L1qCxYu42lPhMN6Ak8WqH0O6K+zTBr7X7yhDTW7MaDVFcdsJXSXqi6HHg2LYrByXBlutloRI
E5wQYzPkKw5Ov7mUkRO3oX6i7N+OXwiizBfE0xsyq6etyMU4zTIcBuabp/DXrcbeXYb52RaP
7Phnih2/AsyCEVBawnZPjQsVfc71Sw50vN5lOwmeUxidTq0VUEsTw33iyTGum+nHftmtqx2G
uds6xQopFWfNnaZe69KrHhwpN7xgUekSEJ6+G+XJwMEjoK0/shw0Hc7kNSU899osn/MU2nd3
t+XvYW1W/9RLyuttR2yVwWyoj4etHVLKrVd90mD2RsWXv18l5A3HP52lMN4iezaBEIuiTtyE
zRIlNgJwJXeABJg/2PXOcq338PZscHxSRNUgtOFpx8DxkLYjsH/iBtSQsT3XJ76YC+2eYtol
UXHZAZokOD2pcsTRheKQY4E46sQPq+udSGQsJ2xjU0wUJzyVJ4b8nFQZVzNxMQB8K1v+D/+u
N+BzV3B2AzsGg9uK5c0oKqF8IgzjkdWSTaEQp5gtGFJFn4+d4CdBz9McGXbVbbchmEAeaPmL
oJ7fSGqJjEWqh+35fUCm3e4qKqavuc891TvH+BQ1l7O0j9c31YXo6FFPLVzWviQrzjH6gXbn
mW932IZyzci+lvnEkkYx31vhFa0HG0KleyNyNmmzFC8qPXYcIyP3h+YXLTOdUBElzK74qTiA
yeyzBxCWuZovHeq27DakkNzG+tKhrzVxQN5tqxxaVhzzJ6ehroVSE2k1hpdtn8D4E/Wrs23p
Z55EyusthOXTdn4LOf0iJNuUh/5YhWNIXH+R39lsV3UL/D97nYfb/CTgFDnq0LJx+oXG1E8c
4ImdP4MRv5f78Gt8omMry6LZ1Kvp0I/4CGxHgOU4ybw0zeoeAN3SaXEWf+S4lL0RH1z1IBfK
byy0I3ERQQrLlJ1vqkej1RDAeOVaVImuT22oDf5TpQrNbFjVPZ/HAeCTQj+xfUBtkg8ncceX
QjvmzYQI0EJ5LWUX495S5YZh7bPForjuLs9hrQWiC3cYBwlBrjLoQebGcLF7E9R+GipVTkOp
0NB4IjlB2eDKJcVvRCzT4hMzEqTh9Y9MZSmbMOUGgQx6HDNxBJ3mLIJdEVZmFiaQJp7AaKWS
5y2fmdDQ6jDjO1fvSJdsF3iYJKjpuC/hzFO/rEL6XuivYuV++2sdjdRQfrFpOU/c03LG5a3G
qS60thewaXcYN8KJUzhVB7TTHh3arHYuH/x7fqzlO0bm9ZXWmIgCmMzWdJRglTZzv6QxEXCT
LLCxDXvho24hdseMji27JYHEo39kGKaBmkT5D9yCQBsKuRi7yFQEVul9yyhyOYAs7e9E0xeY
rzCuMeX6tRqhr2M4KgiULyOqXjS+PxWKJL/rLD70NFNafFg2+IRxYgY3tD3ilwxOZrPJ+gn7
W0xA731p77A7UV4K5Mt3d3uyshKm6Da7YDK4sm8PzkFs52Ey0ONQprQbBNe5xVGpSGj+bXK2
eiLFB6gIc8kYJvYZU6pWQdmccQGhKQejyeBQd9HHJw/+NdtMi86nh8QsHKulyPhx4Vw9dBC7
IAFxvD/nqs/8EcQL9vlEwZ3a7OQCddig/ISANIYkPUbUP2s70xnpD/YTixL6dPQUmAXkZ4TO
HLvNV7Rdfg2l18f9UsLy4xTxEHSpTod8Ze3rGxvUWZBp4iChOnRsGJEceFqdioj2sc8pJpnE
jdJ5VSjLDxb1Sar9YdjgrPY2lqXmiaPcRyZEQKjrACT94iz9/Tgemvn9Qxmh4ckD/qOboJXE
u370CBpUGB7exlEox0GwrOrv32sNfly5maNgULbf77wbqXqQZzzxBm/BIFA/sOlcuAwG4nmV
ql/8WxrlJvyJ3MDR9wUCbDaNv+U520G949TqJlVIuMkDCllXYoW0WjVlWJp1AP/2ovb9aKii
PRHUyLtcQqN9yEI7EF5PjtNN7jhKVCcPhzGGw50nKLm8KIn9jUIPkwxiOpPYAKed4epNrvLY
HbZtqyB6vYmPnk9EpZe8e9c4CScxThjnC7mEg12FFzrY7JEL4jfsPl4FI1JbrpeTJ7V/ooIP
Tg3xtAKjkP10kP+zSC8GQG1f0yaC6CnxGaAVQhdDYy2E8loT9U8izChHfCZrAE8TP9csRU65
Ke5wW6rkoTteg3KjIMHwwomfYvFQrj6lIVrCRAXokAdhIbv+zE4Zke4QUu+w5IKOXyu7rqlv
815TdXjVbEKT3Jm/2XR56fOqbT/68so1YnuxVsfnJnD4PnESerIHAKALflLbhzSNTt044xa9
IaUyfHIWkdv55eZKVomsVPKnjVpo+qQ67r7kwaURsHu3cBsDgIBuaOl+Poou2vw7DJyb1o6F
ONJhCZBlkI33Fx06lMKAtz5nse05/Fc57kAghv7u6eoPnHWFvKgtIkBxhUz3iWOb7pXPLZqt
ORruGbIfk2AwGcZd0BNQosBwSQS6vMD8e33gxPvvOg53iC1dwco7IzGGJ+wHtBCKWAoDyjR3
JRE05Um8AxveYA1tzWF6g6rdT+nmZpHvxMUmA9bEB12uMyXcWeEPfti2f5hchaCw/rgC2huA
zkVVMZj2s18RNR7wmpILPwdHkjqXipefs8SjJujV0y3d6wAnFtbWJcg6vQ+ADqF422dy/iz4
cnCy6gHUobh9E+BWsPIZboCRl928C/nzB0axKcWQAX6f/f+Y2VYQIKK0jIsm6KFpEDPyVkf5
nfSIlNYZP5nT4HuzLDYyIjB1u5K1sQDM+PeDlUL1P14dUb84quyKjBInDOUyZdwQqerQFDka
oqQsYOLjjLfO1NLVZqR204CiYyn3qiqV7aLkSafL6XNrqHAZyf2l2kr3pQvQisPYPHitdWbY
Kp2ZFgGBVxOEZy34ViXx4ksQHncUoLkqbyV77gJPxy4WjRcGu/zPtESb0kexBeQPkyumUEcE
x0ZPc7DJ+M3JRevnYiq/Bw77kP1TfT5HPn7Tn01vSrGmx+h8SrE6q1AgmeJa6umj8Y/ctkKH
ieGLnULvAyycEWU1rNUbHGORa8i3IB0Pg3g8vwnPTLWPHHQm933EoL4Nun/m2kZxy87eXH/B
jFx+XyDmRN5A2DpMVpQsMbGW38U2w2BpxRCBIgA6zbzPLye06eHY4N9jWLy4guJriEf4v7IM
GPGy5MDO6tS9nXFWz0v27WBygxFboVsAu+qea52uPmCFvbV64PKbXVHRu5A5Oq6sRVdHbC5z
hIqcd5niOo+TZwbUXrT0HWX8++ns4z5QMlmczmvdZGm/WmNueEJ+iRvPURtY64jAR0Qs26IJ
IryofKZqNUZJe8D5syFExkmoYJL+bTs2DZ3pkqPNDDR8EuxmZrq8M3W/h92bazTJMAI8nfji
Q20K8Xcod8Jspkg2oYDnKLnUe0vC6AhExqU0+I2vG8HgA7RNsVHa9Kb4p2DPZCApF6KAbJzm
zEXb85Q08KAh3uULmkgXGECjThX3FwVos5nJPhO9UNNCB2OGKuD2CujEi4nRVpzS9cVtpOYg
GZckJcbFxQ8ysTzELFhbpWbpTg6OADg92lACScuKBwO1rNV4Tyid3zym47Py683vITc6oN6l
jBxUmCI3vN2Rbq3UH1sZzRZBDT0y7nzUzrv8buMQ6ltByeJku9DUJyIyhheuPMNPgbQPhiUo
lVZeZDLS/qokq2AgaQYgVe1ZVHiUFBtvKPfbtBfKTjIUBVJzk52tU02eRWLeD8baxI2SKNVl
KuR708IhvduRHRk/alpDOdk7cFsdtMG8wRO2eEQQho+Sp28ALreioL+6hTpsHD5URoSUJQ90
E63oCTAIvNGc+YGyeUrqeehFkvIgEmOpjUQXV8dS5Wht1qoiJPJmrSmD1fBPkOml2HtsQQQY
UJo0ViqKIZ9C/bZ2NwiXdbPfmPR4p9lsc0WCtCQgO+VSyTCcvVT/v7remqRMDRsTAbYev+F7
idiMQ9mUZzRTZIxnZ8Y+x01CBO2UsHYftnn5l6vGFd9mfyzLaZFqwd/KazZKD3VUtfDrJLR4
v2OKA9EuxOzn49jCxpIM9iFtaeIFx5fPHUJtf/lQSTDWpBB2QyQiSvQ1jEnqU2p00wcaBE2J
NEkl2Q3+CQKJh0eQd1CyHjFKoxXzQjh/a3Dr/KskXL5a9oL4ZMYki631pwdtiYUhmpnQ4eri
eLq0FtdSMQx6yfp6q1H+qTmRU6y/eETGr+w0XR9Xf+g66ZFCxpTGcceeXC7Z0iStdHEsbuVz
BQgY8aCMQIJRHC4ZBrmRh4wUQvS+GYIqiv0ya+BBk+MhmFm83LOF9gHLKtOaou/cxZ+1s9pw
Hc9Ye/HuX5uWUKifTIuks4/90f0LAdu3IXbxDe3S/XYboPX6NTZg/E4LSd9FcPudr8geXYi9
xZC1OQclYnYwbM0k5mtwN58KyYZK6JVahVihDrWSry2anUrWBtONZCO68uRx9ueku6h5ksvM
AOqFIQGBsHvzpuw+qY8AvwS4dgpfr5+g4t/tUBaTlXvv5jG2enUJ8YbGz4eE0bXRl7W72mMy
xCACR6qCirf+kyQ3Gy0PsgtXM6U/RoWdvdgbbFNsoVkZPeD3Uijr0IZ+RXaO1KzFyh1+q+XA
6ynF+QVrMRMpfYaDiIVTOvcHBi0FbxcH3yIcLdgJiuWHp9muPFV2RYT9YllVWzuDCwIYUTcn
pc8ohuOpP8wmy0gKMWwolBwhbBM8OEHBPaJOR68LQrFYVfT/Wv3JPz2fH73b81lxdMGwi0a+
eyM01KxyOZfEp2pNHBcwQJw5Fw/SLYqX0q7T4E2jUz8WqT7g1QGQa2O4szRWvZEkRqISZI3E
cYMNbRt7QWQN0gOO3ssKEO9OB2kY2Nng9/RiDLCx3I2dE+/ElLBb51N2Vky2f5yXg3jl6IEX
bS8XikJXMAQN+yUrC2g6u3rBvei+zaNQYG+Il2y47OPqdOVk+J5fFt2+HFW7+tUa2mO/fFvc
GeRux2+jA47SLUCzXJ9Zii1A0IGmVy1K3u3fTQgPFPTErUcc+JN+bS7iBj3DKY3HgdWnxgEN
CX9+y2JgOkfSiabLR5iuxiF9SCdCHPPHca60BUJOVJ3N2NrN+pKwCHT6VrnIT3SuXp7OzIVW
dMZCeYZbxqo+cfSSraeIj68lu0AG9pPf7F9iAZjrJKgV6d96GOwy++fZXFnMEJ5YvMaMxmN/
dkL5RJ7LW22gu2oDJ+XBQFRSWBx5y0DEPUsZOLRxkKaNf4Rh4xYM2FLcZme8uV2a+Zbge433
YTO7VnWq3efhyVny1O7EKtgq1vXDH1q9L00skcJLCG7s5CiHeHFs0vahu75uEAR1uGAqrSjN
HGGcBOlBXWUxid33nTCg9CSx5eBrB+0H2l2gM8msOJTlo0ScFaeuislO2vNRm4zErGH56Jjl
NHXqUvkfLW2LEnGEyttFPRFdp5Ma5ZhV4xcWqGE1MDc3AKhXx9YNC0FWUjq0LZ7XA4RHAvjX
S9ktGI/cgNBaPzdUPb58J4+WtIZfWUITCzOgDw60+38iWa67gAHcj0aXGI6VPanSlwlWrq8c
+iCGb9NjskRy0cIc4XUriBMjOP2UjQ0kchek+k8kpHDYNKcGgwTDkIVT2rRyfzE6+aO+c4tI
98+zj7yQ2qzIcIKDP/KzMw13PALOHKSfV6uHzBQL9u9t7Z6MW8YKRnffD0QTVQ0BwMOm3fBq
MU7YZHJDE6ITsOFZ7PQOSSp6PMuMOVSmhvinQvumquKVLOUHAO2wkqNMw7rBMyYZe8/08gKT
y4LnH0IswOWXqpWViTR+efBYhznauLU582OYq/CcSCpHPU1Av/Ahdf/NT+MMZN4Dl3jVS1+E
nONO7ete4ZJIvjcIC5eJW0sfmHtXYa1EPeRG4cZOmaPde2Lv83ccodYfw8bM52wSGYpw17tI
13jWwzP7uymdhwaRvLcKm3+rlQ1okGSf8gtZGMC8EEj2O6EOaDE30D9dfDE8TkCPaaADzFdR
uBdFIY+bcY846F5gAyGBkPXsTibSUbSit4ZrIjoyLrhEtXDWP/ZOANnW3qThEdQQ/mQmKmiw
PM99o0EMZGSLw788sJ8p3IW1hEl2Pq5XIRsH+OJ1Kcj5SeG0vCykKUEw91l68paaOXOkvMzD
dsj1yTIbNbQcwLw3PnesbiVooJNcN1QR/q/1JBzRbXKLwJW551NjlL3gw3UA42GnIWNSBvl2
7ZdbL2ARdrJvfpFiGtfRH39Shsrsf5dEyeh5K4XjTvK86I4b2Q7fmqdy+wKGHMmwCQSkCZQO
Tf0a8AcwisfVZJ4x46ZTiV8HWorQtLJZLheSINciiyEkZqQbRayijutC3lrpfIU9VofoN9U0
Ki2c4vPsIVQCyxgrX1K7x3Nhls/h62QdgPR9hAGDoisWDgkU6sGd98g+KJm+YSRy/ZYbVV6v
E25VRWV0yZJiV5QaLbhF7tZrfFv4eU2+TjYmcDALUX0qEf1sHDbFP3Oa2xpFREMDIPeN7vDG
kv2P5L12eIrgPxT5LQfdyD4+FHax8X4K0b8vzgJ1BwRigZukuTllUS9kIydZ026tvGrHGxqY
zfKYzT7xHhe/HC6DRMRMkh+fDHnkX9G/k85ilXhhThsHzUv3ho3udEfHJSfwLO4cVo8Nt+kg
asKzTgHca8Z0bSNTK4rLt6/r36DhhDP4xzzqulLG5fMAMZBwB53yVajyAnuVn93fbJK8ysJE
1pfkB3s4IaIrjFpfEe+2693i1REBx6EeTKWfcMlz3h/Nqg5GNOMVKAOp/4dOVtExFc7KH358
pn94chYW1XSm7gICwZLVVjv/sdMlO/qZGPOLhwQQEGkhkv+T8t1+U+tV4lFw2E8LmCdztmyu
/XAjs4Yvat9Wu4EOZU/wBvLWF8YPTlK98YYeLEmsYOEA/wvZDrizGrvQYMpRUnW2JHMyqvEF
z2g7kpxAdIYlEKDaB3xtazj4VMR3F0LzOPk4R7+ZIMkZ3HR72TNcpkAmAT3gE5+iHW5B/37l
wgZHz6eRHHN1+4efGYFBYM5SVmSY1baxZWDcVSKwIPczdiB9v1EWAJmCFYYCX30IjpoLRK77
pLWgvKQ6bzrdb17urJ5he/hj92DY+c9xd+9Vji7tBvXi4GgAcmpRMqojzQTuKu5p3igfbBtk
MKNjHhYgkMoljfN+2yFKzRH8HPAGw+sxILCmiMHDfJEdCXUEhFpXjTv7sfXJBJUjN9oBf+6+
067K1rEhYIYa7mz8/YmOze/p5cyDuNdGNnESB4XIkQsC5/U8w6NxTwH94gcLDKUB5q2GahW7
2Pe9FUb25nHhQAddlREgx0bVO3gc8Qu8XAn6c5aLerYZmdQ5VoM0MVPBIo+FLGwGHY9+VuEP
BGB4ktFsdv9ud41WaDKB/SauQPgNNbmKspY9NgGeXvwHhG/8jdrXLejEMIlCznofp+jDFpkJ
dVG6YcswdK/VhjCZXQkRS20mQvKALnC84l++0TsAbxsMdXQ3fg5GkNjPI2oqi0aGTJ7QPWGs
2Glxx/2NpjE1sjjQpmdA9gDcOgBtHah+2Mkq5s4RehhzFwuU8JJj/hNivZT7wRJmB3l+zlHC
5a2YDZu0n7yeGRDDEYGBDo7CfXN4YsFTuJywXp0xru90Mweg0i+61RSrv0RdBPk+zv5njim7
1rP04GpN9wSZ3yIucsWM7Y4K4GYaDZJ9rXxP0wa/JLIbhVdHSUBHnSOJvztdfNcHYSWnjGGs
yE9WBTv9qLlUE9ArPtbMtluN0VbIOaKVOLfVQDdFXoiVultYYiR/izrhAyAXEaUdDD5lkztC
mq3jqD9/klZS4pRrPZEWF3zGZitDnqRq45iWi07pjzkxt4DcGV2FOGr77W6lDBVmHiCDqEsB
upRjDFh8to03P9owwLPm/VUlM6jxKOE8vvpJu7tYX+fT3EBWmoxPHpetWMSa1RC45dkRF3el
3+Vpms9AkkT0GCGURyH/x/jsPVPwL2xUEO5WzLlyYbrnXJZBh1uhIjCMdEy8Mst2FEYRRjoG
B2jU+GoOY4ZTtRoxli368k0b2MFnaTDg/VkZScG+dpTMjSh3mCkAptEcE5yOtcDwF9E/KkOk
rQ7UTqZrnk37IOOc7uhDh2pJGB9iV/DpgGTjW2eS940/bIKM+BpZEPQYI57TYte9NRvYbkZr
QXGta999GcS6A/IpLhD71bgFU6FEkMJkJTiW/GlRYrKsVMlmYr1oY7gJguj8nyYqV8obCr4O
u2Xw5n2kCs3t1gQfVw+W917rFj3yYJ8D51pDEugGiVSowOw0HL9lgHINU82qfyr5mUwiXp9i
a6TjFu7fDFlobk5OD8JvVpm0WO9tI5ikC0FkpYVfw89ZWXnns04Ts5Tm9SXNUpVnjxo8YQaI
0xvNjKa/2B++IjCYb/ZP3K7hnofIQWSIEJpAcihU6mtn1l+OnqSvBmv2/N0gZKm6LEJi6m4g
CbrVH9X9B5Ili86Rfb3MPbGTC49ZBuf6r9Bfitk4qZydcsFMZOCvbEafIqx+NK/cd/i032S6
pTQopS/m1c/HL6mL0Hcp61Rpi0PDhgiQgubFJHGQtbWO1UOYDkLKZ3pCvA96RsAhfTI70zD0
8acuE/vEQSEtE3Uv8paR1y2SH9XZas4wllrVD882AzaqMjF99aMEZ1BF0zLg7O3R0lVM4Md7
fmCICVuHo9HYIBHJTGQIrgHMxcWKo2hKbhdvXYno9A/Lk4O8aYRG5HPSYrWppHLhUnRKCkoO
BerBSxJPBpSkdtvfHUkUKO7ci50DHXo0La5xLzg5Q9gTdMG9u4NQUo0VZBtVeL1tBeBCJee4
g5NOgPwGm9EZChP9aYzE7QgAnQTdH8kKmAUo2TvQ6hd1xKjIMIA8wBaDLesQzgf8FyrSjZeG
SofmJCO9677fzY1RW0a+74y+TCfHiAe0LvMS76ZTPFj65bAUX7sNPNFxbdfKsDtv0dqOYVGO
TE9x163VLS7IzQvQj5KdsZxrDlx30bg8U/z665Oavz45sOEOl0uQf1jE+ap//33A0tI4oWJl
FmuVfi9TCA3dsptY0XytWKu5LSyTpdpatjoJH7Aciqo/50v8ORxNaWPX/crC+4XjNhoyvk0M
5vQ5yU8nHK/mZPZBwLOjwoVR77Ze98R9+G1zyaeKaPOPMet0PIlaFi37PsBWGEZH7m1HRkGF
7Q4fV6t43r2DYrTW5dVVzK7knmxHsq4U+h72gao3mv2HLaLLL3/lliaL3/AYk2YKluGHZUQO
FmSczsRwAAaZdooc3kn7D5aOJ2Tm68NcT68YvevxKEbt1bNMjZsSZaZslr79c4BPwal1FGVT
BUj+bGYiqSjeugz6yG7VvvKH80W/f2C6Y0hSvxBkPKa7BC3qafe4B8+RMVp2SFgBK4lqMw1M
/Cw50ncGZ71xPgKMzigByrSOszNU537jrndre/RdB4/YN15D6b5CKPAVV7XXx2xcFpjrSm/V
V/+YJjBgrcodWAola9avyOiEGUoH/NtMHZsu6G7qup4MvmvLWv/zJuIR4gusMeum/8s2KjRq
b16cuTplajYjSylvMpjXvhJ2mz/Kyj2ZEyRaJtKZ+Z8i1kUWwM79ojbSVen7o5DuqUVnqP26
00XEKSZ8GXU9MkF/WL/JSmwH4NgDnPvdHl87HhWyYkavylNp0lpXUVf/aVTYe6E/MLkRn/YO
woQd5DnydL61aixRZL/UycxmEDLo1eYl6RjQyKHCycm+D2HwIAOlyJ/xylcQIhtCDbBRIrHy
2lNahPLJR43RsPy8M4kvYliAJE9WALZYBpRFeyFjDpIjce+4Vre4N21gIvWr3MaUjtC0zOIK
KWOWEWzOVOALvf94UDJe8aNg9HYIZEOt6fHZkx23cxoYJMCo99yC/tXxso7DQWUFhlWkxQxA
E/Qm1B/XIYoPKfDKdmt9CL4UnGGiHs09W0if6TJT3zUr/rm/Rj4o0IuevwHMIWIZikI7zQgO
hQRAm74L47luhYPP69S9kMNe3u3h7ijc8MxwpgEuytx6bgFpsw1VpGdtGlQdGBloGzClaI1U
rnGru1s5vur2Ccw/tW57Vrg4WivPKSm9rl3NSLzZx/rgy5100glFbWF9a3t+JSjONTvEgK+g
/JB8GEYZO1QJ/eq/K8SnBkJcwUDAfEANpbq6Gb5AQx1fdcaOI2FvMNI3K7yA/Qj9214h3H0m
hZe8CA2q4bniLXUnDFVmQ5M6DG+0HbdcWmVxNMKqlDUCDaN595U6QtnsP7PEdoLAITcUvgUv
/n7Czgkj/1R0vUp7To1lLcmxqMcIgcYElNu3fZEPogfSdkvx/9rrt4IXn49ARpCY8JK2KjA8
HsWvRdcqhM1Os6YPRUqDHJuL2kavOlw09TV1T6ZFgurAcQvYdnvHDd3tMsoY/JL9V4kBhjXv
zjP8jSL86WiSauOEt6ml2Y5M9rl3gFG/ysJ6ph+fVDN8+IpPDPdoboSo/0gSbrLm9CsXXh80
7FrSV99eJUkzZNvU2i31wD/5CbSVIlskYfh4U3evVVXHDw5wpjHY2YINl7VmzBKJpGrTvayt
34aPvmQAIUgxRuQrCVf+8T10dv9w2q51GNuO5/usu7GbvnhE/0EMy+jqkUdajshGym0qYs5T
ZQOWnLcJqPQC1/7MlUO2VV2jXghrf/PGXZNz6wvs33Kl9wcPeeDapO8Jf6lSfEk5SEJXRb/I
xYGRS/0jfJDOyuJ9iH7WCbgveHCIo9Zwt94YWK5eaZ26xW81HxyslM95Q6IltMFqxsxvpZd4
3+uuq7ptVhw8ZxFWGWGwb6kD0kQ3KbCV6jY2gdJ+dlgs5ZLso+1bQJ42lXTCFbw3OkoLwEbi
oNXShuQh4MlWHXc+MekxJu7fKhaO2sHAFWqxm+kh/krZInR9eC2p7BwXg2qhzj6I5dl5QprE
Wh7OM9DUOzdSo8Pm1+AAfX936j9V26jrGxFaT8UZr5lGsb/y1+tF9jVKzxDNbVeOJDzLcpyT
n2XuosQqC/jFYvA1Qsd+C79LsjWlUogJH4RiMpzikpvUil3sPWWpmpCyD0sFRViJtOEuarJv
OvxzsJZWVpGwuDjd3DLXoeWjWJyYxLm+9QgFbHGuknefZLZ7EgvApu5RpWZ1TP27Mm6+obVE
92YnudzFDfvZV7pJkDmXkN/TJN0IEExY0LU66Rqxdd4dECl/3gyrN9S9kqn40EZCmoL7eHey
uGcin2IsYCu5Czl0CbIcWUloUDQku3wKhEqeL7w+xDjfpXHgmjXCgOXrK8MDGQ816UVTsz4V
JkVOrVqqqqSpgaRUvVEwr8lNkpDGeE7/u4eXlVdRlAjetJ7WIszyPPcL6bfMBta+7zEujh6k
DFhECPkqaZH2Ybn+DqyjoP7T2AWyKC1rV748g30gOfWdJ1I7WptM+SognwCS2+rN+g3/OxuB
+AemwNUtSAfwb0HF/n5xv1nznFQ35fbv6YT6tH9RV2EWlGQcXuFhXl63PzllgtRYfBFW6Oxj
hdbU8JfC4y8A0D5K4k1C8ejTvreMv5eLJKR4gXkFA6IcW/jUzHCd4g3zY/G6SyyBX/sSAZ1L
XYTGBdxDYBubK/o0XJvyMELHtY496WgFwZva67VcvfymKuuqdlT5CDNVrCoOr5lQ0eKpFuvj
u+StY0B6UhO608JFNJ3inX/R+WMs2oRBmmgOdKfvWEU79o0upEETU+ocXFovWhueD/ARUpP8
C+0d0K8shmOxfLF6uj8XcT2hh9fMkmX+RogwbsmB7HOLGoV0ANgcGdyqd9cvrXt7LhDpgYQW
o5FXKLN7mMhMxVhCwZuVx3f5piVqv6KBIw0YpLoFPQzm8YshVirEeugLU94CIn9FT2+yGNol
rd9Xs1nWzLVoxPPF9K4rIa0FN0sn+blNclD8pCGPL7hvbbPcK8e4bHNuYFEsUNM8KVjhU3rk
9JVWAZDEDm2yPwHBNyVy19MHYQSicRhJvvylXc/i/BTxARFCz2jQh8dy8kJBXI7uFhnYfa7K
jspwFDTz8MYUXb9wx6p/eV8EOufawl6pUz+MIy3+o5qH8sohVWjbvywCPSy/m4zQ/hb2blTo
ixeJzkZun7sl5BfXb3jgJnWE0m20fa1Ng17nSye4qJckrYFORzVr5BsGLgi0UPBtSkFk5T5o
LkbBjPW4EyO9PX4INkmG33/vFMRHxUAS8gi/q5bMKsSmBZDtlDnnwkIjNka8UhBj4Y5eVOue
3SNhT6QXVcLH8zQRpQ2VEASKrsBYH3Nmg86n8jIy0hDk2xRLq9rinWair9WDdvoRC/nkOmOA
g3xWTO2szEsy9HntsjI5h46Kiwr8SZCZAW/5WMM/18t3hGD6dzbJq5fTAfUN3buGnw2bBmUG
ojoxZyaM0d+cpCY2Au1CfkJjwPt8rzJpFvlMWBA2o9zCcYbmjWGJSe9KBLUq7O0dVjSSz4Nb
3A1eB5zj1kCkZEaiR7gytZRWynWOBKM5785hvLaRyYQW+WNkcy9TOhffbYrF1dMrOi8rIWO8
D4T6/oomhqPKkfskVqpsQzZKaxo0edsui6MNWs3p6VklxJ1zM51tfRO4jy/BFNaPz7+BgDFu
WbHQaPXc1EJWkMK1Fs5q5t23dKQSHCWKvtdKmlGoReO9Hj5obX+WbAkGX9zsEFtpcYZs2MKH
ecSUAfZuCmKk933uvW5Nec7cBFJQi6/y7PkdyIDwlvlJ1ijjelADnDfkobGpK4eGfFoNiDCi
vapVXdTO6qzklDVdtOO84WUbTkshWMo7wA6dpea0AhIRfOzMZfah6IV7jVkwslrpU6jzhArs
wbhbijNMAQNc2VTGef8Fm/XK3VcU90sSKo3fYuBjhujxxXQ973ETlCybXXhkdNJ6xuqzarmK
YJwrTh70L3ZGBpPqaZorc5FihaK1hv+VuCGpxu4zY8KVYDJMNaATaaCL9OiWa+g0JqQeRiUH
rYJXaEMCRYHVSriR4AudgjGC7IXfBWP6GiT6D6qGMmNBjVRL2AdeYcyvqld5BWh+rJ9L0kRs
LTz3r1rKouJUIhFEghmwJkKsQd5xUwKnGzc9bgMkXMdTpJkl/idAOlfFxsAzY0PR2tGYEJFi
Wq+zrXLT5pGZrU6PsFBeFMDXwlsvZJTq9SfbtWj1dWmy6FXCjsI2S6os00vkHEuRXmd0Sx/f
zThdDPw6lY1gm1oeLYtN1MiztBdCaDPGeT10MxRPzZat4/W3FhJ8+COspfpjK3hIWINlcx1J
cO9vzyEnkHJCEJYPP/eU1rp2+vi6W51GqPhRQSRaD8XA4Uuft+YFnQ37dsAQ19gb5vgODpTh
jx7A5opNlzN8EjNnMOwYNvceAdU9tXrKBHSUIorBa9SMhSK69G5UVDd7nLV82K/cwaCLBrWI
h+V3dalU7T1WIrw76SK3bm0mwT5c9FsgadR6xO5R/rRcSUomNs3ArXvvqfN9zEkKUsJqT6j+
gIpv6t6aAW4DFbA1TehF2cr9COP96nwKHGejBv4WjexE9CJd5iGOgSli1CTWxBzDnSzOaXdn
QBrKrFsQC0qlQrVmWqMG6zYf/T2XOLBNS0/e/sPRGgLMrcMgzIh+26sTaBzTdOXSv4v+nqtM
md8aD1elKnwB69AVM9HjF7V25JssqJpNY+5aFKm3Gk1OYf4qCG0I26VtUx75hW3nE3aVKNe4
e5+4Zo9GxLHYF9E8TO/4OVEnoz6PeamALko15BMBWVO2ofIkIQWVpVWPMhHlgZGw3/sJtYXx
4ZqfgemImvo5D4DyVGs+2XNAhpXIIDpZBwOhHUwDyvLlT90wBjntEqQt94vgy8H2KhN1OSfn
LExtYzCxTi59qMUjFjQLuCZAaPIbKr6W7UNkLnetEIlIwpOKg9WyktKRthF9OeWu4LNNWc1c
p93nxQ4AkNcebPGG1Qyk5RQgrr8vIa8oS0oy8a9oE4oHtDIat+FcRT8G0k8WbU4tLnlC+v+w
edtaonE7y8iwfOAeGpNKgVEiQCAJ72CNYQbelsFroxEpd3Sxk0yc8v99yTrAvHQjohARV4ik
W30hv6HwsdkEt97IXgnkuZrmgWx3V0QyKFzoJn35tjZ9C8gcf3lGD5gJuZml2GCyO2y0rhef
4YysI6GoE6bjUu7H1+jb0An81adOWs1Fc4+qGNp/kdn4OocJWc5tCF/L7EQqYYN3KQm0PQZD
plhfchs6l0Ou9oDQZxzfGkn1tKQVdYBujfRny4968wpjrQheB56Vei2vZ+rGmGoh8mBYHnPY
dROLvs2r9wXRo2f3lL2Edyp5psRCZ9Q3/mV3ZIEgdh7e5N+dn/YvhIzBgE2IqeNDlNVqGnjA
BHiTnQO2D4t5dGYUfIaNc2QKg9raYWrx9/pJEplBn49QLwtwgRXE8KVNDLA4uWycF3SOgogB
EgkTrbvFp8yQ1vUJkxFVMfYWb124WqQjX/t1F4Ccgor6IDGBM6Nusnh/omF5LE7Z9dcvOc25
ob6gSvE0TQm6ZzGdvROoO5kVO/wlsbP35sNxThvZYsbjAb2aL1WFiUivZnphgcaMzKAZfEf4
xXIPFJRAr79JZQ17nkT8jA23NEellPkib3OLZnPLMxWUppGEvX1vDtyAJz16UnfAjUlENiS8
2UtTTT/xBsLxt37y9wWNgAzbcygtUR2WTEMVRg2MZnvmuG4GyDAlx1QGdIrHzIXtzmeQe+9x
jpXeaVUWHOBgedj+RLlsYaPFKBwQE275wxoYXLo/njFcXe7RcgY3JTNnlJ0nWYjimW5oq4Ub
vRaiyRUCvbkP5NQuiUwjizKtYx6Fwx8/pfPiZKAJO6n1ar/yTVHlVS71BttHkizcIeWWeXgw
CtfCSi/j6U5ODryIQCJdI1rIOzL5tuaEA/164hcUikIMlag0TmRu1pYwhu2nGH0cQnfUFsUy
VuVYaCYQYqOqxOG1K+jzzh8akVeWTqFUaTkBJ6GNVKNkjfY/T8Hb/0j2QawWTZ51SlrXDq5T
TuM2UYifFaS5FA27oEdRq1eisqB2sGCE6FsCXAfc96Gykp/ikE3j5dSs9fHtDmrdLahH5Y7Y
9D81juXAt7mYt2dmKsSxyyGEQqT5sHsXNEJ/c+ZRlOObESOE2fkOya1NoQvGd3W+1UwqH++q
1bF+XBTi1kN5cADFsww3dZv2McbW2lgsIsUXsI4Snf8aqn0wKyyoJw15CyY/ivh6jTbxaRWy
6cPPqNUp+6YarkZglnwTt/AHzJ0N3sK3qX8sp2vTIj9QS4p7s8cwEpLNLtsaMnUsKRT7ENfW
eII7WcjBDxGWyw/akBWS75pjKPYeilJOlANZE5ZXAqlFuRPiybe7ql6zUcELLKtNknxItOBC
u4IaIwoJQDuukJkgdPMkma9U8XrRun3dqYGhV+GvXTPDSfVXviMKsEuPGFZ9yc6z3zksSDHp
/+aX5uNn77XwOIdZ4hHC4wiJdteBk09lDmIjbYnuSICedAiBhQCmdjoogOQMCysDaNNECe/O
o+v7oyd9kOLaRAzm4xLsPk3bJjFUU/e94W0ZX/UuD1F37OQmvDv5PSDf1ROpjgopSdo4yIxR
X0uBY+MqOGTvlKO7vTJnF8UHZJy3DM1fI8XBJsOLBbazkP6RNlEflJk9FCwwO3JL60h99Byo
Gsvl+HAWpq9tSG5KGC1lFBsWmYCwcUiP+8W6crERaWfZiGM2RCSJILcyuZpGqNAVLgC9Nhi3
6M8UoDsR6ROb0cCQnZliQ3evz6PdfYeUznYbaYH1tsxn4NprC7Ai8xhUc3rkGIEA+LK93Top
wkrVDK9y/T13cj0305FwAG8G8GZZKra8yChW4R2KvFA7ZDjM6eph1UuZ5O9RoTGDeKOkG+Kc
bs7+bET8oIqqL/BClZYMhrbcC54Q7o9nbwwrvNnW+m7IknpP+80XKu7FWI+lD0eHNf5Yjcvg
90y7vtIP54ukB27ty0b6GCfsPUsSOBy6n6+nLyYJ504ONRwmOj3DpTFzsyTScb4ox2GGE3HU
U7kHGsZ1pQZ8Z9KiWXeD3yhN4Y6GoUkLUKehYN6TIL8BQ0VtaJygDwt6pArhzSfRoxXpOtPu
yawFBp1P1MhnJ5ue6wtbXgBA4pwre/i+mTMW2oK0q/c3X82tXb5ZS0X15NZOZdRS9A8X0e2E
zkcBa1cPb1QTbk95qZ2MFqBzXCZUPF492XrHI5l5y06yMLNSB+DxFm95QRWvWqnEFFTHVfp5
8UumVuF2Tcx7/rXKlhKOtZgC26nOGHuBhh/BS6i/clKqu2u1qeMoUahES1fN8EPccQxIHLRi
zwDv9pFk+yc+/JMxJfTX6KJz/eZHNqkbayKxdacOuHP9zhpe1oUXpR+JI6EMurxkobRQu7v4
r9F1XCh+zlEXjz2ienUjgNxpu1JTviR06EH02G1/q/LffXVepDKU/PmSHCbdn80MjNiibnJY
wJ2UeKs7edr6kIq3hzH1Z+9W7EwmMTEIrc2/b3SYN+Nacn2F1F07R4G6R8t3WcEtsWI8R33b
GVnC3AG9TQi8x9bjeDJlhjsY+eiI2zjbbGQa3BGe0LGSV6vKPoLHr9279b+cvw5zpMgIw/6g
liiDuGdvDFfvgxhory1HWLBQX+9AknS9Ly1Myf06ZT+TNRRRtkxAeayN7PnGDogPeLyksqWT
/MeQGJAGWYgCZx/uPMY0BC+Mi8iXrwUMuoDjWi3l/dlSDv2SBFW8IYaFDubPZcd7iexiSwEx
zuEl5/NId3NDae9lz6DNT801iyVOKwkY8gvI9RrLPTFqsMdJaI3G/ok++jZS85c1abyyCuSY
uQBqbSJPMgSnO9O6tCOh2hC7p/4wfKmNgxUz5GAcQ/35GEC3O8AAsZQkP5QDtETTQSKe8QIP
8AIBBgJMBU9UD/0ec+7lGLCr/ja87O61EjrTdE0zN1kjNnLywP1ZgsDuQLKDAVXYHGQesdSS
DOoZuGd5RV9tNSun/rR/cY+5Lqo54o0qmBGlRdsgbBzuZqNQsePx73YCtTvJO+7LzCN+QttR
r/4YMuZZ/Lf94XNBheJ2Ow3e4AW7dtuFvlJoOSAJ4QTY1+bGv+SkayHnZBbY+vII3XUKN6o0
00RRq7BDTpQzUZPx19IzX3app/dkCQJN/dTKgC/sy3Z5AOZd/tDjV7kWE5UGMn1FInaYmt8o
k8hoCerGcid+OgGwwv6YTJ3H18Ln2njw2QRTZI0xztfO9LRvCH7vsoK69uP/ZfQN65ilToJY
/r6+ZOH3uypUsj9uvzuJRw0CdVv8Vt8OrVmQDYRWDoY1QEck24UKj86knFz/eqK6sVs66/gP
j+uwjY4wwYUGE5PvHyPJECj5xklLe6NqhCO35S8qcwbnE53G5qoxaBKmqdLSTNJAeudFrQh/
/lEc75RihrfagAd8HIlpDqRpxc3w+bKwAU1SWDGwykoHTuWTGna8p7onTTXQqNmsdInb/oRf
xtxynvzd0qNjYNbc5sDk/tFV/GdYqFvUN+NFLiA9BzXnEENkRsMLjQ2Id+nq9BGvT3Zi41F1
3Mub0yGdNRw7peBqjTLQbbEzijBn3e9Qsi1A3GYC92F5jeopkSlEbiiwetAe+X34J1If25Bh
++RFdWipZqCWFTmHPKQKG/pnIdCAA60AP8z0W9sv3li2dnwHvD8YePwwYihcgyhWtIpa/pkE
L5Vtfiz3/AFUor+54sBovI23NNXNqWvCKHUEDmMHOv4o5iPM/EM9q+ZmDnQkpZ1/94kCZqXf
T4Vw6arUkmAiLmK/e9/Lts7JV6uTM8fuhHieHFxFMbYQxb/IHORAuEwsszy7HwFM/s/oMZQI
evhbM5zb6zRzsmgwTd9AdSMnJJkz4/WRe8M0UnMJqKMMyB8AAnEUKgdIV/ToHRmEX85C9vn1
ngebWK2BBFCcmsO3y5GT0DX4VGQjnpShaJHl0I22K7qabw5Y7676hCJMUMIIGfcblc+Gb7cP
/rrd0mT6R2rwg17G7Cdody7VtYaSY0jjhRyckj3deyPJLrL+5q/mmGU9uscrr+wSQ+Ip2de1
wACnoGUqPs3v8znt11gr7vPjwS+CTRNdf2otwU8Ik8g1Lj+FYG83YUwkW+NTmNJ0LZlmbMAQ
QJb82tk1NGL31IhamXJ4kDStrngNNUp4ZbP9mgi0d8z3AnZ8Rde42E1mbQWY+P++LzLZN/1+
fR+cBwGGeywnY4Idf5Qxwc8hIt0vEu+M+h1WGDkvPg0Ru7/eIkm0+4dIQZQol3ys1rmtK0rp
k+2GKFV/9sugusrpu1sMy08KKq0L65FY1emEZhGrPbWhSkf2KGEPGYXD6WqSclk/uzujhN6u
i21atNm1IXdggT2maH7tglDzJSnNDeNI/Y/vwJs+PWuwr4YEkUQxQG00zQSHrsJ31/xP2GFN
UthuOKOt2exkbid0ZenTJSD4H2SZHJ9coY619ozqI+oFddJN8NUtCdaSXdKrFmBwMGdTg95K
kOQxynTT/N8hrrHNAdjXaSBenQ0W0A9qIFsGj3SImjqs5FO7Ioeg8H+ggZUAwAq7ppZERJ4j
eB8RsGx1bdwOybOjUHPGOVJR9x/PDF5XVCV3uNwcJlukRTDy1Scb1kYHbDyLq5jmfa9ApLNy
Xj/yWZkQXhCLH2fzEhOfMbovExqHr6ottaiGl8HzPUVpcwACSLbI6Iuk59WS4adaepfL42H6
DuXFY1HPqJpijzU0n2w4o+VFBWTPgXpgkd5U/j8deelcxyap+4sKymuHqhVvx0mJKtpUrvjQ
Qkga8tTQpHkgerF+8wTLsuUh4/14YQDE51CEcKmgEgiXow8z9iRFI8MzHApuQZXLdra3SH3X
Vk6eOjShiwTtAhKo+I+kFudw4nriouIw7FKsxAqlKOpUDOTR23PZwfBChRavP81vN32102zg
H73bZcaGXVHuczOTwiiLDqipkN0o3f9AB8K29glxCr4/+zf70NMTxUuCtk1DhBTXtuxfv4HF
DwwZ3r7u6Hfr3A+btgDw1xPdQIVeOyBJkW4EDntCvPF40R46FAPmGZB+IbVn9uQkZmFzYT3N
K2LCHduHW0jVHnvontpwn9r/Tkrl/1vnie0FjPUQTIW9/Gkof3hkVtTIFQHAyKzR0n1HM6FQ
5OGzWElMmGH9aPqTCxHk1Ojw1G2qLJRRMgFpsnxWnWdwKlXRR6fBtywCMztzrUifaT+Z1UbA
pSVIe+0Dp1klYF6yapKyeq8y3w4AORzWPGJBxoLsA1mWwyx/Kk7H2oOcrgk2gbBJH+yReiFU
4zt1CzRd567LvLKrqTXshnYYIlZ/n0KPI/4dZi5+YEyDn39fBUHqkqq1g6DT/kebWVwlDnQ/
uYg8Y9dNi/5YPoxH0XMowvv2yKTlNI+iQ1IBkqdEyws8InalDVaTnNS8X0UfxOPbsJOzYPr6
3lkbrbrJXgUvIumDQFF8IHF4HoQkMZ8PDRDwpXpZGAKhUbophqvkUBtRowtQJzn8SevCZlB+
6Dn4g2a4U8LXTZbzN2RaPa9jvMTemvrhynU9Lsh1JbnYCgZnWu4Qm9imnN7Z9SJOCc/5BeoE
V7dsA9/+w83u9fFIGsRMMedTx38/MVx1yC/lqzr+MhtMS2/a7G5ygCsjBSp6vOSyi9nSls3d
gA+2kFpLwN14wCiKXIgfixfggtQjei9sxlPy0WqQ6RR/jpu9FotpzwaHbH94xSR+AwDUtg3w
EpLNARM+e0nntTP/Rd/39Y+opLFswIj5Tfrx3DxguEn7QjRHyzPsfAMA19beDAaKmB3iSjK7
TqfKi/TyRsMjO8QMbMH1M8tyVF/5h1M/zOrjvg3xC96PumWoC18DZe+y39epz4PSY24NSK8V
blTgaTtnfMwGACTYD3pAdK9WtF1CPhqNR/vYIgF6aw4mj4VnVczs7etMizUCsKS5D0yWQjOu
bVzlElCNQsOU+vYDsWF+SYjMmu4gPDnpmohbUDYvxZw+t5tWnYv+DGemOVsHY2iDCUX6y0qF
7tNvEoH6i2rdXJ9MB9LCMi5zNXRlnpI7AnfKjicNokdJrosJPbhuXDZrVLedMzSp/YAgszSq
W0+MIYypu0VsvAtzl+7sgdEFYs7RgQq3tySxQ2999ymKCs2+70d9/U88rrXHd+1Rw4f3PNNi
57IP3oZ6YUWo6JVGG+u6stZ5E4Ns9KMJ1aUjAXqFXHo4Mi/c3TpfUoENL8xgJWnszkW1lrL8
QqI5u4pgsks3buxjqM0uCTRR5KZcJRGq9MeVDEuMvK8Bz1kmehQn7aDDtZnPamMqebGwEeDD
tH7UgR0umPTG5v2+aMeRGPakiKz/v8bIZCB/9TiUTh7glfCUmzrUN+Jw3JfERWbaTwQCiFvD
8ztxlJwtRzplp7XS9Z97i6j8oSRHZUlhT/C2DV0wcnQXjUo1DBuTB980cgSo+b4KC6is5M2L
6s0yd0X8f0RrljFod1hgA81ywN/9llJOWxogdsIZyLEf6j770mX4lwy6jgH8m1rBlfThcXja
lv0hYxAQh0jZ8XXxuF+df7AkC8goGfQWIq4Ild2o5PctymLgPP4jIbPCb7Vz5ASwoKUowp4T
0hKLYEDu/68a5IrubC0vxcfIPP6db16aftEAbm8zr/MM4WsaoQe3U5KClakACeA/spnskcp+
VidkoGHthw+vaxlq/V8kIADf+/DnqOlrDaagh7AbJ7VEJ0CO2KDMDQJ7qPAxCbi4YJVHpcWD
obpBjiqDFXZ6j6/sd2ecz8O3dnNpKdCZyFNKU300f8LEyVTfJma5DlZlrxtibSDnXoHwVaRq
ga714+QEOp+N0QrrM7Xdco3sfP2V3OcEJmUimbCuwZHL5xK25H69FVzIpqERbcqDRaenBsui
tMBnIvpAtfeoJZDV3v4w3BIrnmqNmLfNAKH4gvdejE8WKerjRxBbh+KnzHuvF7s8Ns9DaTQ0
WALQRkTE4VHS8gOdUxwfU7y4zgK2Xkj/kIb7b1Az5t9wfdv9GJEnvXaKaRiyYCR3on1p21fJ
BtR2uQPSHWY7cuyPf56/pYV9n9cFTWVqjqYIY8hIO7ultBNri88LfGIplhOCxELmKV2Iv5G8
8zrWwbdqa6wXXMx+Wjc6cTVLi2V1/XwaUFtml94q+Ymrss6XgLQerRPHL/ISoXNZeDJOR6Nj
BkpWSMUnTiHyjQKH80XO31vJG+ug8hfOjpCHAa9GTV9a3LOPSWQQ1FNv4B89puI+lnZdNcHZ
Z1ndHS/JwFC81MKxvVAXUjzqgxw3prW+VpLi6MPcQ8ciq/esduCEVLLjNKt6pfD9RtvYtSbm
/j6mLYlX9KfPF5P4gG4xsPfcjP4CX5qO5Jkh+t7MB6yz/AfDPtyegxLXNDzwv2EkfEO8sf/M
m63R6AIONcmgKy0XuyDanPXa2/Y0EuwEQi6wu44P6+aqNMtb0D3gD2UHgwGaWarDGGBBzNpo
3PlRjAa9qMuJiKxcJt+jJOMv2RRY8DMQRTsRhiCN07MuD47I60cKlqpz8ig+q4AQQgRrvS5V
SoiXApu5zhZJnLD3cFkbbLcxHffLhAS/q/VI+24LfMM/iaNt6DP+7yV75KZpAkDDnsZ0MO1K
xUxJSf8E02GEkn1cB68ttkDnzzvGE6ik5K0UexW57/QMIfmwTFeQ7ccuD/tVPLkvix8mSM8i
YJorSKFVrcoCue6SitrLLOKBLHyUZWFzDImzALKjzAN08sriQDJ+x+iJBq5Wm3UtskaQM4zZ
nRVFryKPz4TT4LoMbu0AaOuLCLhSj9QBK0X00HM0mDHOmrxwBwfvMy4VtTH/MU/rqdIeW+Un
qjz2xqx+fzkvx552zjReZTsojNASzv0aUjr9AzdSG+94MZJKa9i9RRFccufWk0ofT3t6qfsM
7gTZB4iDB5DHPkMxV0ewBlATyFuXjfB2x2IROulMffO8+0DNMBvp943VHsOAZsICIFl4sItP
K8Cxe8Hure9G5et1v59n2DxoVJhn0ARvCMwqFn+cVGf5rnwzileTSz6SJfm4L1AOmJo3SPAB
/UApG4O5zMioESpg90i++aNrC9q3qoyIWc0GgPzVmWkcuKu0xadMrle0Vn+ovfKxjqOKGpjH
ER8ob6LlyqscTrE7QbNXDrecfE8Uf9L/XD5jhk1bti/ka9MKbO8w84phxhPlXqDjhTtcoO6D
N+tMoLtiCQe6EBot+8NQHdBjHTPmhtpnoYr17jEMi8WO2enpKgrpSYkBTfEi+nw1fl5Lblor
JQzRiD7ZuKv/P9/6T68ugSMpqBi+QQ2GGTOEtoFxxzli+kS+IPCj5/XW0XIOqLofaP2cw0+h
VG1HiKt9jz1rQU9onNjD/U5LNTL97+9ZEhYhPNeuoc45Bv9q7KDFIzk391EMokmolwpOkRmb
QeSG2EVzrjf/irtRnw1otHDn9UClU3kjI+CuoQCzH++G0lFxHiDiinBox2YPSVSpHSwzIA0z
yAXlTV+HPRY1CSpnNDuUQvBFHpEDtHNO7RF/mt/Y87d1cBIgBcAeQCPy65bGYfAmmXiAnnka
ZF8sSwH4fk9He4UY4IjXoBXTKpApOVgaapHL2JRHbko0rQJq2vrJkapGj/ORgzYyduAs4l5M
Yb2OV3LYtzzi/jTrexlVQ0kSHqTuHb8te6YuWQmErAdt4oCxJxtsdb64UjQrt/zylo1tqiRj
JE6cYGftLi8ylJ+xPDzKY2mvUMKKYUI92mR7nqqnKEY84e90utuoIaXe08eEcYt4znH17WCl
SpUA4gLYhlLGjDbboU1FXxSpKwVS0Qctb3vp3TnfFfHPjXM2rzVE6hcINh5BBqhm3tOR4Ya4
kOPJSXIuzqqXPshh6x50bs6fijaXo+LPeb6xqFyDkOWjqgneE+R3z+8vzPEmKS6ZCn/GlA/u
3KPPsRAGMdcnJmwgRvdock8cIhk/qllXEVtE5Pk2vJawV9BwEPXaVvrqbrRa06ylp7IoYziH
bhfGPD1LZ6e/gILuy7MgU2AEckZBVMC33kAgqvtKV4oVpAbglOiIVYJfd+ZDW0CVjCTP/k5k
KHxD6a0dTuhOREtM4i2W0OX0rzgskyxSdAZfR1xIpXq5pjmmCSdZK8xkok3FXzexS57zsSt1
ipvZ+jK8gZpSEuN1SaHOJYzQmyn+AcvnCXOq7NOKoey3KIpMyIJpbp7adVguGNDara5tCPC0
9SfTWQt0zgVcLlcDAGh9YkeJfVnKj5jIygoo1OTkkxJ+h0ruGPXrNvGWest/Xj1/lh28d7BY
sDb881dF4xfXH8jy9WG1A1N7nkfzwTeviTtPwWzbNhkfzy91GB+uBEP3HXhClVjqIphXjWrD
QjT8q/Yco6XdtcEBRW1Ta6bouTkrqnxjY8HzG0sdxaThDP5XgpxIzlVgrIuOyVjyAXcp5Ftw
HuzOtQtKdyPG5r+Lf13N6jfDh5jCKpd9uaAHQfUxjTwS2kuVfdZ9BCEl6cf6CdlwlUhq0sE+
jrsOR8DB5SjlOXrdiJyS6vkRwYWXBEeq3mCaVhB4UbAIReelPYiL5t6wZZYSWy3YZ2QF1gih
ALO1N/91zQSUVzHr3qy5e59ORRl+Lo17M0kpHZXBAnB4+waZoQVQKLfHLIoM/PquOwVQMSsw
pDoKbFJinqLCE5Avouo1Yv9LABnBZV3lDa7fnEsTmPBAb867pP0bPLPEcoPfQ9wvOdMDwPlk
4ggoLbVry9XN11WvW4fT+QSVplBYhgI3kXKmFHapx7rA84fE78D/GlVCywY8WhDYKvBgszJk
OLdlypjk6lcEfazJNAIYnyNDQfUBCqesiD71VSqLkDL0a4ldR0xrn1eyNHxn7fL5tpZQ+jiJ
WDrduMpFl2VHiAj7kMUDLzOwcOesrxTRobrnQkyuMhBwl7Kiw1V3fIVsNh3stCIGDetwPZ8D
QB2F08m4kPfEnOImWO7yTz0xmR2TSBsE5a+6Z578dvxf8WSo6X4PVdIVujafmtfLBaQohbT1
EQDGep9BYhAWcEAuorBhpEoj9Je7xw10BXqXHgY9xYd0ypLsTZi3yo86pdLCkO+IZ5BhOqtO
jxYptftXGDzeCjhhqiY8JElc3aQ/SexLBjmGDGF+H4eBBrgPbVU9e698ijmuXNrM0YUonMsu
7KpgF5vhXX+FN+uvV66UjZIX9q2zr4rHbdMC0NBGPCTzDiUw6Xl2i5Y07slBX71Wou2Lbqsq
8UM5LMjIrfTPkYZ/YVPoYrpIAL8iuCChKUUXArLO0vpJdOPIhs4e+ENL6V3sZJyRmaL1nLVf
KlnjOqZKSmJoqap2NV5ycvjbqwY+B7jW7q4IJLakSKLlDGAVwbvjuMiaoPB/pgA6OAjX4QQw
Q937LRH8QDmlwRSHJJVaimCjbzlLtz2JgBalUAYGy8wbqu5lTB6Arsqx2AZhKZ4C7F8jkEz5
nNLu4zjNB4bc62+ubW05VX4rrFXyqwJp541ewUxiek2uxuF/Vi8VKpGnsYheveiOfsm0HVYv
B6JwynpGC7CEmJKjPV7fK6Q7iT8tYlxao2Tm19OwL2yDAk6pF9cDkOzP2/+DZ4GX3YUUvDHx
alh4slsvomG+SJUrDLntLrDL5jT600k3PiUtcqJBUjonGRnIYRqOPYz4VNn0kTN7ZmIOT9I8
JdgH7YujuhEusmledsFwmwOCJ/R49CY1sWV6TlgVAFtUOy/H585vMtqjZJ9h1rtZjcGJysWu
QB4nw4r4/WsD9jb0gTwFzm4VPOoVwNWVV04BFw3YNFyyd2h8STIsZ4jK8oLK4T4vncE/GkQZ
6Zfj0jPnhaLBpE7b3l+8W6FwuMFKTBXpV99e2QbXYKabBjZOs5VIennjSOeNPUatvAoV4dmt
mwXZbD9acoIy7mEB3WKLmQzKK9y3XrqamICUSyfMtLrL9bBqsgTClZhV57Jqn7iR7X/DMnXM
eX1qeVb5xy+adUIfgpHJODbueFkvHsHWnaM2cMZzuVouyXG8J5Q3I/McU3akiYA+HrEBSF7t
BS8kWugwve/z8DUWmMFT4I5GGVhdJw6eNQd3Y7hw+3H1Rl1Ra9W83kIfpuJIL+CciY6egX0O
atU/Csgc056TCjuVjQ3LCum22Cdo3fZSBJUbjSJiC1fD+NwXpO7fS9rTIaAnqeWCz1IFTUZn
vF5BBun/lQ1obZRJLXZpX3uSSXkHCWu02aicxoTJ2ss99IIYOLpjWIZMLKEbOQbJg6xHWLvA
OAqJupp2GpsE6hCtSxRWhqJwBCqV04OXFcVy0tpsCFMtHVPkv2Zwak9gU85kQWO5Cs8vypgi
Q3XfXuBDekmtLwd7cNboKyD6YuOEqZolYeGsLGnufiMTl6TIqkyIXbBA2Qbm+SS9Q0HcVtCw
USkvsGNywkSWlguCm9wk2Dnc0r58NL6kH71WLLjOD+pt8C0Ve1Ec70jFTnTbWbAZF0aRML5O
Rv901kmdgk9NGk54ElE/d471kg/2AWTSJva/FyZaCzMoAAzwWu90T0SQEVg0ybxFJROnpZ26
OQ3jMLtdmW/OzHjWHyPJjvvvIJLwDJNx/I/EBuSz/zVPzFkAxA6n6ovQOwatZvBonVf1wNA5
LnnfEqKH/PTbp+fxAJedJeu62eE1k0BRTVM62dZ7aENA/rlrcHYbC6kLDBr3ImPT//s06Ec9
UEsDBAoAAQAIAKBLuDBofGILFwAAAAYAAAALAAAAaG52dXFpai5zeXNe+S7ZHS3IVgIXRlQc
kbWQmGpReRexNlBLAQIUAAoAAQAIAKBLuDBip/GblWoAADNmAAAJAAAAAAAAAAEAIAAAAAAA
AABvbnVqeC5leGVQSwECFAAKAAEACACgS7gwaHxiCxcAAAAGAAAACwAAAAAAAAABACAAAAC8
agAAaG52dXFpai5zeXNQSwUGAAAAAAIAAgBwAAAA/GoAAAAA

----------yynbceeefnexpyuconyr--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4MAcm3u087279; Sat, 22 May 2004 03:38:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4MAcmbu087278; Sat, 22 May 2004 03:38:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rmk027.org ([203.199.214.66]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4MAcjxe087212 for <[e-mail]>; Sat, 22 May 2004 03:38:47 -0700 (PDT) (envelope-from [e-mail])
Date: Sat, 22 May 2004 15:59:07 +0530
To: "Ietf-pkix" <[e-mail]>
From: "Wpolk" <[e-mail]>
Subject: Forum notify
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------uplrwiyrlmkhhkibqnpu"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----------uplrwiyrlmkhhkibqnpu
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
 

<br>
</body></html>

----------uplrwiyrlmkhhkibqnpu
Content-Type: application/octet-stream; name="Information.vbs"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Information.vbs"



----------uplrwiyrlmkhhkibqnpu--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4LJtbIB048836; Fri, 21 May 2004 12:55:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4LJtbfj048833; Fri, 21 May 2004 12:55:37 -0700 (PDT)
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.9) with ESMTP id i4LJtZjH048820 for <[e-mail]>; Fri, 21 May 2004 12:55:36 -0700 (PDT) (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 PAA25727; Fri, 21 May 2004 15:55:36 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-certstore-http-07.txt
Date: Fri, 21 May 2004 15:55:36 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

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

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

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


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

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


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

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

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

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

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

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-certstore-http-07.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.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4ICNPPo046264; Tue, 18 May 2004 05:23:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4ICNPfd046263; Tue, 18 May 2004 05:23:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imr6.us.db.com (imr6.us.db.com [160.83.65.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4ICNO2b046257 for <[e-mail]>; Tue, 18 May 2004 05:23:25 -0700 (PDT) (envelope-from [e-mail])
Received: from sdbo1005.db.com by imr6.us.db.com  id i4ICN8lF024779; Tue, 18 May 2004 08:23:09 -0400 (EDT)
To: [e-mail]
Cc: [e-mail], [e-mail], "Miguel Rodriguez" <[e-mail]>
Subject: Re: Signature in OCSP Request
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
Message-ID: <[e-mail]>
From: "Frank Balluffi" <[e-mail]>
Date: Tue, 18 May 2004 08:23:07 -0400
X-MIMETrack: Serialize by Router on sdbo1005/DBNA/DeuBaInt/DeuBa(5012HF330 | August 01, 2003) at 05/18/2004 08:23:09 AM, Serialize complete at 05/18/2004 08:23:09 AM
Content-Type: multipart/alternative; boundary="=_alternative 004408FB85256E98_="
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multipart message in MIME format.
--=_alternative 004408FB85256E98_=
Content-Type: text/plain; charset="us-ascii"

Yasir,

As I recall, it is necessary to reverse the bytes of a signature generated 
by CAPI.

Frank





"Yasir Khan" <[e-mail]>
Sent by: [e-mail]
05/18/2004 06:07 AM

 
        To:     "Miguel Rodriguez" <[e-mail]>, <[e-mail]>
        cc:     <[e-mail]>
        Subject:        Re: Signature in OCSP Request



Hello 
 
 I have attached the TBSData.req  and signed requests after siging with 
CAPI and another toolkit. The file  toolkitSignedRequest.req is a signed 
request file that was signed with a toolkit  and OCSP responders accept 
the request. Wheras capiDirRequest.req is a file  in which signatures have 
been calculated from CAPI and attached to request. But  OCSP servers are 
unable to verify the signatures of the request. The last file 
capipkcsRequest.req is a request in which we made a PKCS#7 object of TBS 
Data  using CAPI and obtained the signatures from PKCS#7 and attached to 
request.
 
We are unable to contrust  a correct signed request using CAPI. The 
signatures in case of CAPI are  different but we dont know why they are 
different?
 
Any help will be highly  appreciated.
 
Regards 
----- Original Message ----- 
From:  Miguel  Rodriguez 
To: 'Yasir Khan' ; [e-mail] 
Sent: Tuesday, May 18, 2004 5:41 AM
Subject: RE: Signature in OCSP  Request

You  may need to reverse the signature so it can be verified by the OCSP 
server.  The signature should be computed over the tbsRequest structure. 
Regarding the  algorithms RFC 2560 is nto specific when it comes to signed 
requests, we need  further clarification of this point.
 
Miguel A Rodriguez
SeguriData
Mexico
-----Original Message-----
From: [e-mail]  [mailto:[e-mail]] On Behalf Of Yasir  Khan
Sent: Monday, May 17, 2004 9:01 AM
To:  [e-mail]
Cc: [e-mail]
Subject:  Signature in OCSP Request




Hello
 
I have a question about the signature field in OCSP request. What  exactly 
should it contain and what 
algorithms can be used for OCSP  request signing? 
 
When i create a signature using MS CAPI, OCSP reponders are unable to 
verify the signatures whereas we
can verify it using CAPI. What data do  we set in signature field exactly?
 
Regards,
 
Yasir
 
 






The following file(s) have been deleted by: Frank Balluffi on 5/18/2004 
8:20:52 AM

capiDirRequest.req
capipkcsRequest.req
TBSData.req
toolKitSignedRequest.req
smime.p7s
ATTOZ6J1
ATT0LW3D
ATTMN5LQ
ATTYKNMP
smime.p7s



--=_alternative 004408FB85256E98_=
Content-Type: text/html; charset="us-ascii"


<br><font size=2><tt>Yasir,</tt></font>
<br>
<br><font size=2><tt>As I recall, it is necessary to reverse the bytes of a signature generated by CAPI.</tt></font>
<br>
<br><font size=2><tt>Frank</tt></font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>&quot;Yasir Khan&quot; &lt;[e-mail]&gt;</b></font>
<br><font size=1 face="sans-serif">Sent by: [e-mail]</font>
<p><font size=1 face="sans-serif">05/18/2004 06:07 AM</font>
<br>
<td><font size=1 face="Arial">&nbsp; &nbsp; &nbsp; &nbsp; </font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; To: &nbsp; &nbsp; &nbsp; &nbsp;&quot;Miguel Rodriguez&quot; &lt;[e-mail]&gt;, &lt;[e-mail]&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; cc: &nbsp; &nbsp; &nbsp; &nbsp;&lt;[e-mail]&gt;</font>
<br><font size=1 face="sans-serif">&nbsp; &nbsp; &nbsp; &nbsp; Subject: &nbsp; &nbsp; &nbsp; &nbsp;Re: Signature in OCSP Request</font></table>
<br>
<br>
<br>
<br><font size=2>Hello </font>
<br><font size=3>&nbsp;</font>
<br><font size=2>&nbsp;I have attached the TBSData.req &nbsp;and signed requests after siging with CAPI and another toolkit. The file &nbsp;toolkitSignedRequest.req is a signed request file that was signed with a toolkit &nbsp;and OCSP responders accept the request. Wheras capiDirRequest.req&nbsp;is a file &nbsp;in which signatures have been calculated from CAPI and attached to request. But &nbsp;OCSP servers are unable to verify the signatures of the request. The last file &nbsp;capipkcsRequest.req is a request in which we made a PKCS#7 object of TBS Data &nbsp;using CAPI and obtained the signatures from PKCS#7 and attached to &nbsp;request.</font>
<br><font size=3>&nbsp;</font>
<br><font size=2>We are unable to contrust &nbsp;a&nbsp;correct signed request using CAPI. The signatures in case of CAPI are &nbsp;different but we&nbsp;dont&nbsp;know why they are different?</font>
<br><font size=3>&nbsp;</font>
<br><font size=2>Any help will be highly &nbsp;appreciated.</font>
<br><font size=3>&nbsp;</font>
<br><font size=2>Regards</font><font size=3>&nbsp;</font>
<br><font size=3>----- Original Message ----- </font>
<br><font size=3><b>From:</b> &nbsp;</font><a href=mailto:[e-mail]><font size=3 color=blue><u>Miguel &nbsp;Rodriguez</u></font></a><font size=3> </font>
<br><font size=3><b>To:</b> </font><a href=mailto:[e-mail]><font size=3 color=blue><u>'Yasir Khan'</u></font></a><font size=3> ; </font><a href="mailto:[e-mail]"><font size=3 color=blue><u>[e-mail]</u></font></a><font size=3> &nbsp;</font>
<br><font size=3><b>Sent:</b> Tuesday, May 18, 2004 5:41 AM</font>
<br><font size=3><b>Subject:</b> RE: Signature in OCSP &nbsp;Request</font>
<br>
<br><font size=2>You &nbsp;may need to reverse the signature so it can be verified by the OCSP server. &nbsp;The signature should be computed over the tbsRequest structure. Regarding the &nbsp;algorithms RFC 2560 is nto specific when it comes to signed requests, we need &nbsp;further clarification of this point.</font>
<br><font size=3>&nbsp;</font>
<br><font size=2>Miguel A Rodriguez</font>
<br><font size=2>SeguriData</font>
<br><font size=2>Mexico</font>
<br><font size=2>-----Original Message-----</font>
<br><font size=2><b>From:</b> </font><a href="mailto:[e-mail]"><font size=2 color=blue><u>[e-mail]</u></font></a><font size=2> &nbsp;[mailto:[e-mail]] <b>On Behalf Of </b>Yasir &nbsp;Khan</font>
<br><font size=2><b>Sent:</b> Monday, May 17, 2004 9:01 AM</font>
<br><font size=2><b>To:</b> &nbsp;[e-mail]</font>
<br><font size=2><b>Cc:</b> [e-mail]</font>
<br><font size=2><b>Subject:</b> &nbsp;Signature in OCSP Request</font>
<br>
<br>
<br>
<br>
<br><font size=2>Hello</font>
<br><font size=2>&nbsp;</font>
<br><font size=2>I have a question about the signature field in OCSP request. What &nbsp;exactly should it contain and what </font>
<br><font size=2>algorithms can be used for OCSP &nbsp;request signing? </font>
<br><font size=2>&nbsp;</font>
<br><font size=2>When i create a signature using MS CAPI, OCSP reponders are unable to &nbsp;verify the signatures whereas we</font>
<br><font size=2>can verify it using CAPI. What data do &nbsp;we set in signature field exactly?</font>
<br><font size=2>&nbsp;</font>
<br><font size=2>Regards,</font>
<br><font size=2>&nbsp;</font>
<br><font size=2>Yasir</font>
<br><font size=2>&nbsp;</font>
<br><font size=3>&nbsp;</font>
<br>
<br>
<br>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">The following file(s) have been deleted by: Frank Balluffi on 5/18/2004 8:20:52 AM</font>
<br>
<br><font size=2 face="sans-serif">capiDirRequest.req</font>
<br><font size=2 face="sans-serif">capipkcsRequest.req</font>
<br><font size=2 face="sans-serif">TBSData.req</font>
<br><font size=2 face="sans-serif">toolKitSignedRequest.req</font>
<br><font size=2 face="sans-serif">smime.p7s</font>
<br><font size=2 face="sans-serif">ATTOZ6J1</font>
<br><font size=2 face="sans-serif">ATT0LW3D</font>
<br><font size=2 face="sans-serif">ATTMN5LQ</font>
<br><font size=2 face="sans-serif">ATTYKNMP</font>
<br><font size=2 face="sans-serif">smime.p7s</font>
<br>
<br>
<br>
--=_alternative 004408FB85256E98_=--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IA5fCE030648; Tue, 18 May 2004 03:05:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4IA5fNr030647; Tue, 18 May 2004 03:05:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk (ns3.worldcall.net.pk [203.81.192.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4IA5cs7030635 for <[e-mail]>; Tue, 18 May 2004 03:05:39 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertia3 ([203.81.198.252]) by ns3.worldcall.net.pk (8.12.11/8.12.11) with SMTP id i4IA1d5U002550; Tue, 18 May 2004 16:01:42 +0600 (PKST)
Message-ID: <008d01c43cc0$0e860cb0$[e-mail]>
From: "Yasir Khan" <[e-mail]>
To: "Miguel Rodriguez" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <002601c43c70$ddb9edd0$[e-mail]>
Subject: Re: Signature in OCSP Request
Date: Tue, 18 May 2004 15:07:53 +0500
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="----=_NextPart_000_0086_01C43CE9.E957D2F0"; protocol="application/x-pkcs7-signature"; micalg=SHA1
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0086_01C43CE9.E957D2F0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_001_0087_01C43CE9.E957D2F0"


------=_NextPart_001_0087_01C43CE9.E957D2F0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_002_0088_01C43CE9.E957D2F0"


------=_NextPart_002_0088_01C43CE9.E957D2F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

MessageHello=20

 I have attached the TBSData.req and signed requests after siging with =
CAPI and another toolkit. The file toolkitSignedRequest.req is a signed =
request file that was signed with a toolkit and OCSP responders accept =
the request. Wheras capiDirRequest.req is a file in which signatures =
have been calculated from CAPI and attached to request. But OCSP servers =
are unable to verify the signatures of the request. The last file =
capipkcsRequest.req is a request in which we made a PKCS#7 object of TBS =
Data using CAPI and obtained the signatures from PKCS#7 and attached to =
request.

We are unable to contrust a correct signed request using CAPI. The =
signatures in case of CAPI are different but we dont know why they are =
different?

Any help will be highly appreciated.

Regards=20
  ----- Original Message -----=20
  From: Miguel Rodriguez=20
  To: 'Yasir Khan' ; [e-mail]=20
  Sent: Tuesday, May 18, 2004 5:41 AM
  Subject: RE: Signature in OCSP Request


  You may need to reverse the signature so it can be verified by the =
OCSP server. The signature should be computed over the tbsRequest =
structure. Regarding the algorithms RFC 2560 is nto specific when it =
comes to signed requests, we need further clarification of this point.

  Miguel A Rodriguez
  SeguriData
  Mexico
    -----Original Message-----
    From: [e-mail] =
[mailto:[e-mail]] On Behalf Of Yasir Khan
    Sent: Monday, May 17, 2004 9:01 AM
    To: [e-mail]
    Cc: [e-mail]
    Subject: Signature in OCSP Request



    Hello

    I have a question about the signature field in OCSP request. What =
exactly should it contain and what=20
    algorithms can be used for OCSP request signing?=20

    When i create a signature using MS CAPI, OCSP reponders are unable =
to verify the signatures whereas we
    can verify it using CAPI. What data do we set in signature field =
exactly?

    Regards,

    Yasir



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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial color=3D#800080 size=3D2>Hello </FONT></DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2>&nbsp;I have attached =
the TBSData.req=20
and signed requests after siging with CAPI and another toolkit. The file =

toolkitSignedRequest.req is a signed request file that was signed with a =
toolkit=20
and OCSP responders accept the request. Wheras =
capiDirRequest.req&nbsp;is a file=20
in which signatures have been calculated from CAPI and attached to =
request. But=20
OCSP servers are unable to verify the signatures of the request. The =
last file=20
capipkcsRequest.req is a request in which we made a PKCS#7 object of TBS =
Data=20
using CAPI and obtained the signatures from PKCS#7 and attached to=20
request.</FONT></DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2>We are unable to =
contrust=20
a&nbsp;correct signed request using CAPI. The signatures in case of CAPI =
are=20
different but we&nbsp;dont&nbsp;know why they are =
different?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2>Any help will be highly =

appreciated.</FONT></DIV>
<DIV><FONT face=3DArial color=3D#800080 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#800080 =
size=3D2>Regards</FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #800080 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=[e-mail] =
href=3D"mailto:[e-mail]">Miguel=20
  Rodriguez</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=[e-mail]=20
  href=3D"mailto:[e-mail]">'Yasir Khan'</A> ; <A=20
  title=[e-mail] =
href=3D"mailto:[e-mail]">[e-mail]</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, May 18, 2004 =
5:41 AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Signature in OCSP=20
  Request</DIV>
  <DIV><BR></DIV>
  <DIV><SPAN class=3D610453200-18052004><FONT face=3DArial =
color=3D#0000ff size=3D2>You=20
  may need to reverse the signature so it can be verified by the OCSP =
server.=20
  The signature should be computed over the tbsRequest structure. =
Regarding the=20
  algorithms RFC 2560 is nto specific when it comes to signed requests, =
we need=20
  further clarification of this point.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D610453200-18052004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D610453200-18052004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Miguel A Rodriguez</FONT></SPAN></DIV>
  <DIV><SPAN class=3D610453200-18052004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>SeguriData</FONT></SPAN></DIV>
  <DIV><SPAN class=3D610453200-18052004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Mexico</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> <A =

    =
href=3D"mailto:[e-mail]">[e-mail]=
</A>=20
    [mailto:[e-mail]] <B>On Behalf Of </B>Yasir=20
    Khan<BR><B>Sent:</B> Monday, May 17, 2004 9:01 AM<BR><B>To:</B>=20
    [e-mail]<BR><B>Cc:</B> =
[e-mail]<BR><B>Subject:</B>=20
    Signature in OCSP Request<BR><BR></FONT></DIV><FONT face=3DArial =
color=3D#800080=20
    size=3D2>
    <DIV><BR>Hello</DIV>
    <DIV>&nbsp;</DIV>
    <DIV>I have a question about the signature field in OCSP request. =
What=20
    exactly should it contain and what <BR>algorithms can be used for =
OCSP=20
    request signing? </DIV>
    <DIV>&nbsp;</DIV>
    <DIV>When i create a signature using MS CAPI, OCSP reponders are =
unable to=20
    verify the signatures whereas we<BR>can verify it using CAPI. What =
data do=20
    we set in signature field exactly?</DIV>
    <DIV>&nbsp;</DIV>
    <DIV>Regards,</DIV>
    <DIV>&nbsp;</DIV>
    <DIV>Yasir</DIV>
    <DIV>&nbsp;</DIV>
    <DIV></FONT>&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_002_0088_01C43CE9.E957D2F0--

------=_NextPart_001_0087_01C43CE9.E957D2F0
Content-Type: application/octet-stream;
	name="capiDirRequest.req"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="capiDirRequest.req"

MIIF3zCCAVGgAwIBAKFWpFQwUjELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMQ8wDQYD
VQQLEwZQZW9wbGUxHzAdBgNVBAMTFlRlc3QgQWxpY2UgVGVzdCBMMiBDQTEwgb4wgbswOjAJBgUr
DgMCGgUABBTLMw+MCkY9+joPkAiahqdX8D05sQQUzA35sCUgCTmqS33NavORCcXf/MACAQWgfTB7
MHkGCSsGAQUFBzABBwRsMGowRDELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMQwwCgYD
VQQLEwNTUUExFDASBgNVBAMTC1Rlc3QgTDIgQ0ExMCIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9hc2Nl
cnRpYS01Ojg1ojEwLzAaBgkrBgEFBQcwAQQEDTALBgkrBgEFBQcwAQEwEQYJKwYBBQUHMAECBATU
e8EyoIIEhjCCBIIwDQYJKoZIhvcNAQEFBQADgYEAiYktIgCLJveIHuCtMWfIMMQ6S9cCGF4hxKyG
Enz/eaQX2pY+IatUbA/YXB+2ch+SeP5uMSzjSqnFtBWLua8fUrIwXqvjYBxQprvWrLYP9KJ42Rnb
yuN8wbFmtV/xsXNlB82+JbWncNM77lH0tPJfsC4P6o4f10DNeR0bAo2VbjugggPrMIID5zCCA+Mw
ggNMoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwRDELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2Vy
dGlhMQwwCgYDVQQLEwNTUUExFDASBgNVBAMTC1Rlc3QgTDIgQ0ExMB4XDTAzMDYzMDExNDQ0N1oX
DTE1MDQzMDExNDExN1owUjELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMQ8wDQYDVQQL
EwZQZW9wbGUxHzAdBgNVBAMTFlRlc3QgQWxpY2UgVGVzdCBMMiBDQTEwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBAPZaou86n5IMyaoG+8r8GQgX5TTv7lxbCqxpo2hgE7kxbEm4FEohbFhl0IFJ
qkBkcByYCDGgnFCYOyo5upnyCwfrVAu06k8UqmJj/117Uwy/PmGfOeGzeoJqvI9kORPeGZ6yIsiy
CcjZqAp4/XjP4b5OtgvRN3+8NeNHWtUGUl3XAgMBAAGjggHVMIIB0TAOBgNVHQ8BAf8EBAMCA/gw
DAYDVR0TAQH/BAIwADCB0QYDVR0gBIHJMIHGMIHDBgorBgEEAfxJAQICMIG0MIGxBggrBgEFBQcC
AjCBpBqBoUNlcnRpZmljYXRlcyBpc3N1ZWQgdW5kZXIgdGhpcyBwb2xpY3kgYXJlIHRvIHVuYXV0
aGVudGljYXRlZCBpbmRpdmlkdWFscy4gIFBsZWFzZSBkbyBub3QgdXNlIHN1Y2ggY2VydGlmaWNh
dGVzIGZvciB2YWx1YWJsZSB0cmFuc2FjdGlvbnMuICBOTyBMSUFCSUxJVFkgQUNDRVBURUQuMB0G
A1UdDgQWBBSmXKPcjzYc56fGGrjauEGTY8TBdDBLBgNVHR8ERDBCMECgPqA8hjpsZGFwOi8vYXNj
ZXJ0aWEtNC9jYWNlcnRpZmljYXRlPW5ldywgb3U9dGVzdCwgbz1haXJpdXMuY29tMDAGCCsGAQUF
BwEBBCQwIjAgBggrBgEFBQcwAYYUaHR0cDovL2FzY2VydGlhLTU6ODUwHgYDVR0RBBcwFYETYWxp
Y2VMMkB0ZXN0aW5nLmNvbTAfBgNVHSMEGDAWgBTMDfmwJSAJOapLfc1q85EJxd/8wDANBgkqhkiG
9w0BAQUFAAOBgQCJ+diomsCnaFbr6f7oR6RRc3qGV18bvEGsAwPNmjFFv058IxmtkL/uX1tSJJOZ
6lI1qQAqUNYzrg/g1MBWZ/wxNXMrDFYNdB6W0sgWJcvnzYYwB4oziNx/fKNjBNuwbOcZXUatVUDY
c+8dn3jkLGRuOepReeylW4JRDifSTJRZIA==

------=_NextPart_001_0087_01C43CE9.E957D2F0
Content-Type: application/octet-stream;
	name="capipkcsRequest.req"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="capipkcsRequest.req"

MIIF3zCCAVGgAwIBAKFWpFQwUjELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMQ8wDQYD
VQQLEwZQZW9wbGUxHzAdBgNVBAMTFlRlc3QgQWxpY2UgVGVzdCBMMiBDQTEwgb4wgbswOjAJBgUr
DgMCGgUABBTLMw+MCkY9+joPkAiahqdX8D05sQQUzA35sCUgCTmqS33NavORCcXf/MACAQWgfTB7
MHkGCSsGAQUFBzABBwRsMGowRDELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMQwwCgYD
VQQLEwNTUUExFDASBgNVBAMTC1Rlc3QgTDIgQ0ExMCIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9hc2Nl
cnRpYS01Ojg1ojEwLzAaBgkrBgEFBQcwAQQEDTALBgkrBgEFBQcwAQEwEQYJKwYBBQUHMAECBATU
e8EyoIIEhjCCBIIwDQYJKoZIhvcNAQEFBQADgYEAZMo3KxKFhAjzFWor+wfP0P2TL7RFhGlWTiZP
n6Umq6MBd9Zf4+tTiQ6etxEGpY2g4H6umma/5l1DBb+pd4hqeSyH5sb1ZzkHy8jCB7KuEVipxEZh
LcEDJZXkKGQxdce/gwarX5QGzh5tPXnyEmi6o68ZDtaPVpXYgCKprdaUGs6gggPrMIID5zCCA+Mw
ggNMoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwRDELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2Vy
dGlhMQwwCgYDVQQLEwNTUUExFDASBgNVBAMTC1Rlc3QgTDIgQ0ExMB4XDTAzMDYzMDExNDQ0N1oX
DTE1MDQzMDExNDExN1owUjELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMQ8wDQYDVQQL
EwZQZW9wbGUxHzAdBgNVBAMTFlRlc3QgQWxpY2UgVGVzdCBMMiBDQTEwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBAPZaou86n5IMyaoG+8r8GQgX5TTv7lxbCqxpo2hgE7kxbEm4FEohbFhl0IFJ
qkBkcByYCDGgnFCYOyo5upnyCwfrVAu06k8UqmJj/117Uwy/PmGfOeGzeoJqvI9kORPeGZ6yIsiy
CcjZqAp4/XjP4b5OtgvRN3+8NeNHWtUGUl3XAgMBAAGjggHVMIIB0TAOBgNVHQ8BAf8EBAMCA/gw
DAYDVR0TAQH/BAIwADCB0QYDVR0gBIHJMIHGMIHDBgorBgEEAfxJAQICMIG0MIGxBggrBgEFBQcC
AjCBpBqBoUNlcnRpZmljYXRlcyBpc3N1ZWQgdW5kZXIgdGhpcyBwb2xpY3kgYXJlIHRvIHVuYXV0
aGVudGljYXRlZCBpbmRpdmlkdWFscy4gIFBsZWFzZSBkbyBub3QgdXNlIHN1Y2ggY2VydGlmaWNh
dGVzIGZvciB2YWx1YWJsZSB0cmFuc2FjdGlvbnMuICBOTyBMSUFCSUxJVFkgQUNDRVBURUQuMB0G
A1UdDgQWBBSmXKPcjzYc56fGGrjauEGTY8TBdDBLBgNVHR8ERDBCMECgPqA8hjpsZGFwOi8vYXNj
ZXJ0aWEtNC9jYWNlcnRpZmljYXRlPW5ldywgb3U9dGVzdCwgbz1haXJpdXMuY29tMDAGCCsGAQUF
BwEBBCQwIjAgBggrBgEFBQcwAYYUaHR0cDovL2FzY2VydGlhLTU6ODUwHgYDVR0RBBcwFYETYWxp
Y2VMMkB0ZXN0aW5nLmNvbTAfBgNVHSMEGDAWgBTMDfmwJSAJOapLfc1q85EJxd/8wDANBgkqhkiG
9w0BAQUFAAOBgQCJ+diomsCnaFbr6f7oR6RRc3qGV18bvEGsAwPNmjFFv058IxmtkL/uX1tSJJOZ
6lI1qQAqUNYzrg/g1MBWZ/wxNXMrDFYNdB6W0sgWJcvnzYYwB4oziNx/fKNjBNuwbOcZXUatVUDY
c+8dn3jkLGRuOepReeylW4JRDifSTJRZIA==

------=_NextPart_001_0087_01C43CE9.E957D2F0
Content-Type: application/octet-stream;
	name="TBSData.req"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="TBSData.req"

MIIBUaADAgEAoVakVDBSMQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExDzANBgNVBAsT
BlBlb3BsZTEfMB0GA1UEAxMWVGVzdCBBbGljZSBUZXN0IEwyIENBMTCBvjCBuzA6MAkGBSsOAwIa
BQAEFMszD4wKRj36Og+QCJqGp1fwPTmxBBTMDfmwJSAJOapLfc1q85EJxd/8wAIBBaB9MHsweQYJ
KwYBBQUHMAEHBGwwajBEMQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExDDAKBgNVBAsT
A1NRQTEUMBIGA1UEAxMLVGVzdCBMMiBDQTEwIjAgBggrBgEFBQcwAYYUaHR0cDovL2FzY2VydGlh
LTU6ODWiMTAvMBoGCSsGAQUFBzABBAQNMAsGCSsGAQUFBzABATARBgkrBgEFBQcwAQIEBNR7wTI=

------=_NextPart_001_0087_01C43CE9.E957D2F0
Content-Type: application/octet-stream;
	name="toolKitSignedRequest.req"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="toolKitSignedRequest.req"

MIIF3zCCAVGgAwIBAKFWpFQwUjELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMQ8wDQYD
VQQLEwZQZW9wbGUxHzAdBgNVBAMTFlRlc3QgQWxpY2UgVGVzdCBMMiBDQTEwgb4wgbswOjAJBgUr
DgMCGgUABBTLMw+MCkY9+joPkAiahqdX8D05sQQUzA35sCUgCTmqS33NavORCcXf/MACAQWgfTB7
MHkGCSsGAQUFBzABBwRsMGowRDELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMQwwCgYD
VQQLEwNTUUExFDASBgNVBAMTC1Rlc3QgTDIgQ0ExMCIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9hc2Nl
cnRpYS01Ojg1ojEwLzAaBgkrBgEFBQcwAQQEDTALBgkrBgEFBQcwAQEwEQYJKwYBBQUHMAECBATU
e8EyoIIEhjCCBIIwDQYJKoZIhvcNAQEFBQADgYEAO26VjQIbHXnNQNcfjuoPLrBf8rT0Ue4703Cn
tSW+zQdlc7HxX7VmscF848rbGdl4ovQPtqzWu6ZQHGDjq14wslIfr7mLFbTFqUrjLDFu/niSH3K2
H1zYD2xUqyE+ltoXpHn/fBKGrMQhXhgC10s6xDDIZzGt4B6I9yaLACItiYmgggPrMIID5zCCA+Mw
ggNMoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwRDELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2Vy
dGlhMQwwCgYDVQQLEwNTUUExFDASBgNVBAMTC1Rlc3QgTDIgQ0ExMB4XDTAzMDYzMDExNDQ0N1oX
DTE1MDQzMDExNDExN1owUjELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMQ8wDQYDVQQL
EwZQZW9wbGUxHzAdBgNVBAMTFlRlc3QgQWxpY2UgVGVzdCBMMiBDQTEwgZ8wDQYJKoZIhvcNAQEB
BQADgY0AMIGJAoGBAPZaou86n5IMyaoG+8r8GQgX5TTv7lxbCqxpo2hgE7kxbEm4FEohbFhl0IFJ
qkBkcByYCDGgnFCYOyo5upnyCwfrVAu06k8UqmJj/117Uwy/PmGfOeGzeoJqvI9kORPeGZ6yIsiy
CcjZqAp4/XjP4b5OtgvRN3+8NeNHWtUGUl3XAgMBAAGjggHVMIIB0TAOBgNVHQ8BAf8EBAMCA/gw
DAYDVR0TAQH/BAIwADCB0QYDVR0gBIHJMIHGMIHDBgorBgEEAfxJAQICMIG0MIGxBggrBgEFBQcC
AjCBpBqBoUNlcnRpZmljYXRlcyBpc3N1ZWQgdW5kZXIgdGhpcyBwb2xpY3kgYXJlIHRvIHVuYXV0
aGVudGljYXRlZCBpbmRpdmlkdWFscy4gIFBsZWFzZSBkbyBub3QgdXNlIHN1Y2ggY2VydGlmaWNh
dGVzIGZvciB2YWx1YWJsZSB0cmFuc2FjdGlvbnMuICBOTyBMSUFCSUxJVFkgQUNDRVBURUQuMB0G
A1UdDgQWBBSmXKPcjzYc56fGGrjauEGTY8TBdDBLBgNVHR8ERDBCMECgPqA8hjpsZGFwOi8vYXNj
ZXJ0aWEtNC9jYWNlcnRpZmljYXRlPW5ldywgb3U9dGVzdCwgbz1haXJpdXMuY29tMDAGCCsGAQUF
BwEBBCQwIjAgBggrBgEFBQcwAYYUaHR0cDovL2FzY2VydGlhLTU6ODUwHgYDVR0RBBcwFYETYWxp
Y2VMMkB0ZXN0aW5nLmNvbTAfBgNVHSMEGDAWgBTMDfmwJSAJOapLfc1q85EJxd/8wDANBgkqhkiG
9w0BAQUFAAOBgQCJ+diomsCnaFbr6f7oR6RRc3qGV18bvEGsAwPNmjFFv058IxmtkL/uX1tSJJOZ
6lI1qQAqUNYzrg/g1MBWZ/wxNXMrDFYNdB6W0sgWJcvnzYYwB4oziNx/fKNjBNuwbOcZXUatVUDY
c+8dn3jkLGRuOepReeylW4JRDifSTJRZIA==

------=_NextPart_001_0087_01C43CE9.E957D2F0--

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK3TCCAzEw
ggIZoAMCAQICAQIwDQYJKoZIhvcNAQEFBQAwOzELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2Vy
dGlhMRkwFwYDVQQDExBBc2NlcnRpYSBSb290IENBMB4XDTAzMDMwNDA4MTI1N1oXDTEyMDczMDEw
NDIyOVowYDELMAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMSYwJAYDVQQLEx1DbGFzcyAy
IENlcnRpZmljYXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNQXNjZXJ0aWEgQ0EgMjCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAnRehtg8oWu+jYIkNJVR1ueHs7k8fClUiqUsrjmhuaI6SGjw0eusF
FCCnDN2URjk+Un2OFHa3fn0lRFes/rIXvV0aB8pZGp8XJLO6u3pdfKJGnVeBtgBUr/YkXT/APo+z
pp6a52+VjOEA8tcsfkco+Ml4quvZRSQ6/5hvDlEnm08CAwEAAaOBnjCBmzAOBgNVHQ8BAf8EBAMC
AQYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQUc/Pyi9HYduL1F1K9IjZs+KkJi3QwNQYI
KwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhl3d3cuZ2xvYmFsdHJ1c3RmaW5kZXIuY29tMB8GA1Ud
IwQYMBaAFLFTcaAo/ecMU5odaxA87sgazV7OMA0GCSqGSIb3DQEBBQUAA4IBAQAWgwuPN1Kt4P+g
mBe25iHuepjjWcslDjZaC65ZxQuGjr/Aj7eKtBwpvw+01S4r9QIKQeT0DqlcFJlf3mDa6S25ZKxR
hUM74fxSYvfT1hAFd7NMZ2BYSj5bGHX5LWFQi1REDthiggjUt5QUGj+OVDfqBakynkiYMinw+NV0
gdRzMyhE3j3nWzeXrOXOmzea3o4bsLK2yCAJ6v+VjjTs+gBlCIE2aqSdctX2JOFJLQUyWlArBqZ9
CEdVW+iYS7PYRnOddXLiX3EC/7+MlbNMZSW234XzWQxrNqF8JzUXbYHm3jDMsprDdeC8RtiYAhQa
T/Ogeq21ndR7phpmrMQqYCSBMIIDajCCAlKgAwIBAgIBATANBgkqhkiG9w0BAQUFADA7MQswCQYD
VQQGEwJHQjERMA8GA1UEChMIQXNjZXJ0aWExGTAXBgNVBAMTEEFzY2VydGlhIFJvb3QgQ0EwHhcN
MDMwMzA0MDgwNjEyWhcNMTMwMzA0MDgwMTI3WjA7MQswCQYDVQQGEwJHQjERMA8GA1UEChMIQXNj
ZXJ0aWExGTAXBgNVBAMTEEFzY2VydGlhIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw
ggEKAoIBAQDR+NPebia/iGElNG3QI9TlQSWE+vwhh9N1p608htxwX3HG2PREDou8hP/r3pIkkJEs
flGxt3RVXK+Ut7IyKKB17rhlUSGmrqaRL2fAxyCsCbtak6uLqh7afDYesI1ozLn4sYMFeFWGCWKk
kNBzGfDvKebjXAz9yNxhFyLGbB+ZUkEsfjQA3GJ4Dza4FAbWUH/Q9jWpd8RU9Wx9Hi+QTfXOTaaW
Tn+QMRg9QWuP6pklSsGA65j9YWoBd+ONtSEUM0aX3p/iuecSqC/IjfSxa7hWCskQR+bzqg3xMJTa
R1JpCQds6Z1OqJX5R3UEh71FaxC2TTMgGhNDhwVuoxEgSPhlAgMBAAGjeTB3MA4GA1UdDwEB/wQE
AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSxU3GgKP3nDFOaHWsQPO7IGs1ezjA1Bggr
BgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGXd3dy5nbG9iYWx0cnVzdGZpbmRlci5jb20wDQYJKoZI
hvcNAQEFBQADggEBAKRrsf6/A8LzMqEFJcKl3pq41fPXH7gDLbayGYxvRJ15LRMwxy6A8A2SrY5r
V8u8PStKcMGKj/1R4q1zY/h2TH0eIHDNzIcXiAndZFNBIRPskQ1qIKIlTtO/TYC1f+qss9r7eKcw
Yk90WhdkdZ0k/r21Z7JQMtLGvgO+2Mc4LEb4f1Li/TdB3M0dBq0nRrDX5wiM3hoRbYkWn+0rNtHl
4fVqp5M0S9BeWud/jNIiPu2OSFCdiXDgYVYP56OfVYHuUQuTGfsRP8EI3uUE5RFqIPBj+Vx/Dwzt
/LnNR2CfKv6HPS5AstKZWr04k/RKserIBmJLuxohgfnUuLWJovLFPJkwggQ2MIIDn6ADAgECAgE0
MA0GCSqGSIb3DQEBBQUAMGAxCzAJBgNVBAYTAkdCMREwDwYDVQQKEwhBc2NlcnRpYTEmMCQGA1UE
CxMdQ2xhc3MgMiBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxFjAUBgNVBAMTDUFzY2VydGlhIENBIDIw
HhcNMDQwMzA4MDc0NjM5WhcNMDUwMzA4MDcwMDAxWjBLMQswCQYDVQQGEwJHQjERMA8GA1UEChMI
QXNjZXJ0aWExFDASBgNVBAsTC0RldmVsb3BtZW50MRMwEQYDVQQDEwpZYXNpciBLaGFuMIGfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDQw4w9nWiaKNYb6jLXsC/oWxIqhrnyG/pb3CdYhimtpH8k
9LcuXf0nxt2DNPcKN0Trsj+va5o8My3tlAt+8OAXMLKFMX1VBcUQew+cJsvdrxLeX4lrBrZnmUGR
WL0xr/TDvTSUIwERqCqYpCHWrTkGnOkbMctJdYok0ebEhd3npQIDAQABo4ICEzCCAg8wDgYDVR0P
AQH/BAQDAgP4MAwGA1UdEwEB/wQCMAAwggEDBgNVHSAEgfswgfgwgfUGCisGAQQB/EkBAgEwgeYw
geMGCCsGAQUFBwICMIHWGoHTVGhpcyBjZXJ0aWZpY2F0ZSBpcyBmb3IgdGhlIHNvbGUgdXNlIG9m
IEFzY2VydGlhLCBhbmQgaXRzIGN1c3RvbWVycy4gQXNjZXJ0aWEgYWNjZXB0cyBubyBsaWFiaWxp
dHkgZm9yIGFueSBjbGFpbSBleGNlcHQgYXMgZXhwcmVzc2x5IHByb3ZpZGVkIGluIGl0cyBDZXJ0
aWZpY2F0ZSBQb2xpY3ksIHdoaWNoIGlzIGF2YWlsYWJsZSBmcm9tIGluZm9AYXNjZXJ0aWEuY29t
LjAdBgNVHQ4EFgQUOwYmW7OQ2HAHAeNeR/ltL6CKbgcwTQYDVR0fBEYwRDBCoECgPoY8aHR0cDov
L3d3dy5hc2NlcnRpYS5jb20vT25saW5lQ0EvY3Jscy9Bc2NlcnRpYUNBMi9jbGFzczIuY3JsMDUG
CCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZd3d3Lmdsb2JhbHRydXN0ZmluZGVyLmNvbTAiBgNV
HREEGzAZgRd5YXNpci5raGFuQGFzY2VydGlhLmNvbTAfBgNVHSMEGDAWgBRz8/KL0dh24vUXUr0i
Nmz4qQmLdDANBgkqhkiG9w0BAQUFAAOBgQBHDbq9/Y4utItSYbDeuMmzYM6tckb2Kyk3wU7mQfIJ
PRCzNDCcG6fsmx0BvmZg/jclxGc12P64LDRDPH2Ly47L+c/DeBvVzFz6+37tGSoNs3c+2t8eH1l3
sYvbJ4E2QeZaeGs1mISgOiEGuCn9zvwXpNzNovcHZ6oxetVNQVE2IjGCAcgwggHEAgEBMGUwYDEL
MAkGA1UEBhMCR0IxETAPBgNVBAoTCEFzY2VydGlhMSYwJAYDVQQLEx1DbGFzcyAyIENlcnRpZmlj
YXRlIEF1dGhvcml0eTEWMBQGA1UEAxMNQXNjZXJ0aWEgQ0EgMgIBNDAJBgUrDgMCGgUAoIG6MBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDUxODEwMDc1M1owIwYJ
KoZIhvcNAQkEMRYEFBXmSQAM68vBgi3i9yZm9UkxZZjTMFsGCSqGSIb3DQEJDzFOMEwwCgYIKoZI
hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMAcGBSsOAwIdMA0GCSqGSIb3DQEBAQUABIGAUIIGB0xZKvZLJR9H3/qV7f7Sgnq3vheGOSVJ
iGdpuC7R0CPIB0VbW+yn630RGZbcKgcXGqLatut0lrLnEY0LhXjaP7Wf1eWbRYnQ12AfajzbKC04
sgCKIvC3iXILZzFIBoo+HbPr/OKTnlZDhEj41AQg+Or71ssYS2xvObZzXFIAAAAAAAA=

------=_NextPart_000_0086_01C43CE9.E957D2F0--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4I0ddxU015269; Mon, 17 May 2004 17:39:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4I0ddJh015268; Mon, 17 May 2004 17:39:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4I0dbYF015251 for <[e-mail]>; Mon, 17 May 2004 17:39:38 -0700 (PDT) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 17 May 2004 19:40:09 -0500
From: "Miguel Rodriguez" <[e-mail]>
To: "'Yasir Khan'" <[e-mail]>, <[e-mail]>
Subject: RE: Signature in OCSP Request
Date: Mon, 17 May 2004 19:41:14 -0500
Message-ID: <002601c43c70$ddb9edd0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0027_01C43C46.F4E3E5D0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <011d01c43c17$5eaee0d0$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Importance: Normal
X-OriginalArrivalTime: 18 May 2004 00:40:10.0906 (UTC) FILETIME=[ACF68FA0:01C43C70]
Sender: [e-mail]
Precedence: 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_0027_01C43C46.F4E3E5D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

You may need to reverse the signature so it can be verified by the OCSP
server. The signature should be computed over the tbsRequest structure.
Regarding the algorithms RFC 2560 is nto specific when it comes to
signed requests, we need further clarification of this point.
 
Miguel A Rodriguez
SeguriData
Mexico

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Yasir Khan
Sent: Monday, May 17, 2004 9:01 AM
To: [e-mail]
Cc: [e-mail]
Subject: Signature in OCSP Request




Hello
 
I have a question about the signature field in OCSP request. What
exactly should it contain and what 
algorithms can be used for OCSP request signing? 
 
When i create a signature using MS CAPI, OCSP reponders are unable to
verify the signatures whereas we
can verify it using CAPI. What data do we set in signature field
exactly?
 
Regards,
 
Yasir
 
 


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

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

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D610453200-18052004><FONT face=3DArial color=3D#0000ff =
size=3D2>You=20
may need to reverse the signature so it can be verified by the OCSP =
server. The=20
signature should be computed over the tbsRequest structure. Regarding =
the=20
algorithms RFC 2560 is nto specific when it comes to signed requests, we =
need=20
further clarification of this point.</FONT></SPAN></DIV>
<DIV><SPAN class=3D610453200-18052004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D610453200-18052004><FONT face=3DArial color=3D#0000ff =
size=3D2>Miguel=20
A Rodriguez</FONT></SPAN></DIV>
<DIV><SPAN class=3D610453200-18052004><FONT face=3DArial color=3D#0000ff =

size=3D2>SeguriData</FONT></SPAN></DIV>
<DIV><SPAN class=3D610453200-18052004><FONT face=3DArial color=3D#0000ff =

size=3D2>Mexico</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>Yasir Khan<BR><B>Sent:</B> Monday, May 17, 2004 9:01=20
  AM<BR><B>To:</B> [e-mail]<BR><B>Cc:</B>=20
  [e-mail]<BR><B>Subject:</B> Signature in OCSP=20
  Request<BR><BR></FONT></DIV><FONT face=3DArial color=3D#800080 =
size=3D2>
  <DIV><BR>Hello</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>I have a question about the signature field in OCSP request. What =
exactly=20
  should it contain and what <BR>algorithms can be used for OCSP request =

  signing? </DIV>
  <DIV>&nbsp;</DIV>
  <DIV>When i create a signature using MS CAPI, OCSP reponders are =
unable to=20
  verify the signatures whereas we<BR>can verify it using CAPI. What =
data do we=20
  set in signature field exactly?</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Regards,</DIV>
  <DIV>&nbsp;</DIV>
  <DIV>Yasir</DIV>
  <DIV>&nbsp;</DIV>
  <DIV></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0027_01C43C46.F4E3E5D0--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4HL5Et1003405; Mon, 17 May 2004 14:05:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4HL5EoV003404; Mon, 17 May 2004 14:05:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from optimus.ietf.org (optimus22.ietf.org [132.151.6.22]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4HL5Ded003397 for <[e-mail]>; Mon, 17 May 2004 14:05:13 -0700 (PDT) (envelope-from [e-mail])
Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1BPoGo-0003IW-V4; Mon, 17 May 2004 15:59:30 -0400
X-test-idtracker: no
From: The IESG <[e-mail]>
To: IETF-Announce:;
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, pkix mailing list <[e-mail]>, pkix chair <[e-mail]>, pkix chair <[e-mail]>
Subject: Document Action: 'A 224-bit One-way Hash Function: SHA-224'  to Informational RFC 
Message-Id: <[e-mail]>
Date: Mon, 17 May 2004 15:59:30 -0400
Sender: [e-mail]
Precedence: 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:

- 'A 224-bit One-way Hash Function: SHA-224 '
   <draft-ietf-pkix-sha224-01.txt> as an Informational RFC

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

The IESG contact persons are Steve Bellovin and Russ Housley.

Technical Summary
 
 This draft specifies a 224-bit cryptographic hash function.  224 bits is
 the obvious choice to match triple-DES in strength against brute-force
 attacks. At least two independent implementations exist and agree on the
 test vectors in this document.

 
Working Group Summary
 
 Since NIST has already specified SHA-224, this was the only reasonable
 choice.

Protocol Quality
 
 Steve Bellovin has reviewed this document for the IESG.

RFC Editor Note

 Please make two changes.

 1. Please correct typos in the Abstract.

    OLD:

     ... A SHA-224 is based on SHA-256, but it uses an different ...

    NEW:

     ... SHA-224 is based on SHA-256, but it uses a different ...

 2. The Introduction has two paragraphs.  Please add an additional
    paragraph at the end of the Introduction.

    NEW:

     This document makes the SHA-224 one-way hash function specification
     available to the Internet community, and it publishes the object
     identifiers for use in ASN.1-based protocols.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4HKf9CY001550; Mon, 17 May 2004 13:41:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4HKf9tN001549; Mon, 17 May 2004 13:41:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail19e.dulles19-verio.com (mail19e.dulles19-verio.com [198.170.241.12]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4HKf7NZ001535 for <[e-mail]>; Mon, 17 May 2004 13:41:08 -0700 (PDT) (envelope-from [e-mail])
Received: from www.geminisecurity.com (161.58.96.110) by mail19e.dulles19-verio.com (RS ver 1.0.92vs) with SMTP id 4-0166386469; Mon, 17 May 2004 16:41:09 -0400 (EDT)
From: "Peter Hesse" <[e-mail]>
To: "'PKIX List'" <[e-mail]>
Cc: "'Steve Hanna'" <[e-mail]>
Subject: RE: Comments on Path Building I-D
Date: Mon, 17 May 2004 16:41:10 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcQzrRHuZ0P5y5ZzSma4FwtwW/9M0QAAC6bQ
Message-ID: <[e-mail]>
X-Loop-Detect: 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>

Steve,

<resending because I exceeded the PKIX list size limit...>

Thank you for your in-depth reading of the document and the large number of
comments.  I will attempt to address the majority of them in this message.
I apologize for the time it has taken me to respond.

> Overall Comments:
> 
> * My main overall comment is the one I made last July. There 
> is not consensus on path building techniques in the PKIX 
> working group or the IETF. Why? Because we don't understand 
> the problem thoroughly yet.

We do understand the problem.  The problem is a traditional graph theory
problem.  The only new part of the problem as it relates to PKI is how to
define the penalty function.  We have defined heuristics that make sense for
PKI.

I'm not sure that this is a reason to prevent this document from
progressing.  This document is based upon the best research we have to date,
which includes real-world experience with operational PKIs and users.  If at
a later time, there is additional research performed, and new conclusions
are reached, then the obvious recommendation would be to update the draft.
Until that time, I do not think it is useful to withhold this document.
 
> In this document, you advocate depth first search and suggest 
> that building forward is usually best. I don't think you have 
> carefully considered a wide variety of other algorithms like 
> breadth first search, meet in the middle, etc. Can you show 
> me any solid evidence that shows your algorithms are better 
> than the alternatives?

Yes and no.  I can generate a set of PKI structures which will make this
algorithm work best, just as you could generate a set of PKI structure which
would make another algorithm work best.  Until there are useful real-world
examples to test against which demonstrates one approach is generally better
than another, such evidence would be questionable.  The methods described in
the draft have been used in real-world PKIs with success.
 
> I doubt that you have any such proof. In fact, it seems clear 
> to me that depth first search is a poor algorithm for 
> building cert paths. I say this as a person who has 
> implemented that algorithm myself and regretted it. The 
> problem is that if you make a wrong choice, you must 
> completely explore that part of the PKI before you consider 
> backing out and trying other options. I have heard stories of 
> path building taking 35 minutes or more when there was a 
> valid short path because the builder used DFS and headed down 
> the wrong path.

Certainly these are horror stories, and if the path-building software
consistently took 35 minutes to develop a path, it would not be in use
today.  In the document, we advocate finding a valid path fastest to prevent
such a thing from occurring.  

There may be ways to optimize building so that a valid path is even more
likely found first across a wider range of conditions than the approach we
described.  However, this is a balancing act between complexity for
implementers, performance, and functionality.  We may be able to design an
exceedingly complex (to implement) algorithm that almost always yields best
performance and allows for every conceivable scenario, but no one would want
to (or be able to) implement it.

> We need to do our homework before making any solid 
> recommendations to implementers. I suppose it's better to 
> have some advice than none, but this document should have a 
> prominent warning that these techniques are experimental. In 
> fact, we might want to give the RFC Experimental status.

We (as authors) have influence but no control as to whether the document
heads down standards, informational, or experimental tracks.  We have
requested informational status, but the IESG can decide whatever they wish.
I truly feel that this document is Informational, it provides potential
implementers with information that they can use when they are creating their
own implementation; it provides little in the way of strict recommendations.
Note the following snippets of RFC2026:

4.2.1  Experimental

   The "Experimental" designation typically denotes a 
   specification that is part of some research or development 
   effort. [...]

4.2.2  Informational

   An "Informational" specification is published for the 
   general information of the Internet community, and does not
   represent an Internet community consensus or recommendation.
   [...]

> As I've suggested before, I want to see a careful analysis of 
> different path building strategies. Theoretical analysis will 
> probably be useful, but I expect it will also be useful to 
> compare real-world performance with a variety of topologies 
> (some from real-world deployments, some looking at possible 
> futures like many cross-certified bridges). We need to try 
> out a lot of ideas without getting committed to any too 
> early. The cert path building panel at the PKI R&D Workshop 
> this year was a good start, but we need to do more in-depth 
> work. I've started talking to some other researchers about 
> this. I hope that this documents' authors will join this effort.
> Their experience and aid will be valuable.

I agree with you and would also like to see additional research and analysis
performed in this area.  However, X.509 has existed in one form or another
since 1988 and there has never been any guidance for implementers on how to
build certification paths.  Now, 16 years later, we are offering to provide
a document with some guidance--a starting point at the least--for
implementers.  We should not wait any longer for additional research.

When new research brings something additional to light, this RFC can be
updated or replaced as warranted.
 
> * At several places in the document, you refer to the "authors'
> opinions". If this was truly a working group document, it 
> would reflect the consensus of the working group, not the 
> opinions of the authors. As I said before, I don't see 
> working group consensus on this topic. Has anyone other than 
> me (and maybe the authors) carefully reviewed the current 
> draft? I haven't seen any comments on it during Last Call.

We did receive a significant number of comments from some other folks on
earlier drafts, and we have addressed those comments.  This document must be
based upon the opinions of the authors, because as I mentioned above, one
can always create a path which makes a particular algorithm operate well.
As the section from RFC2026 above, there is no problem with an informational
RFC where the judgment calls in the document are based upon the opinions of
the authors.

> Since this document does not reflect working group consensus, 
> I do not think it should go forward as a working group draft. 
> It should be an individual submission. But I suppose once it 
> becomes an RFC nobody will ever know whether it was a working 
> group submission or not. And I really do think it's useful to 
> have some guidance on cert path building (even if we don't 
> understand the problem very well). So I'd be OK with having 
> it be a working group submission if it goes to Experimental 
> status and a caveat is added at the beginning warning that 
> this is only the authors' opinion (albeit an educated 
> opinion) and that further study is under way to determine 
> which techniques are actually preferred.

As I mentioned earlier, based upon RFC2026, I don't think that experimental
status is appropriate.  As far as a caveat at the beginning of the document,
we intended to have already performed that in section 1.2, Purpose:
  
# This document provides information and guidance for certification
# path building.  There are no requirements or protocol
# specifications in this document.  This document provides many
# options for performing certification path building, as opposed to
# one particular way to best perform certification path building.
# This document draws upon the authors' experience with existing
# complex certification paths to offer insights and recommendations
# to developers integrating support for [X.509] digital
# certificates into their applications.
#  
# In addition, this document suggests using an effective general
# approach to path building that involves a depth first tree
# traversal.  While the authors believe this approach offers the
# balance of simplicity in design with very effective and
# infrastructure neutral path building capabilities, the algorithm
# is no more than a suggested approach. Other approaches (e.g.,
# building complete spanning trees of the PKI.) exist and may be
# shown to be more effective under certain conditions.
# Certification path validation is described in detail in
# both [X.509] and [RFC 3280] and is not repeated in this document. 


> * You should include in this document a section with guidance 
> to PKI designers about what they can do to make path building 
> easier. Here are some ideas:
> 
> Use a simple topology (hierarchical with one root), when possible.
> Include AIA, SIA, and CRLDP extensions in certificates. Make 
> certificates (especially CA certificates) and CRLs easily 
> available by LDAP and HTTP, populating both sides of the 
> crossCertificatePair attribute. Use name constraints and 
> policy constraints whenever possible, especially at high 
> fanout points like bridges. Avoid having more than two high 
> fanout CAs (at most) between any two points, if possible.

I don't disagree with any of these suggestions, and I think that they are
appropriate for capture in a document.  I'm just not sure that this document
is the right place.  This is less of a path development issue and more of a
PKI architecture issue.  Therefore, I recommend that a separate document be
created to provide guidance to PKI implementers on how best to construct
their PKI so that path development routines have a good chance for success.
I would be happy to collaborate with you on such a document.

> * I have a *serious* objection to the idea that someone is 
> going to specially configure path building software for a 
> particular PKI environment (as I think you imply at the end 
> of section 2.3, early in section 3.4, and in a few other 
> places). This is not practical. Most organizations do not 
> have a PKI wizard on staff (especially a path building 
> wizard). The path building software must just work, 
> automatically. If we can't do that, PKI will never be widely 
> used (at least, not in a non-hierarchical topology). 
> Fortunately, I see no reason why we need special 
> configuration. With AIA and SIA and CRLDP and some good 
> algorithms, we should be able to build paths just fine in 
> almost any PKI without any configuration.

Again, I agree with what you have written here.  However, my practical
experience in this area is a reason for this implication being made.  With
no guidance, a path building implementer might be just concerned with
getting their software to work with the particular PKI they have been faced
with in testing.  This occurred a few times in early revs of the DoD PKI and
government-funded software.

Our goal as stated in the purpose section is an approach which "offers the
balance of simplicity in design with very effective and infrastructure
neutral path building capabilities."  Certainly a design can be simplified
if parts of the implementation are left out, because they will never be used
in the target infrastructure.  The end of our section 2.1 lists the reasons
why users might want to do this.  Additionally, as I mentioned above, one
can always come up with an algorithm that works best in their specific
environment.  While it may not be practical to expect, if there is enough
pressure to ensure that paths are built and validated in a timely fashion, I
can imagine it happening.

Oh, and two additional notes: CRLDP does not help in path development--just
for retrieving data needed for the path.  And, AIA does not help path
development any better than a populated LDAP directory does.  (If a issuer
has multiple certificates, either AIA will be underpopulated or you will
face the same dilemma in terms of which certificate to use to develop the
path.)

> Substantive Comments:
> 
> * Section 1.2 (Purpose) says "... this document suggests using ...
> depth first tree traversal. ... Other approaches (e.g., 
> building complete spanning trees of the PKI.) exist and may 
> be shown to be more effective under certain conditions."
> 
> Building a complete spanning tree of the PKI is not a decent solution.
> Please change this to something more reasonable, like breadth 
> first search. Otherwise, you're just setting up a straw man, 
> an impractical alternative.

We will change this to a breadth first search.  Of course as we mention in
the document, in certain cases, this might be impractical as well.  (i.e.
forward cross-certificates not being present)

> * In section 1.4.1, you mention one disadvantage of the trust 
> list approach. You might want to mention the problem that 
> compromise of any trusted certificate compromises the entire system.

We will add this.

> * In section 1.4.2, you say that a partial mesh is a mixture 
> of unidirectional and bidirectional cross-certifications. 
> It's probably also important to note that in a partial mesh 
> there may be CAs that are not directly cross-certified at all.

We will add this.

> * What is a Root CA doing in Figure 3? As you say, each EE in 
> a mesh usually trusts the CA that issued its certificate. 
> Because of this Root CA, Figure 3 does not depict a full 
> mesh, as stated in 1.4.2. I suggest that you remove the Root CA.

This was changed to be a root based upon a comment made by Denis Pinkas
stating that the diagrams were inconsistent.  I think I agree with you, it
is more confusing with the root in there.  We will change this.
 
> * At the end of section 1.4.3, you raise the concern that the 
> assurance of a high-assurance PKI may be diluted by 
> cross-certifying with a less restrictive PKI. If you're going 
> to raise this concern, you should mention that it can be 
> addressed through the use of certificate policies.

We will add this.

> * At the end of section 1.4.4, you say that connecting PKIs 
> with a bridge results in a non-hierarchical PKI. Certainly, 
> this is true. But mesh and hybrid PKIs are not hierarchical 
> either. Why raise this here?

This is mentioned because a lot of people look at a picture involving a
Bridge, and think of the Bridge as a root, and everything being subordinate
to it.  This is just another attempt to prevent that.

> And the following sentence which states that any PKI can be 
> considered hierarchical from the right perspective only 
> applies if you remove and duplicate links in the PKI. Since 
> you don't have space to get into this here, I suggest you 
> remove those last two sentences.

We already reference section 2.3 where we go into some more detail.

> * At the end of the first paragraph of section 2.1, you 
> explain that S/MIME messages commonly include certificates. I 
> think you would be wise to also mention SSL/TLS since this is 
> the most widespread use of PKI and it also supplies 
> certificates in the protocol.

We will add this.

> * Before Figure 6, you explain how certificates are depicted 
> with arrows in your figures. You should also explain the 
> "B(A)" notation you use.

We will add an explanation to this section.

> * At the end of the paragraph after Figure 6, you say that 
> building paths is as important as validating them. I don't 
> agree. Many products have been shipping for years and work 
> just fine without building. In a complex PKI, building is 
> important. But in a simple hierarchical PKI, it's not.

Even in a simple hierarchical PKI, some amount of building has occurred.
(OK, maybe not in a REAL simple example with one trust root and all target
certificates issued directly by it...)  Building is important.  If you don't
build a path, you can't validate a path.  It's just that building in certain
cases is so easy it doesn't even seem like you're doing any work.

> * At the end of section 2.1, you have a large discussion of 
> why you believe building forward is usually better. This 
> duplicates later discussions on this topic. I suggest you 
> save this for later.

We will shorten section 2.1 and provide a cross-reference to the end of 2.3
where we discuss this in more detail.

> * In section 2.2, you could simplify and clarify Criterion 1 
> by changing it from this:
> 
>  Criterion 1: The implementation is able to find all possible paths.
> By this, it is meant that all possible certification paths 
> between the trust anchor and the target certificate which may 
> be valid paths can be built by the algorithm.
> 
> to this:
> 
>  Criterion 1: The implementation is able to find all possible paths.
> By this, it is meant that all valid certification paths 
> between  the trust anchor and the target certificate can be 
> built by the algorithm.

Yes, but I will propose changing it to (potentially) valid because I do not
necessarily want to burden path building software with having to also be
path validation software.  By potentially, I mean it is valid as far as the
builder can tell.  To some builders that is fully valid.  To others it may
still require a final sanity check/run through the validation procedure.
 
> * In section 2.2, Criterion 2 seems rather odd. Who cares 
> which invalid paths you build first? The important thing is 
> how quickly and efficiently you can build a valid path or 
> determine that no valid path exists.

The purpose of this criterion is ensure that the users get meaningful
errors.  You want to build paths which are likely to be valid before you go
off and build paths which have a very low chance of success.  What is a
better error for a user to see, "name constraints violation at certificate
14" or "cert 3 revoked"?  We will try and word this a bit better to get that
point across.

> * In section 2.3, you say that because certificates are not 
> permitted to repeat, every potentially valid path has a 
> terminus. But every potentially valid path *always* has a 
> terminus, even if certificates are allowed to repeat. As 
> defined in RFC 3280, a certification path is a collection of 
> n certificates. Every path has a finite number of 
> certificates. I suggest you remove the sentence "As a result, 
> every potential valid path has a terminus, a leaf on the tree."

Each path does have a terminus, once it becomes a path.  If certificates can
be repeated, the number of certificates in the path and the number of
possible paths both increase to infinity.  This is a wordsmithing issue that
may be able to be worded more clearly.  Perhaps we will change it to say "If
certificates could be repeated, loops can be formed such that the number of
paths and the number of certificates in a path both increase without bound
(e.g. A issues to B, B issues to C, and C issues to A.)"

> * In the following paragraph, you say that removing and 
> duplicating nodes and links in a PKI to turn it into a 
> hierarchy greatly simplifies software design. This may be so, 
> but it also removes many opportunities for insight and 
> optimization. For example, it increases the number of nodes 
> in the data structure and makes it harder to mark a certain 
> area of the PKI as unproductive (since that area may appear 
> several places in the tree).

We will remove "- this greatly simplifies software design." from the
sentence.

> * Later in that paragraph, you use the phrase "decision tree" 
> without defining it. I suggest that you define it in section 1.3.

We will add a definition for "decision tree".

> * One paragraph on page 16 (starting with "A more complicated
> example") talks about problems with building in the reverse 
> direction when there are many trust anchors. The real issue 
> here is fanout.
> Whether you're building forward or building reverse, it's bad 
> news when you get to a point where you have several choices. 
> It's especially bad if your heuristics (ranking) don't give 
> you much help in deciding which way to go. And it's even 
> worse if you're using depth-first search, since one wrong 
> move can send you off in the wrong direction for hours. 
> That's why I suggest breadth first search or (even better) 
> ranking all candidates at all points in the tree at each 
> decision time.
> 
> Four trust anchors is a four-way fanout. A similar situation 
> would arise if you were building forward and arrived at a CA 
> that has four certificates with it as the subject. In either 
> case, you hope that your ranking will help choose the right 
> path. And if you're using depth first search, you really hope 
> that you don't take a wrong turn.
> One technique for dealing with extreme fanout with fairly 
> equal rankings is to start building from the other end. 
> Another is to rank the certs at the fanout point low and try 
> another branch. A third is to use DPD to get help. And a 
> fourth is to tell PKI designers to use name constraints and 
> other techniques at high fanout points (like
> bridges) to help path building succeed.
> 
> I hope that you find this analysis useful.

I agree that this example may go into a little too much detail without
providing much benefit to the reader--we've done a good job of identifying
the problem but not at clearly identifying a solution.  I will try and
simplify the example, identify that the real enemy here is fanout, and that
to combat it, implementers should strive to use optimizations such as those
discussed in section 3.1 when there are a lot of choices at a particular
point of development. (By the way, this is p18 on my copy.)  

> * In Figure 10, are W, X, Y, and Z all trust anchors? I think so.
> That's pretty odd. Why would a relying party have all four of 
> those trust anchors? Who needs the bridge CA in that case? I 
> suspect that this topology was created to support your 
> arguments that repeating a (name, key) pair is bad and that 
> building in reverse is bad. If so, I think you can do better.

They are trust anchors for different relying parties, the trust anchors of
each of the PKIs which are cross-certified with the Bridge.  We will attempt
to make that clearer in the example.  In our example we are treating only W
as our trust anchor.

> Let's do a careful theoretical analysis and try out different 
> algorithms on different topologies. I suspect you're right 
> that repeating a (name, key) pair is bad but we need to think 
> about this carefully since it is a significant change to RFC 
> 3280. I think you will see below that building in reverse is 
> a useful tool that should be used in conjunction with 
> building forward. But we need to show the merits of our 
> approaches through analysis, not by consructing topologies 
> that serve our own purposes.

We have identified reasons why a (name, key) pair should not be repeated
within this document, and why building implementations should consider not
allowing them in section 2.4.2.  We have not attempted to change RFC3280
although I think we would have a decent argument for this, it is for a
different time and place.  

> * In the paragraph after Figure 10, you have several 
> sentences explaining the diagram's notation. This was 
> explained much earlier.
> The rest of the paragraph (explaining where certificates 
> would be stored in an LDAP directory) also duplicates 
> material found elsewhere.
> I suggest that you remove these, since the document is 
> already too long.

We will remove the duplication.
 
> * In section 2.4.2, you seem to be proposing that software 
> should build a decision tree. I believe you don't intend for 
> the software to actually build a tree for the entire PKI but 
> only to move incrementally through the PKI adding nodes and 
> links to the tree as needed. I hope that's the case, anyway. 
> Otherwise, you'd need to download all certs in the PKI! If 
> I'm right, you need to be much clearer about this. I could 
> easily imagine a developer writing code that actually builds 
> the tree. That code would work fine in a small test PKI but 
> flood the directory with requests and then die in a large PKI.

We will try and make this clearer.

> * After Figure 11, you point out that building in reverse is 
> not good in this case. Sure. The EE is in a simple hierarchy. 
> Of course, building forward is best there. If you don't know 
> the topology (especially if you have several trust anchors), 
> starting with forward is fine. Then you can switch or meet in 
> the middle if things get hairy.

As I mentioned before, one can always make an example that is good for a
particular argument!  In this case though, we don't say it is not good, we
say it is not possible, due to a lack of available certificates.
 
> * In section 2.6, you say "[...] the path builder only needs 
> to store the current location in the tree [...] All completed 
> branches can be discarded from memory [...]". Maybe. There's 
> a lot to be said for retaining records of paths you have 
> already tried and rejected. Then you can avoid retrying them 
> at a different point in the graph (unless conditions are 
> sufficiently different to merit a retry).

I agree with what you've written.  We have even some implementations that
mark a path as bad given a certain set of inputs so that it is not tried
again.  We will reword this section.

> * Later in section 2.6, you say "Consider HTTPS support" for 
> CRLDP and AIA. Why would this be valuable? You're retrieving 
> signed data. Using HTTPS may trigger another path build, 
> maybe even a loop where one build triggers another which 
> triggers another and so on. I suppose some repositories may 
> require HTTPS to authenticate the client or protect the certs 
> from prying eyes. But you should probably warn that doing so 
> may be expensive and that implementers should protect against loops.

I think we know of someone that is using HTTPS for one of these cases, and
that is why it was thrown in there.  We will add something to warn users
that HTTPS support needs to be considered in terms of its potential impact
creating a loop.

> * Toward the end of section 2.6, you talk about the path 
> cache. You call for "a configurable expiration date for each 
> entry". Who would configure the date and why? I'm a path 
> building geek and I can't imagine configuring such a thing!

By configurable, I think it is meant that the software would set the
expiration when it creates the entry, based upon a number of factors.
Examples of factors include the expiry of the information used to make the
determination, bandwidth, assurance level, storage space, whether it is a
server or client, etc.  We will make this clearer.

> * A few sentences later, you suggest storing issuer-subject 
> cert relationships. If you want to do this, I suggest that 
> you use a cert hash instead of an (issuer, serial) tuple. 
> Issuer, serial is *not* always unique, especially across 
> multiple PKIs or when one CA is malicious (and remember that 
> some CAs are only partly trusted in a modern PKI).

According to X.509, Issuer, Serial is always unique, since a given issuer
cannot repeat a serial number.  Of course, this assumes a "global directory"
where issuers are never repeated.  Issuer/Serial tuple is used as the
certificate identifier in a number of protocols (S/MIME for example) and of
course it is important for users to ensure that the resultant path is valid
through validation of signatures.

> * In section 2.7.1, you talk about the required inputs. 
> Instead of supplying the actual Target Certificate, it is 
> sometimes useful to provide criteria that describe what sorts 
> of target certificates you're willing to accept. For 
> instance, when doing S/MIME encryption to a new correspondent 
> you may not have the correspondent's encryption certificate. 
> The path building software can help find it if you tell it 
> what you need.

We will note this as a possibility.  Our goal for this document was "given a
certificate, how do I build its path" but we will note this.

> * In section 3.2, you recommend that path building software 
> output a detailed log. I think you should recommend that this 
> log be carefully structured so that the paths tried can be 
> easily reconstructed by a diagnostic program. My team built a 
> tool that shows the cert graph and then replays the paths our 
> builder tried, lighting up each one in sequence. We found 
> this a great help in understanding the behavior of our 
> software (finding bugs, improving algorithms, etc.). It's 
> also a very cool way to demo path building, which otherwise 
> is a pretty boring demo ("see, there's the web page!").

Heh.  Mark that up as a good reason to work in R&D.  We will make this
recommendation.  (About the reconstruction of the paths, not necessarily the
lighting-up part.)

> * Later in that paragraph, you say "Ideally, there would be a 
> mechanism for turning this logging on and off [...]". I'd 
> change this to "There should be [...]". Logging is expensive 
> (in storage and CPU time), especially for path building where 
> you commonly try hundreds of certificates or more to create a 
> valid path. You really need a way to turn logging off and on.

We also can't be prescriptive since this is an Informational document... I
agree but I will not use the word "should".

> * A few paragraphs later, you say "it may be useful to not 
> rule out any paths" and just return each path as its built, 
> even if it's invalid. The problem with this is that 
> (especially with a depth first
> search) is that there are many topologies that may cause you 
> to wander among many invalid paths. Why is this technique 
> good? You say it will "provid[e] a more rapid response to the 
> caller than one which builds all possible paths." Maybe. I 
> suspect you'll instead waste time by spending a lot of time 
> returning invalid paths to the caller. I don't see much 
> reason to return invalid paths except in a diagnostic log or 
> for your interesting idea of providing one path that's 
> *mostly* valid for debugging and in case the caller finds 
> that invalid path educational or compelling.

Of course the simplest case of this is you build a path and everything lines
up except a certificate along the way is expired or revoked.  In this case,
the path is probably the "right" one and is not valid, and won't be.  This
is what we're getting at.

> * A few paragraphs later, you lay out your approach. Here are 
> some comments on it:
> 
> You say "Do not check revocation status if it requires a 
> directory lookup or network access." Why not start the 
> revocation check and let it run in parallel while you do 
> other things (like checking certs deeper in the graph)? That 
> way, you'll have the revocation check done when you need it. 
> And if the check fails you can abort all work that was based 
> on the validity of that certificate. Of course, you'll want 
> to cache the revocation status of certificates for some time.

Again, this gets back to keeping it simple for the implementer.  See later,
we will add to section 7 some more advanced optimizations that includes
background/parallel processing.
 
> You say "Do not check digital signatures". Again, why not run 
> this in parallel? Most of path building time (about 90%, 
> based on our data) is spent waiting for the network (while 
> downloading certificates and such). That's an ideal time to 
> be checking signatures. And, of course, you'll want to cache 
> the results of signature checks.

Same as above.  Signature checks are computationally expensive.  For
3280-compliant certificates, AKID/SKID matching is a much less expensive way
to know that the signatures are likely to chain.
 
> You say "Do not check anything that can not be checked as 
> part of the iterative process of traversing the tree." Why 
> not? I expect you would want to run these final checks (like 
> full policy processing when building forward) before 
> returning the path to the caller. Otherwise, the caller will 
> need to run a complete validation of the path, which will 
> take much more time than just running these last few checks.

I'm not entirely sure I understand what you're saying here.  We're
recommending you don't check anything that's going to get checked anyway.
 
> * In the last paragraph of 3.2, you say "Second, it is fairly 
> uncommon in typical application environments to encounter a 
> revoked key; therefore, most certificates validated will not 
> be revoked." In a PKI, we don't revoke a key. We revoke a 
> certificate. Therefore, this sentence should read "Second, it 
> is fairly uncommon in typical application environments to 
> encounter a revoked certificate."

Agree.  We will make this change.
 
> * Why include section 3.3 at all? It's very odd to have an 
> IETF spec talking about internal data structures. Maybe you 
> should just give everyone a copy of your code (since it is 
> apparently ideal) and save them the trouble of implementing 
> it! I'm going to skip my more detailed comments on this 
> section since I think it should be entirely removed.

I have no problem removing the data formats,  I think it is useful to have a
semi-pseudocode example worked through for implementers to read, so I don't
think we should remove the entire section.
 
> * In section 3.4, you refer say "developers should evaluate 
> each method with respect to the environment that the 
> application will operate, and assign weights to each 
> accordingly in the path building software.". First, the word 
> "that" in this sentence should be "in which". Second, this is 
> a prime example of the awful idea that developers must 
> examine each PKI and configure their software to run optimally there.

We will change to "in which".  Again, if efficiency is your number one
concern, it may be worthwhile to tune the path builder for your environment.
An example of a situation that deserves tuning is a server-based
implementation, when it is always processing paths for a particular
infrastructure.  

We have typically implemented the scoring weights to be read from
configuration files so that they can be tuned; default values would be used
in absence of tuned numbers.
 
> * In section 3.5.1, you say "According to [RFC 3280], 
> basicConstraints is required to be present with cA=TRUE in 
> all CA certificates."
> Actually, section 6.1.4 (k) of RFC 3280 says "Verify that the 
> certificate is a CA certificate (as specified in a 
> basicConstraints extension or as verified out-of-band)." 
> Maybe your software doesn't make any provision for 
> out-of-band indication of CA certificates, but you should 
> probably at least note the possibility that other software may do so.

We will change this to identify this rule must account for out-of-band
indications.
 
> * In section 3.5.5, you say "Certificates in the path cache 
> have been validated previously. There is some probability 
> that the path from that certificate to a trust anchor is 
> still valid." The path may still be valid but it may contain 
> constraints that are inconsistent with the path from the 
> Target Certificate to this certificate. You should probably 
> note that possibility.

We will add an additional note about the changes to initial constraints.

> * In section 3.5.6, you say that the Previously Verified 
> Signatures sorting method doesn't apply when building in 
> reverse. Actually, it does. Your analysis is incorrect. This 
> method never tells you which way the Target or Trust Anchor 
> is (which certificate is most likely).
> It only lets you rule out certificates because the signature 
> check would certainly fail.

I agree that this does help and will be included.

> * In section 3.5.7, you say the Path Length Constraints 
> sorting method "may be applied in reverse, but the benefit is 
> likely less than that of the forward direction". Why? You can 
> argue that the method is more effective when building in 
> reverse because path length constraints often appear close to 
> trust anchors.

Like you mention above, the forward direction lets you immediately rule out
a branch of certificates that would fail.  In the reverse direction, you
rule out branches farther down with some unknown fanout.   That said, I
think this section reads too opinionated and will change it appropriately.

> * In section 3.5.8, you say "Certificates that contain 
> nameConstraints that would  be violated by certificates 
> already in the path to this point are given lower priority 
> (or perhaps eliminated)." They should definitely be 
> eliminated. You know they can't be used to build a valid 
> path, so what's the point (unless you're working on building 
> an invalid path)?

I agree, this will be changed to eliminate certificates.
 
> * In section 3.5.9, you say "While this is viable, the 
> signature verifications required make it less attractive as 
> an elimination method." Usually, a CRL check only requires 
> one signature verification so "verification" should be singular.

Will do.
 
> You also say "It is suggested that this method only be used 
> for sorting and that CRLs are validated post path building." 
> As I noted above, fetching CRLs and performing signature 
> checks can be done in parallel with other work. It's a good 
> idea to do this so that you can discover revoked certs before 
> you have invested too much time in them (and also so that you 
> have the results of the revocation check ASAP).

See my above comments, we are trying to stay simple.
 
> You should also probably change this section to include 
> discussion of OCSP. Right now, it's very focussed on CRLs.

I agree, we will try and make it less specific to CRLs.

> * Here's a sorting method similar to the "Issuer Found in the 
> Path Cache" method, but better suited to building in reverse. 
> Check whether the subject of the candidate certificate 
> matches the issuer of a certificate sent by the target (in 
> SSL/TLS, S/MIME, etc.). If so, then the candidate certificate 
> should be ranked more highly because it is more likely to 
> lead to a path to the Target Certificate. You may also want 
> to do RDN Matching (as in 3.5.15) with the certificates sent 
> by the target.

I agree that this is a helpful sorting method.  With your permission, we
will add it to the document.
 
> * In section 3.5.15 (on RDN matching), you say "Additionally, 
> it should be noted that this method can require a lot of 
> processing if many trust anchors are present." Actually, this 
> should only require a few hash table lookups (of the RDNs).

Assuming you implement it with a hash table!
 
> * Section 3.5.18 could be clearer. I think you're saying that 
> the subject and issuer of the candidate certificate should 
> have lots of RDNs in common. But this could be understood to 
> be saying that the subject of the candidate certificate 
> should have lots of RDNs in common with the issuer of the 
> next certificate. Of course, they must match exactly so that 
> can't be what you're saying. But it would help if this 
> section was more explicit.

We will attempt to reword this to make it clearer.
 
> * Section 3.5.19 also should be clarified. The description of 
> the reverse method is much clearer than that of the forward 
> method. I suggest that you replace the forward method 
> language with language based on the reverse method language. 
> One change to the reverse method language, though. Instead of 
> saying "If an entity named by a reverse certificate", say "If 
> the subject of a certificate". There's no such thing as a 
> "reverse certificate".

We will reword the forward definition to be closer to the reverse.
 
> Note also that just because you find a name in the 
> certificate cache, that doesn't mean you have the right 
> certificates. There may be several different CAs with the 
> same name. Also, you may now have more clues (like AIA and 
> SIA) for finding certificates than you had before.
> You should be sure to pursue any such new clues.

Agree, that's why it's just a sort and not an eliminate rule.
 
> * In the Justification for 3.5.19, you say "The presence of 
> required directory values populated in the cache increases 
> the likelihood that all the required certificates and CRLs 
> needed to complete the path from this certificate to the 
> trust anchor (or target if building in
> reverse) are present in the cache from a prior path being 
> developed [...]". That's fine, but you might also want to 
> keep the actual path previously developed and look at that as 
> a prime candidate for the path this time.

We do recommend a cache for relationships and a cache for information in
section 2.6.  The idea of course is that given the cache of relationships
and the cache of information, you could reconstruct the previous path.  See
rule 3.5.10.
 
> * In section 3.5.20, you use the presence of a CRL in the CRL 
> cache to indicate whether a complete path through a CA has 
> previously been found. This is rather indirect. It would be 
> better to actually track which certs have been previously 
> included in valid paths. Keeping a copy of the path would 
> also be quite useful.

Agreed.  Again, rule 3.5.10 is more useful, and then this can be a secondary
rule to that.

> * The discussion of Forward Policy Chaining in section 4 
> overstates the benefits of policy checks when building in the 
> forward direction.
> We should discuss this more.

We don't feel like we're overstating, and welcome more discussion.

> * In section 5.2, you suggest that each name/key pair only be 
> allowed to appear once in a path. Since there is no such 
> requirement in X.509 or RFC 3280, this would violate 
> Criterion 1 as stated in section 2.2.
> You would miss some valid paths.

This is what happens when you have 5 authors on a document!  This
contradiction will be resolved, most likely by changing the Criterion 1
(since we feel strongly about the non-repetition of the name/key).  
> 
> * In section 6 (Retrieval Methods), you should mention 
> getting certificates and CRLs from the target (with S/MIME or 
> SSL/TLS, for instance). That's a *great* way to get 
> certificates and CRLs. The ones you get are usually highly valuable.

Yes we will add this.  Of course, most commercial implementations don't
provide CRLs in this way.

> * Sections 6.2 and 6.3 should include text that encourages 
> implementers to support AIA and SIA, especially HTTP. This 
> text from the end of section 6.4 could easily be adapted:
> 
>     However, implementers of path building  and validation 
> modules are strongly encouraged to support CRLDPs.  At  a 
> minimum, developers are encouraged to consider supporting the 
> LDAP  and HTTP transports; this will provide for 
> interoperability across a  wide range of existing PKIs.

We will add this (appropriately modified) text to 6.2 and 6.3.

> * In section 7, you should talk about prefetching and 
> parallel fetching. Both are good ways to improve the 
> performance of a cert path building implementation.

We will add these to section 7 as more advanced possibilities.

> * In section 7.1, you say "Certificate processing systems can 
> cache data retrieved from external sources for some period of 
> time, but not to exceed the useful period of the data (i.e., 
> an expired certificate need not be cached)." CRLs are often 
> issued well before the nextUpdate of the previous CRL. Could 
> you mention this and suggest that implementers check 
> periodically for updated CRLs? Similarly, 
> crossCertificatePairs may be updated on an unpredictable 
> basis. If you don't check back every so often, you'll never 
> know that a new cross certificate is available!

We could, although it will take a bit of additional writing to explain these
issues.  We will attempt to encourage retrievals before the nextUpdate has
passed.

> * The last bullet in section 7.1 offers a few suggestions for 
> other things to cache. I'd add to that list previously built 
> paths and partial paths. If the cache is safe from 
> unauthorized modifications (as with an in-memory cache), you 
> may also want to cache validation and signature check status 
> for certificates and CRLs.

We will add these additional recommendations.

> * In section 7.2 (Retrieval Order), you may want to consider 
> checking repositories in parallel instead of serially. Also, 
> you might want to run ahead with your path building and 
> validation while a network query is ongoing. Maybe you can 
> build and validate the path with just the certificates and 
> CRLs you have already (thus eliminating the need to wait for 
> the network query to complete). Anything to get the answer to 
> the user more quickly!

Agreed.  This has been noted a number of times in this message.
 
> * In section 8.1, you should probably add a statement that 
> path building can be used as a denial of service attack. Make 
> a series of simple requests to a server and cause it to do a 
> bunch of long path builds. To avoid this, the server can 
> limit the amount of resources it's willing to devote to a 
> path build. This amount can be reduced when the load is 
> heavy. And standard DOS protections like identifying 
> attackers can be employed.

Yes, we will add something about the threat of DOS attacks on server DPD
systems and systems that handle authentication.
 
> * Section 8.2 goes way beyond RFC 3280 and X.509. I know that 
> Santosh is working on getting this into X.509 and the 
> successor to RFC 3280.
> I'll debate the specifics of his proposal in that context. 
> But for this document, I think you should be careful to 
> explain that this goes beyond the standards. If you implement 
> it, you will violate Criterion
> 1 from section 2.2. Maybe the best thing to do is to just 
> briefly point out that there's an issue here and it's under 
> discussion in the standards groups. Once it's settled there, 
> this document can be revised to reflect whatever's agreed on.

This issue has been debated on the list and there has not been any objection
to it.  It does not violate Criterion 1 of Section 2.2 since the path for
the CRL signer needs to be developed for the same CA hierarchy as the
certification path.
 
> Minor Comments:

We will accept all your minor comments.

Steve, I know I speak for all of the authors when I thank you for this
detailed review of the document.  It is a tremendous help to know that
someone else has read and thought about the entire document, and even if you
have differing opinions on parts of it, you were willing to help create a
better finished product.

Sincerely,

--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.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4HG91hi082056; Mon, 17 May 2004 09:09:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4HG91dG082055; Mon, 17 May 2004 09:09:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4HG91Ju082049 for <[e-mail]>; Mon, 17 May 2004 09:09:01 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 17 May 2004 09:09:03 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 17 May 2004 09:09:00 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 17 May 2004 09:09:03 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP & validation policies
Date: Mon, 17 May 2004 09:09:02 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
thread-index: AcQ74/RcOtUtTjLAQpuHulPYJsLT7QARP2VQ
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 17 May 2004 16:09:03.0591 (UTC) FILETIME=[45D1A770:01C43C29]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4HG91Ju082050
Sender: [e-mail]
Precedence: 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,
Another round will no longer than this is taking. Rather than read items
out of context, it is better to read the full proposal.
Trevor

* -----Original Message-----
* From: Denis Pinkas [mailto:[e-mail]]
* Sent: Monday, May 17, 2004 12:53 AM
* To: Trevor Freeman
* Cc: [e-mail]
* Subject: Re: SCVP & validation policies
* 
* Trevor,
* 
* > Hi Denis,
* 
* > As I said previous an OID is one of the possible options, but there
is
* > no consensus to make this mandatory so SCVP will continue to support
* > both options.
* 
* Making the OID optional as requested by Wen-Cheng Wang, does not
* necessarilly mean "supporting both options".
* 
* > I also don't see consensus that it is mandatory that a
* > SCVP server will always map a request back to the OID.
* 
* Many opinions, except one, are supporting this however.
* 
* > I will be posting SCVP 15 shortly so you can review the latest
draft.
* 
* An extract of the proposal sent to the mailing list and targeted to
this
* problem would probably save another round.
* 
* Denis
* 
* > Trevor
* >
* > -----Original Message-----
* > From: Denis Pinkas [mailto:[e-mail]]
* > Sent: Thursday, May 13, 2004 12:54 AM
* > To: Trevor Freeman
* > Cc: Florian Oelmaier; [e-mail]
* > Subject: Re: SCVP & validation policies
* >
* > Trevor,
* >
* > (text deleted)
* >
* > Florian said: "it is widespread consensus on this list that
* > this could be done with SCVP by the use of the OID as a reference
* > to the validation policy as the sole configuration item."
* >
* > I agree.
* >
* > To respond to a request from Wen-Cheng Wang, the OID of the
validation
* > policy should be optional in the request. However, if the OID of the
* > validation policy is not present in the request, then the OID of the
* > validation policy that has been used SHALL be returned by the SCVP
* > server in
* > the response. If the validation policy has dynamic parameters, then
* > these
* > parameters SHALL be returned too.
* >
* > Now, we need to move, Trevor.
* >
* > Would you propose in an e-mail extracts of an ASN.1 syntax that
would
* > accommodate these requirements for both the request and the
response,
* > focussing on the validation policy elements ?
* >
* > Thanks,
* >
* > Denis
* >
* > (text deleted)
* >
* >
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4HFNiKW078830; Mon, 17 May 2004 08:23:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4HFNiZj078829; Mon, 17 May 2004 08:23:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail19e.dulles19-verio.com (mail19e.dulles19-verio.com [198.170.241.12]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4HFNhQ4078823 for <[e-mail]>; Mon, 17 May 2004 08:23:43 -0700 (PDT) (envelope-from [e-mail])
Received: from www.geminisecurity.com (161.58.96.110) by mail19e.dulles19-verio.com (RS ver 1.0.92vs) with SMTP id 4-0863847424; Mon, 17 May 2004 11:23:45 -0400 (EDT)
From: "Peter Hesse" <[e-mail]>
To: "'PKIX List'" <[e-mail]>
Cc: "'Steve Hanna'" <[e-mail]>, "'Wen-Cheng Wang'" <[e-mail]>
Subject: RE: Comments on Path Building I-D
Date: Mon, 17 May 2004 11:23:45 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <00c101c43293$cfa00a90$4f85900a@wcwang>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-Index: AcQymwDrjoePWzQZSJe1V4Jui0XfqQJh8KFQ
Message-ID: <[e-mail]>
X-Loop-Detect: 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>

Wen-Cheng,

I will reply to your comments inline.

> After reading the certpathbuild draft and the comments from Steve 
> Hanna, my feeling is that this draft is more like a paper (or thesis) 
> than a PKIX specification. I believe that is why Steve criticized the 
> text of the draft as if he is a reviewer of a PKI paper. I really 
> admire the authors and Steve's rich and deep knowledge of optimization 
> and implementation technique for path building. I must confess that I 
> gained much from reading "the paper" and the comments from Steve. 
> However, I doubt whether it is suitable for the PKIX WG to publish 
> "the paper" as an RFC.
> I think the text of the draft is good enough to become a paper on a 
> PKI conference proceedings or even  on a journal.
> But, that does not mean it will be a good PKIX RFC.

This document is meant to serve as an informational document which
implementers can read and use to make intelligent decisions when building
their own implementation.  Unlike most PKIX RFCs, which are standards-track
RFCs, this document is not intended to be prescriptive.  If you read RFC
2026, section 4.2.2 about Informational RFCs, I believe you will agree that
this document fits the mold of an Informational RFC quite well.

> As a faithful reader of PKIX specifications, I would expect that if 
> the PKIX WG would like to publish an RFC entitled "Certification Path 
> Building" then its text should focus on:
> 
> 1. defining what is a legal certification path
>            Can certificates with names in different encoding be 
> chained?
>            Can certificates with unmached issuer name and subject name
>            be chained by matching SKID and AKID?

These issues are covered in the document, and both have been brought up on
this list as recommended additions to RFC 3280.

> 2. defining a algorithm for certification path building, also 
> including
>          specifying the inputs to the algorithm and
>          specifying the outputs from the algorithm

As I mentioned above, an informational RFC should not be so prescriptive

> 3. specifying the format of certificate/CRL extensions (e.g. SKID, 
> AKID,AIA, SIA, CRLDP...) that are related to certification path 
> building.
>     E.g.,
>            the URL format of different procols (such as LDAP, HTTP, 
> FTP...)
>            (e.g., Should the LDAP URL contains the ";binary" option?)

These extensions are already specified in RFC3280.  The specifics of the
formats of these values may be best captured in a "best-practices" document
which I have suggested (in my response to Steve) as an additional document
to be considered by the group.  Aside from the restrictions identified in
section 4.2.1.7 of RFC3280, I do not think the values can be constrained any
further.

> 4. specifying how a compliant implementation should process
>     theose certificate/CRL extensions related certification path 
> building

Again, this is specified by RFC3280, our document makes no attempt to change
the way any extensions or fields are processed, nor should it.

>5. specifying what is the minimum set of repository retrieving  
>protocols (such as LDAP, HTTP, FTP, SMTP...) a compliant  
>implementation sould support and how these protocols should be  
>supported. E.g., What is the expected object format?
>                     (e.g., DER binary vs.Base64-encoded)
>                What is the expected MIME type if HTTP is used?

Again, this is best suited for a "best-practices" document.  There need not
be any minimum set of protocols defined as a standard, but a list of best
practices could give guidance on what protocols were most commonly used.

> 6. discussing security consideration
> 
> I believe that the PKIX certpathbuild specification should specify a 
> baseline certification path building algorithm in the fashion of RFC 
> 3280 specifying a basic certification path validation algorithm. The 
> purpose of defining the algorithm is for precisely describe the 
> expected result of the certification path building.

RFC3280 section 3.2 has identified a starting point, which is a
certification path.  We have provided a way to get from nothing to obtaining
that certification path, after which time you can perform validation; a
procedure that RFC3280 is silent on.  There cannot be a basic algorithm for
building defined as a PKIX standard, because this would make any algorithms
not designed in this fashion non-standard.  RFC3280 section 3.2 provides
enough to give us the basic algorithm.
 
> There is no need for a PKIX
> specification to teach implementators the optimization and 
> implementation technique for path building. It is up to the 
> implementators themselves to choose their own the optimization and 
> implementation technique. Isn't it?

Yes, it is up to the implementors.  Our document provides a recommendation
on what makes a good path builder, with example scenarios and an example
implementation.  All throughout, the document makes it clear that the
implementor can take or leave any of the suggestions.

> Therefore, I would like to suggest the authors to complete remove the 
> section 3 of the current draft. It is not only because a PKIX 
> specification is not supposed to be a paper or textbook for teaching 
> the optimization and implementation technique for path building, but 
> also because the optimization and implementation technique described 
> in that section is not, as Steve said, the consensus of the PKIX WG.
> I suggest that the draft sould spend more space and time to cover the 
> areas I mentioned above.
> (I know the current draft already covers them, but I think it is still 
> not in-depth enough.)

As I mentioned above, I believe that RFC3280 already covers the majority of
these issues, and in addition, a new document may be created to provide
guidance on the best practices of certification path development utilities.
As I mentioned in my message to Steve, I would be happy to collaborate on
such a document.

--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.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4HDw1OL073125; Mon, 17 May 2004 06:58:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4HDw1fI073124; Mon, 17 May 2004 06:58:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk (ns3.worldcall.net.pk [203.81.192.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4HDvxqb073118 for <[e-mail]>; Mon, 17 May 2004 06:58:00 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertia3 ([203.81.202.25]) by ns3.worldcall.net.pk (8.12.11/8.12.11) with SMTP id i4HDsLOw003647; Mon, 17 May 2004 19:54:21 +0600 (PKST)
Message-ID: <011d01c43c17$5eaee0d0$[e-mail]>
From: "Yasir Khan" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Signature in OCSP Request
Date: Mon, 17 May 2004 19:00:53 +0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_011A_01C43C41.46BCB6D0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: 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_011A_01C43C41.46BCB6D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hello

I have a question about the signature field in OCSP request. What =
exactly should it contain and what=20
algorithms can be used for OCSP request signing?=20

When i create a signature using MS CAPI, OCSP reponders are unable to =
verify the signatures whereas we
can verify it using CAPI. What data do we set in signature field =
exactly?

Regards,

Yasir



------=_NextPart_000_011A_01C43C41.46BCB6D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT face=3DArial color=3D#800080 size=3D2>
<DIV><BR>Hello</DIV>
<DIV>&nbsp;</DIV>
<DIV>I have a question about the signature field in OCSP request. What =
exactly=20
should it contain and what <BR>algorithms can be used for OCSP request =
signing?=20
</DIV>
<DIV>&nbsp;</DIV>
<DIV>When i create a signature using MS CAPI, OCSP reponders are unable =
to=20
verify the signatures whereas we<BR>can verify it using CAPI. What data =
do we=20
set in signature field exactly?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>&nbsp;</DIV>
<DIV>Yasir</DIV>
<DIV>&nbsp;</DIV>
<DIV></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_011A_01C43C41.46BCB6D0--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4H7qmvS009805; Mon, 17 May 2004 00:52:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4H7qmPe009804; Mon, 17 May 2004 00:52:48 -0700 (PDT)
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.9) with ESMTP id i4H7ql4W009738 for <[e-mail]>; Mon, 17 May 2004 00:52:47 -0700 (PDT) (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 KAA29842; Mon, 17 May 2004 10:02:02 +0200
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 JAA24690; Mon, 17 May 2004 09:51:23 +0200
Message-ID: <[e-mail]>
Date: Mon, 17 May 2004 09:53:19 +0200
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: Trevor Freeman <[e-mail]>
CC: [e-mail]
Subject: Re: SCVP & validation policies
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>

Trevor,

> Hi Denis,

> As I said previous an OID is one of the possible options, but there is
> no consensus to make this mandatory so SCVP will continue to support
> both options. 

Making the OID optional as requested by Wen-Cheng Wang, does not 
necessarilly mean "supporting both options".

> I also don't see consensus that it is mandatory that a
> SCVP server will always map a request back to the OID.

Many opinions, except one, are supporting this however.

> I will be posting SCVP 15 shortly so you can review the latest draft.

An extract of the proposal sent to the mailing list and targeted to this 
problem would probably save another round.

Denis

> Trevor
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Thursday, May 13, 2004 12:54 AM
> To: Trevor Freeman
> Cc: Florian Oelmaier; [e-mail]
> Subject: Re: SCVP & validation policies
> 
> Trevor,
> 
> (text deleted)
> 
> Florian said: "it is widespread consensus on this list that
> this could be done with SCVP by the use of the OID as a reference
> to the validation policy as the sole configuration item."
> 
> I agree.
> 
> To respond to a request from Wen-Cheng Wang, the OID of the validation 
> policy should be optional in the request. However, if the OID of the 
> validation policy is not present in the request, then the OID of the 
> validation policy that has been used SHALL be returned by the SCVP
> server in 
> the response. If the validation policy has dynamic parameters, then
> these 
> parameters SHALL be returned too.
> 
> Now, we need to move, Trevor.
> 
> Would you propose in an e-mail extracts of an ASN.1 syntax that would 
> accommodate these requirements for both the request and the response, 
> focussing on the validation policy elements ?
> 
> Thanks,
> 
> Denis
> 
> (text deleted)
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4H5ellq062057; Sun, 16 May 2004 22:40:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4H5elDF062055; Sun, 16 May 2004 22:40:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns3.worldcall.net.pk (ns3.worldcall.net.pk [203.81.192.10]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4H5ej6E061928 for <[e-mail]>; Sun, 16 May 2004 22:40:46 -0700 (PDT) (envelope-from [e-mail])
Received: from ascertiafm ([203.81.202.25]) by ns3.worldcall.net.pk (8.12.11/8.12.11) with SMTP id i4H5b2CW014939 for <[e-mail]>; Mon, 17 May 2004 11:37:03 +0600 (PKST)
Message-ID: <004501c43bd1$e4778be0$[e-mail]>
From: "Faisal Maqsood" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Relationship between SAN and IAN?
Date: Mon, 17 May 2004 10:43:27 +0500
Organization: Ascertia Ltd
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01C43BFB.C96DC1A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
X-Scanned-By: MIMEDefang 2.39
Sender: [e-mail]
Precedence: 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_0042_01C43BFB.C96DC1A0
Content-Type: text/plain;
	charset="unicode"
Content-Transfer-Encoding: quoted-printable

=0D=00=0A=
=00-=00-=00-=00-=00-=00 =00O=00r=00i=00g=00i=00n=00a=00l=00 =
=00M=00e=00s=00s=00a=00g=00e=00 =00-=00-=00-=00-=00-=00 =00=0D=00=0A=
=00F=00r=00o=00m=00:=00 =00F=00a=00i=00s=00a=00l=00 =
=00M=00a=00q=00s=00o=00o=00d=00 =00=0D=00=0A=
=00T=00o=00:=00 =
=00i=00e=00t=00f=00-=00p=00k=00i=00x=00@=00i=00m=00c=00.=00o=00r=00g=00 =
=00=0D=00=0A=
=00S=00e=00n=00t=00:=00 =00T=00u=00e=00s=00d=00a=00y=00,=00 =
=00F=00e=00b=00r=00u=00a=00r=00y=00 =002=004=00,=00 =002=000=000=004=00 =
=001=001=00:=000=004=00=0D=00=0A=
=00S=00u=00b=00j=00e=00c=00t=00:=00 =
=00R=00e=00l=00a=00t=00i=00o=00n=00s=00h=00i=00p=00 =
=00b=00e=00t=00w=00e=00e=00n=00 =00S=00A=00N=00 =00a=00n=00d=00 =
=00I=00A=00N=00?=00=0D=00=0A=
=00=0D=00=0A=
=00=0D=00=0A=
=00H=00e=00l=00l=00o=00 =00F=00o=00l=00k=00s=00,=00=0D=00=0A=
=00=0D=00=0A=
=00I=00 =00h=00a=00v=00e=00 =00a=00 =00q=00u=00e=00r=00y=00 =
=00f=00o=00r=00 =00c=00l=00a=00r=00i=00f=00i=00c=00a=00t=00i=00o=00n=00 =
=00a=00n=00d=00 =00n=00e=00e=00d=00s=00 =00y=00o=00u=00r=00 =
=00v=00i=00e=00w=00s=00.=00=0D=00=0A=
=00L=00e=00t=00 =00u=00s=00 =00c=00o=00n=00s=00i=00d=00e=00r=00 =
=00t=00h=00e=00r=00e=00 =00a=00r=00e=00 =00t=00w=00o=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00s=00 =00A=00 =
=00a=00n=00d=00 =00B=00 =00(=00p=00a=00r=00t=00 =00o=00f=00 =
=00t=00h=00e=00 =00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00i=00o=00n=00 =
=00p=00a=00t=00h=00)=00.=00 =00=0D=00=0A=
=00 =00 =00a=00.=00.=00 =00I=00f=00 =00A=00 =00i=00s=00 =
=00i=00s=00s=00u=00e=00r=00 =00o=00f=00 =00B=00 =00a=00n=00d=00 =
=00t=00h=00e=00r=00e=00 =00i=00s=00 =
=00S=00u=00b=00j=00e=00c=00t=00A=00l=00t=00N=00a=00m=00e=00 =
=00e=00x=00t=00e=00n=00s=00i=00o=00n=00 =00p=00r=00e=00s=00e=00n=00t=00 =
=00i=00n=00 =00A=00 =00a=00n=00d=00 =
=00I=00s=00s=00u=00e=00r=00A=00l=00t=00N=00a=00m=00e=00 =00i=00n=00 =
=00B=00 =00a=00n=00d=00 =00v=00a=00l=00u=00e=00 =00o=00f=00 =
=00S=00u=00b=00j=00e=00c=00t=00A=00l=00t=00N=00a=00m=00e=00 =00i=00n=00 =
=00A=00 =00i=00s=00 =
=00"=00U=00R=00L=00=3D=00h=00t=00t=00p=00:=00/=00/=00w=00w=00w=00.=00t=00=
e=00s=00t=00s=00e=00r=00v=00e=00r=00n=00a=00m=00e=00.=00c=00o=00m=00"=00.=
=00 =00I=00s=00 =00t=00h=00e=00r=00e=00 =00a=00n=00y=00 =
=00r=00e=00q=00u=00i=00r=00e=00m=00e=00n=00t=00 =00i=00n=00 =
=00R=00F=00C=00 =002=004=005=009=00 =00o=00r=00 =003=002=008=000=00 =
=00o=00r=00 =00s=00o=00m=00e=00 =00w=00h=00e=00r=00e=00 =
=00e=00l=00s=00e=00 =00f=00o=00r=00 =
=00I=00s=00s=00u=00e=00r=00A=00l=00t=00N=00a=00m=00e=00 =
=00v=00a=00l=00u=00e=00 =00(=00i=00f=00 =
=00p=00r=00e=00s=00e=00n=00t=00)=00 =00i=00n=00 =00B=00.=00 =00I=00 =
=00m=00e=00a=00n=00 =00i=00n=00 =00t=00h=00i=00s=00 =00c=00a=00s=00e=00 =
=00I=00s=00s=00u=00e=00r=00A=00l=00t=00N=00a=00m=00e=00 =
=00v=00a=00l=00u=00e=00 =00m=00u=00s=00t=00 =
=00c=00o=00n=00t=00a=00i=00n=00 =
=00"=00U=00R=00L=00=3D=00h=00t=00t=00p=00:=00/=00/=00w=00w=00w=00.=00t=00=
e=00s=00t=00s=00e=00r=00v=00e=00r=00n=00a=00m=00e=00.=00c=00o=00m=00"=00?=
=00 =00=0D=00=0A=
=00 =00 =00b=00.=00.=00 =00S=00i=00m=00i=00l=00a=00r=00 =
=00q=00u=00e=00r=00y=00 =00f=00o=00r=00 =
=00S=00u=00b=00j=00e=00c=00t=00K=00e=00y=00I=00d=00e=00n=00t=00i=00f=00i=00=
e=00r=00 =00a=00n=00d=00 =
=00A=00u=00t=00h=00o=00r=00i=00t=00y=00K=00e=00y=00I=00d=00e=00n=00t=00i=00=
f=00i=00e=00r=00 =00t=00h=00a=00t=00 =00i=00f=00 =
=00S=00u=00b=00j=00e=00c=00t=00K=00e=00y=00I=00d=00e=00n=00t=00i=00f=00i=00=
e=00r=00 =00v=00a=00l=00u=00e=00 =00i=00s=00 =00o=00f=00 =
=006=000=00-=00b=00i=00t=00 =00l=00e=00n=00g=00t=00h=00 =00i=00n=00 =
=00A=00.=00 =00I=00s=00 =00R=00F=00C=00 =00a=00l=00l=00o=00w=00s=00 =
=00t=00o=00 =00p=00u=00t=00 =
=00A=00u=00t=00h=00o=00r=00i=00t=00y=00K=00e=00y=00I=00d=00e=00n=00t=00i=00=
f=00i=00e=00r=00 =00v=00a=00l=00u=00e=00 =00o=00f=00 =
=001=006=000=00-=00b=00i=00t=00 =00l=00e=00n=00g=00t=00h=00 =00i=00n=00 =
=00B=00?=00=0D=00=0A=
=00R=00e=00g=00a=00r=00d=00s=00,=00=0D=00=0A=
=00F=00a=00i=00s=00a=00l=00 =00M=00a=00q=00s=00o=00o=00d=00=0D=00=0A=
=00
------=_NextPart_000_0042_01C43BFB.C96DC1A0
Content-Type: text/html;
	charset="unicode"
Content-Transfer-Encoding: quoted-printable

=FF=FE<=00!=00D=00O=00C=00T=00Y=00P=00E=00 =00H=00T=00M=00L=00 =
=00P=00U=00B=00L=00I=00C=00 =
=00"=00-=00/=00/=00W=003=00C=00/=00/=00D=00T=00D=00 =00H=00T=00M=00L=00 =
=004=00.=000=00 =
=00T=00r=00a=00n=00s=00i=00t=00i=00o=00n=00a=00l=00/=00/=00E=00N=00"=00>=00=
=0D=00=0A=
=00<=00H=00T=00M=00L=00>=00<=00H=00E=00A=00D=00>=00=0D=00=0A=
=00<=00M=00E=00T=00A=00 =
=00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00t=00e=00x=00t=00/=00h=00t=00m=00=
l=00;=00 =
=00c=00h=00a=00r=00s=00e=00t=00=3D=00u=00n=00i=00c=00o=00d=00e=00"=00 =
=00h=00t=00t=00p=00-=00e=00q=00u=00i=00v=00=3D=00C=00o=00n=00t=00e=00n=00=
t=00-=00T=00y=00p=00e=00>=00<=00B=00A=00S=00E=00 =00=0D=00=0A=
=00h=00r=00e=00f=00=3D=00"=00f=00i=00l=00e=00:=00/=00/=00F=00:=00\=00_=00=
B=00a=00c=00k=00U=00p=00-=00F=00M=00\=00E=00m=00a=00i=00l=00 =
=00S=00i=00g=00n=00a=00t=00u=00r=00e=00\=00"=00>=00<=00!=00D=00O=00C=00T=00=
Y=00P=00E=00 =00H=00T=00M=00L=00 =00P=00U=00B=00L=00I=00C=00 =
=00"=00-=00/=00/=00W=003=00C=00/=00/=00D=00T=00D=00 =00H=00T=00M=00L=00 =
=004=00.=000=00 =
=00T=00r=00a=00n=00s=00i=00t=00i=00o=00n=00a=00l=00/=00/=00E=00N=00"=00>=00=
=0D=00=0A=
=00<=00M=00E=00T=00A=00 =
=00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00M=00S=00H=00T=00M=00L=00 =
=005=00.=000=000=00.=003=005=000=002=00.=005=003=009=000=00"=00 =
=00n=00a=00m=00e=00=3D=00G=00E=00N=00E=00R=00A=00T=00O=00R=00>=00=0D=00=0A=
=00<=00M=00E=00T=00A=00 =
=00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00M=00S=00H=00T=00M=00L=00 =
=005=00.=000=000=00.=003=005=000=002=00.=005=003=009=000=00"=00 =
=00n=00a=00m=00e=00=3D=00G=00E=00N=00E=00R=00A=00T=00O=00R=00>=00=0D=00=0A=
=00<=00S=00T=00Y=00L=00E=00>=00<=00/=00S=00T=00Y=00L=00E=00>=00=0D=00=0A=
=00=0D=00=0A=
=00<=00M=00E=00T=00A=00 =
=00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00M=00S=00H=00T=00M=00L=00 =
=005=00.=000=000=00.=003=005=000=002=00.=005=003=009=000=00"=00 =
=00n=00a=00m=00e=00=3D=00G=00E=00N=00E=00R=00A=00T=00O=00R=00>=00<=00/=00=
H=00E=00A=00D=00>=00=0D=00=0A=
=00<=00B=00O=00D=00Y=00 =
=00b=00g=00C=00o=00l=00o=00r=00=3D=00#=00f=00f=00f=00f=00f=00f=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00 =
=00s=00t=00y=00l=00e=00=3D=00"=00F=00O=00N=00T=00:=00 =
=001=000=00p=00t=00 =00a=00r=00i=00a=00l=00"=00>=00-=00-=00-=00-=00-=00 =
=00O=00r=00i=00g=00i=00n=00a=00l=00 =00M=00e=00s=00s=00a=00g=00e=00 =
=00-=00-=00-=00-=00-=00 =00=0D=00=0A=
=00<=00D=00I=00V=00 =
=00s=00t=00y=00l=00e=00=3D=00"=00B=00A=00C=00K=00G=00R=00O=00U=00N=00D=00=
:=00 =00#=00e=004=00e=004=00e=004=00;=00 =
=00f=00o=00n=00t=00-=00c=00o=00l=00o=00r=00:=00 =
=00b=00l=00a=00c=00k=00"=00>=00<=00B=00>=00F=00r=00o=00m=00:=00<=00/=00B=00=
>=00 =00<=00A=00 =00=0D=00=0A=
=00h=00r=00e=00f=00=3D=00"=00m=00a=00i=00l=00t=00o=00:=00f=00a=00i=00s=00=
a=00l=00.=00m=00a=00q=00s=00o=00o=00d=00@=00a=00s=00c=00e=00r=00t=00i=00a=
=00.=00c=00o=00m=00"=00 =00=0D=00=0A=
=00t=00i=00t=00l=00e=00=3D=00f=00a=00i=00s=00a=00l=00.=00m=00a=00q=00s=00=
o=00o=00d=00@=00a=00s=00c=00e=00r=00t=00i=00a=00.=00c=00o=00m=00>=00F=00a=
=00i=00s=00a=00l=00 =00M=00a=00q=00s=00o=00o=00d=00<=00/=00A=00>=00 =
=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00<=00B=00>=00T=00o=00:=00<=00/=00B=00>=00 =
=00<=00A=00 =
=00h=00r=00e=00f=00=3D=00"=00m=00a=00i=00l=00t=00o=00:=00i=00e=00t=00f=00=
-=00p=00k=00i=00x=00@=00i=00m=00c=00.=00o=00r=00g=00"=00 =00=0D=00=0A=
=00t=00i=00t=00l=00e=00=3D=00i=00e=00t=00f=00-=00p=00k=00i=00x=00@=00i=00=
m=00c=00.=00o=00r=00g=00>=00i=00e=00t=00f=00-=00p=00k=00i=00x=00@=00i=00m=
=00c=00.=00o=00r=00g=00<=00/=00A=00>=00 =00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00<=00B=00>=00S=00e=00n=00t=00:=00<=00/=00B=00>=00 =
=00T=00u=00e=00s=00d=00a=00y=00,=00 =00F=00e=00b=00r=00u=00a=00r=00y=00 =
=002=004=00,=00 =002=000=000=004=00 =
=001=001=00:=000=004=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00<=00B=00>=00S=00u=00b=00j=00e=00c=00t=00:=00<=00/=00=
B=00>=00 =00R=00e=00l=00a=00t=00i=00o=00n=00s=00h=00i=00p=00 =
=00b=00e=00t=00w=00e=00e=00n=00 =00S=00A=00N=00 =00a=00n=00d=00 =
=00I=00A=00N=00?=00<=00/=00D=00I=00V=00>=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00<=00B=00R=00>=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00H=00e=00l=00l=00o=00 =
=00F=00o=00l=00k=00s=00,=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00&=00n=00b=00s=00p=00;=00<=00/=00D=00I=00V=00>=00=0D=
=00=0A=
=00<=00D=00I=00V=00>=00I=00 =00h=00a=00v=00e=00 =00a=00 =
=00q=00u=00e=00r=00y=00 =00f=00o=00r=00 =
=00c=00l=00a=00r=00i=00f=00i=00c=00a=00t=00i=00o=00n=00 =00a=00n=00d=00 =
=00n=00e=00e=00d=00s=00&=00n=00b=00s=00p=00;=00y=00o=00u=00r=00 =
=00v=00i=00e=00w=00s=00.=00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00L=00e=00t=00 =00u=00s=00 =
=00c=00o=00n=00s=00i=00d=00e=00r=00 =00t=00h=00e=00r=00e=00 =
=00a=00r=00e=00 =00t=00w=00o=00 =
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00e=00s=00 =00A=00 =
=00a=00n=00d=00 =00B=00 =00(=00p=00a=00r=00t=00 =00o=00f=00 =
=00t=00h=00e=00 =00=0D=00=0A=
=00c=00e=00r=00t=00i=00f=00i=00c=00a=00t=00i=00o=00n=00 =
=00p=00a=00t=00h=00)=00.=00 =00<=00/=00D=00I=00V=00>=00=0D=00=0A=
=00<=00U=00L=00>=00=0D=00=0A=
=00 =00 =00<=00L=00I=00>=00I=00f=00 =00A=00 =00i=00s=00 =
=00i=00s=00s=00u=00e=00r=00 =00o=00f=00 =00B=00 =00a=00n=00d=00 =
=00t=00h=00e=00r=00e=00 =00i=00s=00 =
=00S=00u=00b=00j=00e=00c=00t=00A=00l=00t=00N=00a=00m=00e=00 =
=00e=00x=00t=00e=00n=00s=00i=00o=00n=00 =00p=00r=00e=00s=00e=00n=00t=00 =
=00i=00n=00 =00A=00 =00a=00n=00d=00 =00=0D=00=0A=
=00 =00 =00I=00s=00s=00u=00e=00r=00A=00l=00t=00N=00a=00m=00e=00 =
=00i=00n=00 =00B=00 =00a=00n=00d=00 =00v=00a=00l=00u=00e=00 =00o=00f=00 =
=00S=00u=00b=00j=00e=00c=00t=00A=00l=00t=00N=00a=00m=00e=00 =00i=00n=00 =
=00A=00 =00i=00s=00 =00=0D=00=0A=
=00 =00 =
=00"=00U=00R=00L=00=3D=00h=00t=00t=00p=00:=00/=00/=00w=00w=00w=00.=00t=00=
e=00s=00t=00s=00e=00r=00v=00e=00r=00n=00a=00m=00e=00.=00c=00o=00m=00"=00.=
=00 =00I=00s=00 =00t=00h=00e=00r=00e=00 =00a=00n=00y=00 =
=00r=00e=00q=00u=00i=00r=00e=00m=00e=00n=00t=00 =00i=00n=00 =
=00R=00F=00C=00 =002=004=005=009=00 =00o=00r=00 =00=0D=00=0A=
=00 =00 =003=002=008=000=00 =00o=00r=00 =00s=00o=00m=00e=00 =
=00w=00h=00e=00r=00e=00 =00e=00l=00s=00e=00 =00f=00o=00r=00 =
=00I=00s=00s=00u=00e=00r=00A=00l=00t=00N=00a=00m=00e=00 =
=00v=00a=00l=00u=00e=00 =00(=00i=00f=00 =
=00p=00r=00e=00s=00e=00n=00t=00)=00 =00i=00n=00 =00B=00.=00 =00I=00 =
=00m=00e=00a=00n=00 =00i=00n=00 =00=0D=00=0A=
=00 =00 =00t=00h=00i=00s=00 =00c=00a=00s=00e=00 =
=00I=00s=00s=00u=00e=00r=00A=00l=00t=00N=00a=00m=00e=00 =
=00v=00a=00l=00u=00e=00 =00m=00u=00s=00t=00 =
=00c=00o=00n=00t=00a=00i=00n=00 =00=0D=00=0A=
=00 =00 =
=00"=00U=00R=00L=00=3D=00h=00t=00t=00p=00:=00/=00/=00w=00w=00w=00.=00t=00=
e=00s=00t=00s=00e=00r=00v=00e=00r=00n=00a=00m=00e=00.=00c=00o=00m=00"=00?=
=00 =00=0D=00=0A=
=00 =00 =00<=00L=00I=00>=00S=00i=00m=00i=00l=00a=00r=00 =
=00q=00u=00e=00r=00y=00 =00f=00o=00r=00 =
=00S=00u=00b=00j=00e=00c=00t=00K=00e=00y=00I=00d=00e=00n=00t=00i=00f=00i=00=
e=00r=00 =00a=00n=00d=00 =
=00A=00u=00t=00h=00o=00r=00i=00t=00y=00K=00e=00y=00I=00d=00e=00n=00t=00i=00=
f=00i=00e=00r=00 =00t=00h=00a=00t=00 =00i=00f=00 =00=0D=00=0A=
=00 =00 =
=00S=00u=00b=00j=00e=00c=00t=00K=00e=00y=00I=00d=00e=00n=00t=00i=00f=00i=00=
e=00r=00 =00v=00a=00l=00u=00e=00 =00i=00s=00 =00o=00f=00 =
=006=000=00-=00b=00i=00t=00 =00l=00e=00n=00g=00t=00h=00 =00i=00n=00 =
=00A=00.=00 =00I=00s=00 =00R=00F=00C=00 =00a=00l=00l=00o=00w=00s=00 =
=00t=00o=00 =00p=00u=00t=00 =00=0D=00=0A=
=00 =00 =
=00A=00u=00t=00h=00o=00r=00i=00t=00y=00K=00e=00y=00I=00d=00e=00n=00t=00i=00=
f=00i=00e=00r=00 =00v=00a=00l=00u=00e=00 =00o=00f=00 =
=001=006=000=00-=00b=00i=00t=00 =00l=00e=00n=00g=00t=00h=00 =00i=00n=00 =
=00B=00?=00<=00/=00L=00I=00>=00<=00/=00U=00L=00>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00R=00e=00g=00a=00r=00d=00s=00,=00<=00/=00D=00I=00V=00=
>=00=0D=00=0A=
=00<=00D=00I=00V=00>=00F=00a=00i=00s=00a=00l=00 =
=00M=00a=00q=00s=00o=00o=00d=00<=00/=00D=00I=00V=00>=00<=00/=00B=00O=00D=00=
Y=00>=00<=00/=00H=00T=00M=00L=00>=00=0D=00=0A=
=00
------=_NextPart_000_0042_01C43BFB.C96DC1A0--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4FHGblf029735; Sat, 15 May 2004 10:16:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4FHGb47029734; Sat, 15 May 2004 10:16:37 -0700 (PDT)
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.11/8.12.9) with ESMTP id i4FHGaPN029728 for <[e-mail]>; Sat, 15 May 2004 10:16:36 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i4FHGcN04929; Sat, 15 May 2004 19:16:38 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Sat, 15 May 2004 19:16:38 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i4FHGbN27237; Sat, 15 May 2004 19:16:37 +0200 (MEST)
Date: Sat, 15 May 2004 19:16:37 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP & validation policies
Cc: [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>

> [TF] Nice ideal, but Administrators of all descriptions make security
> related decisions.
As long as we continue with innovation prohibiting companies. :-) 

> [TF] Having the client be unaware that relay happened still seems a
> desirable simplification. All it takes is the server to process the rely
> reply. I am OK with including an SVVP response from another server for
> third party accountability, but not if the client is expected to process
> the embedded SCVP response.

I tend to agree. depends somewhat on the definition of 'process', clients
also do not process OCSP responses or time stamps, do they?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4EJRcqC055534; Fri, 14 May 2004 12:27:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4EJRcch055533; Fri, 14 May 2004 12:27:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4EJRbM6055527 for <[e-mail]>; Fri, 14 May 2004 12:27:37 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 14 May 2004 12:27:41 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 14 May 2004 12:27:41 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 May 2004 12:27:41 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP & validation policies
Date: Fri, 14 May 2004 12:27:40 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
thread-index: AcQ52FzIFTMYA/QuTnmfrVxJuCeKgAAD2+Yg
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 14 May 2004 19:27:41.0555 (UTC) FILETIME=[863D6430:01C439E9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4EJRbM6055528
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Friday, May 14, 2004 10:25 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: RE: SCVP & validation policies
* 
* 
* >
* >   [TF] One administrator can defile a policy and that policy can
consist
* > of n parameters living in some kind of object (XML in a file store,
* > attributes in a directory etc). Other administrators do not need to
be
* > intimately aware of the content of that object to use object, they
just
* > need a pointer which they can use. Therefore the number of
parameters in
* > the object is irrelevant. There is generally a perception that any
* > policy change has to be applied in a reasonable timeframe therefore
any
* > policy management system has regularly check for updates therefore
* > frequency of updates tends not to be a issue either. However I
really
* > don't expect SCVP policy of any type to have significant churn.
* 
* Policy changes are not to be applied by any workflow application
* administrator,
* i.e. client administrator. They are made by the security
administrator.
[TF] Nice ideal, but Administrators of all descriptions make security
related decisions.

* 
* > * But since you have responsed positively to Denis, I may
* > * not even understand what you are saying.
* 
* Well, since you have already agreed that it is posssible just to use a
* policy oid
* there is no need to discuss further whether the alternative is good,
* useful, practical or whatever.
* 
* > *
* > * Since three drafts, the whole text is unimplementable,
* > * i.e. almost a year, ...), so the following list of some
* > * (to me) open questions is not necessariy complete.
* > *
* > * - in what way a relay scvp can include an answer from another scvp
* > *   server? please allow to have a place for this. Just provide for
* > *   example a 'content-info' as a placeholder for time stamps, scvp
* > *   responses.
* 
* > [TF] Up to now one of our objective was to hide any complexity that
may
* > arise out of relay. There is also no guaranteed correlation between
* > relayed requests. A client may make a DPV request and the server may
* > intern make a DPD request to another SCVP server so embedding the
DPD
* > response to he DPV request is on no value.
* 
* inverse logic A ==> B is not the same as  not A ==> not B
* the fact that you may find one case where is doesn't make sense
* to include a response, doesn't mean that it never makes sense.
* And in the given example, in particular when there is no
* correlation, who can the realy prove that it has provided
* his a particular response based on whatever other response?
[TF] Having the client be unaware that relay happened still seems a
desirable simplification. All it takes is the server to process the rely
reply. I am OK with including an SVVP response from another server for
third party accountability, but not if the client is expected to process
the embedded SCVP response.

* 
* 
* 'our objective'? RFC 3379 says:
* 
*    The DPV request MUST allow the client to request that the server
*    include in its response additional information which will allow
*    relying parties not trusting the DPV server to be confident that
the
*    certificate validation has correctly been performed.  Such
*    information may (not necessarily exclusively) consist of a
*    certification path, revocation status information from authorized
CRL
*    issuers or authorized OCSP responders, revocation status
information
*    from CRL issuers or OCSP responders trusted under the validation
*    policy, time-stamp tokens from TSAs responders trusted under the
*    validation policy, or a DPV response from a DPV server that is
*                       XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
* 
*    trusted under the validation policy.  When the certificate is valid
*    according to the validation policy, the server MUST, upon request,
*    include that information in the response.  However, the server MAY
*    omit that information when the certificate is invalid or when it
*    cannot determine the validity.
* 
* > *
* > * - Is the Nonce field the response to the following req:
* > *
* > *    The DPV server MUST be able, upon request, copy a text field
* > provided
* > *    by the client into the DPV response.  As an example, this field
may
* > *    relate to the nature or reason for the DPV query.
* 
* ???? no answer?
[TF] The nonce is there to bind the request to the response.
* 
* > *
* > * - I'd like to know what others think about my compromise proposal
* > *   for requestor/responder.
* > *
* ???? no answer?
* 
* > * - I have some feeling that there are at least some different
* > * interpretation
* > *   of policies and object identifiers validation algoritithms, etc.
* > *
* > *   - OIDs used for a configuration
* > *   - oids to reference some globally recognised rules
* > *   - oids to define sysntaxes of validation algorihms.
* > [TF] Yes I have been thinking that an OID alone is to restrictive.
* 
* You already have for example a validation algorithm OID for
* name validation (like the qulifiers in Policyinfo)
* plus the required necessary parameters together with
* the configuration policy OID.
* 
* > Others may want to use a URL to point to a policy so we need a
couple of
* > built in choices plus an extension mechanism for other to define
other
* > reference types.
* 
* More than the qualifier logic in the PolicyInfo?
* 
* > *
* > * - It is not clear to me whether for example the name matching
* > algorithm
* > *   is at the right level of abstraction. I'd rather have an
* > *   algorithm that say: 'Can this cert be used for this keypurpose,
* > *   for the following names.' It maybe not useful to
* > *   burden the client with the details of adding keyusage and
* > *   compatible extendedkeyusage.
* > [TF] I was specially asked to do the name matching example because
it is
* > widely used today. I am sure others can submit other policy example
as
* > separate IDs.
* 
* I agree fully that the there is some good purpose of this kind of
* algorithm.
* I am just wondering whether the EXAMPLE specification is sufficiently
* well defined. Looks like may ask for three quarks with
* keyusage, extendedkeyusage and validation algorithm instead
* of asking for some more obvious atomic things.
* 
* If I am an ssl client or server, I simply don't care whether the
* actual certificate has whatever key usages or so, I just want a yes/no
* answer and maybe a path for logging. I just give the set of
* names and certs,
* 
* Do we need to distinguish email-protection certs for signing and
* encryption?
[TF] If you want to provide another example you can do so in another
draft.
* 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4EHvneC048878; Fri, 14 May 2004 10:57:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4EHvnCk048877; Fri, 14 May 2004 10:57:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4EHvmY7048858 for <[e-mail]>; Fri, 14 May 2004 10:57:48 -0700 (PDT) (envelope-from [e-mail])
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i4EHvjYd644888; Fri, 14 May 2004 13:57:45 -0400
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4EHwI2q110506; Fri, 14 May 2004 13:58:19 -0400
To: "Al Arsenault" <[e-mail]>
Cc: "Anders Rundgren" <[e-mail]>, "David P. Kemp" <[e-mail]>, [e-mail]
MIME-Version: 1.0
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-08.txt
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 14 May 2004 13:57:41 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.2CF2 HFB2|May 5, 2004) at 05/14/2004 13:57:44, Serialize complete at 05/14/2004 13:57:44
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>

        Al:

        The serialNumber attribute is not expected to contain the 
certificate serial number.  In its original definition it was supposed to 
contain the serial number of a piece of physical equipment, and it's 
defined to be a string rather than an integer like the certificate serial 
number.  There was a lot of discussion about which field to use for 
national identity numbers back in the fall of '99 as part of QC (see the 
thread of http://www.imc.org/ietf-pkix/old-archive-99/msg03041.html for an example), and the use is reflected in RFC 3739 section 3.1.2 (and 
also in the corresponding section of RFC 3039).
        IMHO, PI is better than this use of serialNumber, but serialNumber 
is not as unacceptable as it would be if it were supposed to match the 
certificate serial number.

                Tom Gindin





"Al Arsenault" <[e-mail]>
Sent by: [e-mail]
05/12/2004 09:30 PM

 
        To:     "Anders Rundgren" <[e-mail]>, "David P. Kemp" 
<[e-mail]>, <[e-mail]>
        cc: 
        Subject:        RE: I-D ACTION:draft-ietf-pkix-pi-08.txt






> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Anders Rundgren
> Sent: Wednesday, May 12, 2004 5:01 PM
> To: David P. Kemp; [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
> 
> 
> 
> >It is my hope that PI will become an RFC in the near future, so
> >that certificates (from an un-named large PKI :-) that currently
> >handle PIs by munging them into Common Name (e.g.,
> >CN="Kemp.David.P.0514101404") will have a saner alternative.
> 
> The de-facto standard, already engraved in *millions* of certs is
> putting 0514101404 in serialNumber. 
> 
> 

The problem with that is that "0514101404" is not expected to change; it's 
a number which stays with you as long as you're an employee of the 
company, or as long as you're a customer, or even all of your life.

The serialNumber is expected to change every time the certificate changes 
- commonly, when a certificate expires once a year, the new certificate 
has a new serialNumber.  It's considered seriously bad form to issue a 
"renewed" certificate with a different validity period and the same 
serialNumber.

Thus, those who put 0514101404 in "serialNumber" are just setting 
themselves up for trouble later on down the road.

(And as I've pointed out numerous times before, I know of organizations 
that put the equivalent of "0514101404" in subjectAltName, as a DNS Name! 
It's certainly possible, but that doesn't make it the "right thing" to do.

                                                 Al Arsenault



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4EHOf0i045445; Fri, 14 May 2004 10:24:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4EHOfra045444; Fri, 14 May 2004 10:24:41 -0700 (PDT)
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.11/8.12.9) with ESMTP id i4EHOdML045437 for <[e-mail]>; Fri, 14 May 2004 10:24:40 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i4EHOgN21923; Fri, 14 May 2004 19:24:42 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 14 May 2004 19:24:42 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i4EHOfK24575; Fri, 14 May 2004 19:24:41 +0200 (MEST)
Date: Fri, 14 May 2004 19:24:41 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP & validation policies
Cc: [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>

> 
>   [TF] One administrator can defile a policy and that policy can consist
> of n parameters living in some kind of object (XML in a file store,
> attributes in a directory etc). Other administrators do not need to be
> intimately aware of the content of that object to use object, they just
> need a pointer which they can use. Therefore the number of parameters in
> the object is irrelevant. There is generally a perception that any
> policy change has to be applied in a reasonable timeframe therefore any
> policy management system has regularly check for updates therefore
> frequency of updates tends not to be a issue either. However I really
> don't expect SCVP policy of any type to have significant churn.   

Policy changes are not to be applied by any workflow application administrator,
i.e. client administrator. They are made by the security administrator.

> * But since you have responsed positively to Denis, I may
> * not even understand what you are saying.

Well, since you have already agreed that it is posssible just to use a policy oid
there is no need to discuss further whether the alternative is good,
useful, practical or whatever. 

> * 
> * Since three drafts, the whole text is unimplementable,
> * i.e. almost a year, ...), so the following list of some
> * (to me) open questions is not necessariy complete.
> * 
> * - in what way a relay scvp can include an answer from another scvp
> *   server? please allow to have a place for this. Just provide for
> *   example a 'content-info' as a placeholder for time stamps, scvp
> *   responses.

> [TF] Up to now one of our objective was to hide any complexity that may
> arise out of relay. There is also no guaranteed correlation between
> relayed requests. A client may make a DPV request and the server may
> intern make a DPD request to another SCVP server so embedding the DPD
> response to he DPV request is on no value.

inverse logic A ==> B is not the same as  not A ==> not B
the fact that you may find one case where is doesn't make sense
to include a response, doesn't mean that it never makes sense.
And in the given example, in particular when there is no
correlation, who can the realy prove that it has provided
his a particular response based on whatever other response?  


'our objective'? RFC 3379 says: 

   The DPV request MUST allow the client to request that the server
   include in its response additional information which will allow
   relying parties not trusting the DPV server to be confident that the
   certificate validation has correctly been performed.  Such
   information may (not necessarily exclusively) consist of a
   certification path, revocation status information from authorized CRL
   issuers or authorized OCSP responders, revocation status information
   from CRL issuers or OCSP responders trusted under the validation
   policy, time-stamp tokens from TSAs responders trusted under the
   validation policy, or a DPV response from a DPV server that is
                      XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

   trusted under the validation policy.  When the certificate is valid
   according to the validation policy, the server MUST, upon request,
   include that information in the response.  However, the server MAY
   omit that information when the certificate is invalid or when it
   cannot determine the validity.

> * 
> * - Is the Nonce field the response to the following req:
> * 
> *    The DPV server MUST be able, upon request, copy a text field
> provided
> *    by the client into the DPV response.  As an example, this field may
> *    relate to the nature or reason for the DPV query.

???? no answer?

> * 
> * - I'd like to know what others think about my compromise proposal
> *   for requestor/responder.
> * 
???? no answer?

> * - I have some feeling that there are at least some different
> * interpretation
> *   of policies and object identifiers validation algoritithms, etc.
> * 
> *   - OIDs used for a configuration
> *   - oids to reference some globally recognised rules
> *   - oids to define sysntaxes of validation algorihms.
> [TF] Yes I have been thinking that an OID alone is to restrictive.

You already have for example a validation algorithm OID for
name validation (like the qulifiers in Policyinfo)
plus the required necessary parameters together with
the configuration policy OID.  

> Others may want to use a URL to point to a policy so we need a couple of
> built in choices plus an extension mechanism for other to define other
> reference types.

More than the qualifier logic in the PolicyInfo? 

> * 
> * - It is not clear to me whether for example the name matching
> algorithm
> *   is at the right level of abstraction. I'd rather have an
> *   algorithm that say: 'Can this cert be used for this keypurpose,
> *   for the following names.' It maybe not useful to
> *   burden the client with the details of adding keyusage and
> *   compatible extendedkeyusage.
> [TF] I was specially asked to do the name matching example because it is
> widely used today. I am sure others can submit other policy example as
> separate IDs.

I agree fully that the there is some good purpose of this kind of algorithm. 
I am just wondering whether the EXAMPLE specification is sufficiently
well defined. Looks like may ask for three quarks with
keyusage, extendedkeyusage and validation algorithm instead
of asking for some more obvious atomic things.

If I am an ssl client or server, I simply don't care whether the
actual certificate has whatever key usages or so, I just want a yes/no
answer and maybe a path for logging. I just give the set of
names and certs, 

Do we need to distinguish email-protection certs for signing and encryption?
    



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4EGZTkt040569; Fri, 14 May 2004 09:35:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4EGZTP7040568; Fri, 14 May 2004 09:35:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4EGZSZl040562 for <[e-mail]>; Fri, 14 May 2004 09:35:28 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 14 May 2004 09:35:31 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 14 May 2004 09:35:31 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 May 2004 09:35:31 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP & validation policies
Date: Fri, 14 May 2004 09:35:30 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
thread-index: AcQ5nekTcjzm3b/iRXuObxRCkpNsmgAMIXUw
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 14 May 2004 16:35:31.0867 (UTC) FILETIME=[794416B0:01C439D1]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4EGZTZl040563
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

See below

* -----Original Message-----
* From: Peter Sylvester [mailto:[e-mail]]
* Sent: Friday, May 14, 2004 3:26 AM
* To: [e-mail]; Trevor Freeman
* Cc: [e-mail]
* Subject: RE: SCVP & validation policies
* 
* > Hi Peter,
* > The problem of having to push policy to clients of all descriptions
is a
* > well understood problem set. The infrastructure to do that is the
main
* > overhead. The number of parameters associated with that process is
not a
* > significant overhead.
* 
* You don't push parameters that are subject to change, you need to
handle
* updates, if you configure one id, the problem of updates is gone.
* 
* Whenever you can remove one parameter, you significantly reduce
* the potential problem space (about divide it at least by 2)

  [TF] One administrator can defile a policy and that policy can consist
of n parameters living in some kind of object (XML in a file store,
attributes in a directory etc). Other administrators do not need to be
intimately aware of the content of that object to use object, they just
need a pointer which they can use. Therefore the number of parameters in
the object is irrelevant. There is generally a perception that any
policy change has to be applied in a reasonable timeframe therefore any
policy management system has regularly check for updates therefore
frequency of updates tends not to be a issue either. However I really
don't expect SCVP policy of any type to have significant churn.   

* 
* But since you have responsed positively to Denis, I may
* not even understand what you are saying.
* 
* Since three drafts, the whole text is unimplementable,
* i.e. almost a year, ...), so the following list of some
* (to me) open questions is not necessariy complete.
* 
* - in what way a relay scvp can include an answer from another scvp
*   server? please allow to have a place for this. Just provide for
*   example a 'content-info' as a placeholder for time stamps, scvp
*   responses.
[TF] Up to now one of our objective was to hide any complexity that may
arise out of relay. There is also no guaranteed correlation between
relayed requests. A client may make a DPV request and the server may
intern make a DPD request to another SCVP server so embedding the DPD
response to he DPV request is on no value.
* 
* - Is the Nonce field the response to the following req:
* 
*    The DPV server MUST be able, upon request, copy a text field
provided
*    by the client into the DPV response.  As an example, this field may
*    relate to the nature or reason for the DPV query.
* 
* - I'd like to know what others think about my compromise proposal
*   for requestor/responder.
* 
* - I have some feeling that there are at least some different
* interpretation
*   of policies and object identifiers validation algoritithms, etc.
* 
*   - OIDs used for a configuration
*   - oids to reference some globally recognised rules
*   - oids to define sysntaxes of validation algorihms.
[TF] Yes I have been thinking that an OID alone is to restrictive.
Others may want to use a URL to point to a policy so we need a couple of
built in choices plus an extension mechanism for other to define other
reference types.
* 
* - It is not clear to me whether for example the name matching
algorithm
*   is at the right level of abstraction. I'd rather have an
*   algorithm that say: 'Can this cert be used for this keypurpose,
*   for the following names.' It maybe not useful to
*   burden the client with the details of adding keyusage and
*   compatible extendedkeyusage.
[TF] I was specially asked to do the name matching example because it is
widely used today. I am sure others can submit other policy example as
separate IDs.
* 
* 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4EF1cab029538; Fri, 14 May 2004 08:01:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4EF1ckY029537; Fri, 14 May 2004 08:01:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4EF1biR029517 for <[e-mail]>; Fri, 14 May 2004 08:01:38 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 14 May 2004 11:01:22 -0400
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
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> <[e-mail]> <[e-mail]> <001001c43864$e11bb130$0500a8c0@arport> <[e-mail]> <00c001c43924$d691c5e0$0500a8c0@arport>
In-Reply-To: <00c001c43924$d691c5e0$0500a8c0@arport>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 14 May 2004 15:01:28.0728 (UTC) FILETIME=[55B16980:01C439C4]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The problem is that most PKIs do not support SN attributes
managed as in your "real world" example, they support
SN as disambiguator, as cited (not invented) by Denis.

Some tightly-managed PKIs (government and commercial) do
support SN attributes that are permanent references to a
user; in fact some do not even populate commonName and
use SN as the only user identifier.  In an ideal world,
all PKIs that populated the SN naming attribute would
put a Permanent Identifier in it.  This would be in
partial alignment with the wording of X.520, which
says:
   "The Serial Number attribute type specifies an
    identifier, the serial number of an object."

If you regard people as objects, then it is pretty clear
that the "serial number" of a person is something equivalent
to DNA; it doesn't change when the person changes names,
and it doesn't change depending on which CA issues the
person a certificate.  However, there are strong privacy
reasons for not putting a DNA equivalent into certificates,
and that's never going to happen.  So an alternative
like the PI RFC is required.  The requirements are:

1) mechanical applications must be able to tell reliably
and unambiguously (i.e., without installation-time
configuration) if a cert contains a PI, and if so, how
to extract it.

2) the PI doesn't change over the "functional lifetime"
of the person (the time the person has an account at
an institution, which can range up to most of a person's
natural lifetime).

3) the PI is assigned by a naming authority that is not
in general a CA.  One CA must be able to issue certs for
multiple institutions that create user accounts, and
multiple CAs must be able to issue certs for an account
at a single such institution (and are recognized as all
referring to the same account by the applications of
requirement #1).

If you can come up with a specification that uses the
SN attribute and satisfies each of these three requirements,
I will happily favor it over the Pinkas/Gindin proposal.
But I don't believe such a specification is possible.

Dave




Anders Rundgren wrote:

> Now assume that you don't have an e-mail address
> to stuff into the DN but you do have some kind of
> unique identifier.  Why put this somewhere else than
> in the DN?  An example shows how ugly it gets:
> 
> Denis' world:
> DN: CN=John Smith, serialNumber=3, O=ACME, C=US
> PI: OID.6.4.3.5.6.6.6.43.3, 05725277
> 
> The real world:
> DN: CN=John Smith, serialNumber=05725277, O=ACME, C=US
> The name space is given by the CA policy. Implicit or explicit.
> 
> Although esthetics is maybe not priority #1, I believe that
> "inventing" arbitrary disambiguing numbers when there is
> a perfectly valid number to use is a *very* hard sale. 
> However, most of the PI motivation goes away if the unique
> identifier is used as disambiguer and that's the problem in
> a nutshell.  Can you fix this dilemma, please tell us how!
> 
> 
> A solution for DoD
> ----------------------
> 
> Not that I believe you want my advice but here is a suggestion
> for DoD:
> 
> CN=David Kemp, serialNumber=05725277, DC=staffregistry1, DC=dod, DC=mil
> 
> Using this scheme you get globally unique identifiers (GUIDs)
> which is a much more needed and popular thing than finding
> new ways to complicate RP applications.  Why would a
> certificate ever contain more "name" info than this (+ S/MIME
> support in applicable cases)?
> 
> 
> rgds
> Anders
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4EC9u3V013061; Fri, 14 May 2004 05:09:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4EC9uf9013060; Fri, 14 May 2004 05:09:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4EC9seU013048 for <[e-mail]>; Fri, 14 May 2004 05:09:55 -0700 (PDT) (envelope-from [e-mail])
Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.12.10/8.12.10) with ESMTP id i4EC97hO022739; Fri, 14 May 2004 20:09:08 +0800
Received: (from root@localhost) by ms20.chttl.com.tw (8.12.10/8.12.10) id i4EC975j017003; Fri, 14 May 2004 20:09:07 +0800
Received: from wcwang ([10.144.133.79]) by ms20.chttl.com.tw (8.12.10/8.12.10) with SMTP id i4EC94pF016797; Fri, 14 May 2004 20:09:04 +0800
Message-ID: <026301c439ac$3fc72370$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Tom Gindin" <[e-mail]>
Cc: "Santoni Adriano" <[e-mail]>, <[e-mail]>, "Stephen Kent" <[e-mail]>, <[e-mail]>, "Steve Hanna" <[e-mail]>
References: <[e-mail]>
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String inencodingRDNs
Date: Fri, 14 May 2004 20:09:01 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree that if all RP implementations adopt X.500-like name matching
rules, then there is no need to issue name encoding rollover certificates.

Even so, we still need to clarify whether a certificate with same issuer
and subject names but in different encoding should be interpreted
as self-issued, because there is no way to prohibit CAs from issuing
such certificates (e.g., CA1-CA1-p-u-cert I mentioned in my recent post).

Wen-Cheng Wang


> 
> The whole encoding rollover certificate issue seems to be in error and
> should probably be deprecated.
> 
> Here is the reason:
> 
> Either you regard names of different encoding a name match or you don't.
> 
> X.509 matching rules for attributes caseIgnoreSyntax suggest that names
> in different encoding are a match if they can be concluded to express
> the same name.
> 
> RFC 3280 say that this is OK to implement, but you are allowed to
> disregard this and treat names of different encoding as no match
> 
> So.... If this IS accepted as a name match, then you don't need the
> rollover cert. It has no function since the path now works without it.
> 
> 
> The paradox is then the following: 
> If we fix name matching in RFC 3280, then there IS NO use of the
> encoding rollover cert any more (path works without it). If we on the
> other hand DON't fix this, then this certificate will neither be a self
> issued certificate by definition and thus it will in some cases break
> path validation.
> 
> 
> Stefan Santesson
> Program Manager, Windows Security
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4EAQL2a003574; Fri, 14 May 2004 03:26:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4EAQLll003573; Fri, 14 May 2004 03:26:21 -0700 (PDT)
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.11/8.12.9) with ESMTP id i4EAQJI9003566 for <[e-mail]>; Fri, 14 May 2004 03:26:20 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i4EAQKN16487; Fri, 14 May 2004 12:26:20 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 14 May 2004 12:26:20 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i4EAQJk23215; Fri, 14 May 2004 12:26:19 +0200 (MEST)
Date: Fri, 14 May 2004 12:26:19 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP & validation policies
Cc: [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>

> Hi Peter,
> The problem of having to push policy to clients of all descriptions is a
> well understood problem set. The infrastructure to do that is the main
> overhead. The number of parameters associated with that process is not a
> significant overhead.

You don't push parameters that are subject to change, you need to handle
updates, if you configure one id, the problem of updates is gone.

Whenever you can remove one parameter, you significantly reduce 
the potential problem space (about divide it at least by 2)

But since you have responsed positively to Denis, I may
not even understand what you are saying.

Since three drafts, the whole text is unimplementable,
i.e. almost a year, ...), so the following list of some
(to me) open questions is not necessariy complete.  

- in what way a relay scvp can include an answer from another scvp
  server? please allow to have a place for this. Just provide for
  example a 'content-info' as a placeholder for time stamps, scvp
  responses.

- Is the Nonce field the response to the following req: 

   The DPV server MUST be able, upon request, copy a text field provided
   by the client into the DPV response.  As an example, this field may
   relate to the nature or reason for the DPV query.

- I'd like to know what others think about my compromise proposal
  for requestor/responder.

- I have some feeling that there are at least some different interpretation
  of policies and object identifiers validation algoritithms, etc.

  - OIDs used for a configuration
  - oids to reference some globally recognised rules
  - oids to define sysntaxes of validation algorihms. 

- It is not clear to me whether for example the name matching algorithm
  is at the right level of abstraction. I'd rather have an
  algorithm that say: 'Can this cert be used for this keypurpose,
  for the following names.' It maybe not useful to
  burden the client with the details of adding keyusage and 
  compatible extendedkeyusage. 

    



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4E9xs89000282; Fri, 14 May 2004 02:59:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4E9xsQg000281; Fri, 14 May 2004 02:59:54 -0700 (PDT)
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.11/8.12.9) with ESMTP id i4E9xqha000259 for <[e-mail]>; Fri, 14 May 2004 02:59:53 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i4E9xkN16205; Fri, 14 May 2004 11:59:46 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 14 May 2004 11:59:46 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i4E9xj222852; Fri, 14 May 2004 11:59:45 +0200 (MEST)
Date: Fri, 14 May 2004 11:59:45 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP & validation policies
Cc: [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>

> 
> Hi Denis,
> As I said previous an OID is one of the possible options, but there is
> no consensus to make this mandatory so SCVP will continue to support
> both options. I also don't see consensus that it is mandatory that a
> SCVP server will always map a request back to the OID.

I can live with this.

> I will be posting SCVP 15 shortly so you can review the latest draft.

Given the previous discussion, I'd like to see a possibility
that the request can be as simple as just sending in the certificate. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4E94dOT084016; Fri, 14 May 2004 02:04:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4E94dOW084015; Fri, 14 May 2004 02:04:39 -0700 (PDT)
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.9) with ESMTP id i4E94c4s083959 for <[e-mail]>; Fri, 14 May 2004 02:04:38 -0700 (PDT) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.22]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 May 2004 10:04:21 +0100
Received: from 65.53.196.22 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 14 May 2004 10:04:21 +0100
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, 14 May 2004 10:04:21 +0100
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String inencodingRDNs
Date: Fri, 14 May 2004 10:03:24 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: R: I: R: RFC3280: doubt on the use of UTF8String inencodingRDNs
Thread-Index: AcQ5jSVlwhgx8O2TT+qmzLBm+HVi/AAAkdGQ
From: "Stefan Santesson" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>, "Tom Gindin" <[e-mail]>
Cc: "Santoni Adriano" <[e-mail]>, <[e-mail]>, "Stephen Kent" <[e-mail]>, <[e-mail]>, "Steve Hanna" <[e-mail]>
X-OriginalArrivalTime: 14 May 2004 09:04:21.0150 (UTC) FILETIME=[71DC7BE0:01C43992]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4E94d4s084007
Sender: [e-mail]
Precedence: 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 whole encoding rollover certificate issue seems to be in error and
should probably be deprecated.

Here is the reason:

Either you regard names of different encoding a name match or you don't.

X.509 matching rules for attributes caseIgnoreSyntax suggest that names
in different encoding are a match if they can be concluded to express
the same name.

RFC 3280 say that this is OK to implement, but you are allowed to
disregard this and treat names of different encoding as no match

So.... If this IS accepted as a name match, then you don't need the
rollover cert. It has no function since the path now works without it.


The paradox is then the following: 
If we fix name matching in RFC 3280, then there IS NO use of the
encoding rollover cert any more (path works without it). If we on the
other hand DON't fix this, then this certificate will neither be a self
issued certificate by definition and thus it will in some cases break
path validation.


Stefan Santesson
Program Manager, Windows Security

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Wen-Cheng Wang
> Sent: den 14 maj 2004 09:21
> To: Tom Gindin
> Cc: Santoni Adriano; [e-mail]; Stephen Kent;
> [e-mail]; Stefan Santesson; Steve Hanna
> Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String
> inencodingRDNs
> 
> 
> Tom,
> 
> >
> >         The bottom line of the statements you have quoted is that
some
> > fully RFC 3280-compliant RP implementations will treat all rollover
> > certificates as self-issued, some will treat no rollover
certificates as
> > self-issued, and some will treat many rollover certificates as self-
> issued
> > but some as not.  Thus, whether a given rollover certificate is
deemed
> to
> > be self-issued by a compliant RP is implementation dependent -
probably
> a
> > worse situation than "rollover certificates are not interpreted as
> > self-issued".
> Yes, the current situation is that some RP implementations will treat
> name rollover certificates (if any) as self-issued but some will not.
> The root cause of inconsistency on interpreting self-issued
certificates
> among different implementations is the deficiency of name matching
> rules in RFC 3280 and the X.509 standard. There can be a debate
> on whether name rollover certificates should be interpreted as
> self-issued or not. However, the current situation is the current
> situation. The situation will not change unless the deficiency in
> RFC 3280 and the X.509 standard is mended and hopefully
> all RP implementations will migrate to  a consistent way of
> interpreting self-issued certificates. The point is that even if we
> finally
> agree that  "name rollover certificates should not interpreted as
> self-issued", we still need to revise or amend  RFC 3280 and the
> X.509 standard to make it clear.
> 
> >         IMHO, it would really help if we had a list of CA's who
encode
> > their current DN's using BMPString with characters in the surrogate
> range,
> > and whether they are compliant to UTF-16 or not, and a list of CA's
who
> > encode their current DN's using T61String.  Most other character
> > conversions under the ASN.1 standard are simple algorithms.
> >
> That might be an interesting investigation, but I do not think it will
> help for resolving the inconsistency on interpreting self-issued
> certificates. As I said above, the root cause is the deficiency of
> name matching rules. Paying more attention to mend the deficiency
> might be more helpful. If we have name matching rules that can take
> care of name string in different character sets and/or in different
> encoding, it will not only resolve the inconsistency on interpreting
> self-issued certificates but also will reduce the needs of issuing
> name rollover certificates.
> 
> Wen-Cheng Wang




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4E8lnZ9077811; Fri, 14 May 2004 01:47:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4E8ln9C077810; Fri, 14 May 2004 01:47:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft4.fr.colt.net (smtp-ft4.fr.colt.net [213.41.78.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4E8llBW077772 for <[e-mail]>; Fri, 14 May 2004 01:47:48 -0700 (PDT) (envelope-from [e-mail])
Received: from free.fr (host.106.92.68.195.rev.coltfrance.com [195.68.92.106]) by smtp-ft4.fr.colt.net with ESMTP id i4E8lhH25727 for <[e-mail]>; Fri, 14 May 2004 10:47:43 +0200
Message-ID: <[e-mail]>
Date: Fri, 14 May 2004 10:48:36 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:) Gecko/20040226
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in encodingRDNs
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom Gindin wrote:

>        IMHO, it would really help if we had a list of CA's who encode 
>their current DN's using BMPString 
>
Probably not many. This might have happened mostly with some CA having 
left a few requests using BMPString slip in.

>with characters in the surrogate range, 
>and whether they are compliant to UTF-16 or not, 
>
I certainly believe nobody did that. Is it required to precise that 
UTF8String is the only reliable way to encode surrogate/non BMP unicode 
characters ?

>and a list of CA's who 
>encode their current DN's using T61String.
>
The bug database of Mozilla enables to localize some of them, for example :
E = [e-mail], CN = neam Gesellschaft für Kommunikationslösungen mbH, 
OU = Security, O = neam CA, C = DE (this is in T61)

Most of those CAs are clearly not used for certificates that were 
actually intended to be publicly distributed (thus did not care too much 
about interoperability problems).

There is in that database a very interesting case of a CA with a UTF8 
name that issued a cert with a BMPString name :
You can download that from this link :
http://bugzilla.mozilla.org/attachment.cgi?id=109214&action=view

I think this certainly demonstrate a CA wishing to switch to the use of 
UTF8String, but that unfortunately also allowed it's software to issue 
BMPString when it allowed "unicode" in certificate names.
Implementers should beware of such situations.

>  Most other character 
>conversions under the ASN.1 standard are simple algorithms.
>  
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4E7LgcP049287; Fri, 14 May 2004 00:21:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4E7LgRO049286; Fri, 14 May 2004 00:21:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gate3.chttl.com.tw (gate3.chttl.com.tw [203.75.28.115]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4E7LTAA049171 for <[e-mail]>; Fri, 14 May 2004 00:21:35 -0700 (PDT) (envelope-from [e-mail])
Received: from ms8.chttl.com.tw (ms8 [10.144.2.118]) by gate3.chttl.com.tw (8.12.10/8.12.10) with ESMTP id i4E7KngJ011080; Fri, 14 May 2004 15:20:49 +0800
Received: (from root@localhost) by ms8.chttl.com.tw (8.12.10/8.12.10) id i4E7KmOM029785; Fri, 14 May 2004 15:20:48 +0800
Received: from wcwang ([10.144.133.79]) by ms8.chttl.com.tw (8.12.10/8.12.10) with SMTP id i4E7KjuU029681; Fri, 14 May 2004 15:20:46 +0800
Message-ID: <017b01c43983$f9202930$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Tom Gindin" <[e-mail]>
Cc: "Santoni Adriano" <[e-mail]>, <[e-mail]>, "Stephen Kent" <[e-mail]>, <[e-mail]>, "Stefan Santesson" <[e-mail]>, "Steve Hanna" <[e-mail]>
References: <[e-mail]>
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String inencodingRDNs
Date: Fri, 14 May 2004 15:20:42 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

>
>         The bottom line of the statements you have quoted is that some
> fully RFC 3280-compliant RP implementations will treat all rollover
> certificates as self-issued, some will treat no rollover certificates as
> self-issued, and some will treat many rollover certificates as self-issued
> but some as not.  Thus, whether a given rollover certificate is deemed to
> be self-issued by a compliant RP is implementation dependent - probably a
> worse situation than "rollover certificates are not interpreted as
> self-issued".
Yes, the current situation is that some RP implementations will treat
name rollover certificates (if any) as self-issued but some will not.
The root cause of inconsistency on interpreting self-issued certificates
among different implementations is the deficiency of name matching
rules in RFC 3280 and the X.509 standard. There can be a debate
on whether name rollover certificates should be interpreted as
self-issued or not. However, the current situation is the current
situation. The situation will not change unless the deficiency in
RFC 3280 and the X.509 standard is mended and hopefully
all RP implementations will migrate to  a consistent way of
interpreting self-issued certificates. The point is that even if we finally
agree that  "name rollover certificates should not interpreted as
self-issued", we still need to revise or amend  RFC 3280 and the
X.509 standard to make it clear.

>         IMHO, it would really help if we had a list of CA's who encode
> their current DN's using BMPString with characters in the surrogate range,
> and whether they are compliant to UTF-16 or not, and a list of CA's who
> encode their current DN's using T61String.  Most other character
> conversions under the ASN.1 standard are simple algorithms.
>
That might be an interesting investigation, but I do not think it will
help for resolving the inconsistency on interpreting self-issued
certificates. As I said above, the root cause is the deficiency of
name matching rules. Paying more attention to mend the deficiency
might be more helpful. If we have name matching rules that can take
care of name string in different character sets and/or in different
encoding, it will not only resolve the inconsistency on interpreting
self-issued certificates but also will reduce the needs of issuing
name rollover certificates.

Wen-Cheng Wang



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4E0BUK4068819; Thu, 13 May 2004 17:11:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4E0BUp2068818; Thu, 13 May 2004 17:11:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4E0BJhb068801 for <[e-mail]>; Thu, 13 May 2004 17:11:19 -0700 (PDT) (envelope-from [e-mail])
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i4E08CKr580206; Thu, 13 May 2004 20:08:22 -0400
Received: from d01ml062.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i4E08Vaq080562; Thu, 13 May 2004 20:08:32 -0400
To: "Wen-Cheng Wang" <[e-mail]>
Cc: "Santoni Adriano" <[e-mail]>, [e-mail], "Stephen Kent" <[e-mail]>, [e-mail], "Stefan Santesson" <[e-mail]>, "Steve Hanna" <[e-mail]>
MIME-Version: 1.0
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in encodingRDNs
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Thu, 13 May 2004 20:07:55 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.2CF2 HFB2|May 5, 2004) at 05/13/2004 20:08:01, Serialize complete at 05/13/2004 20:08:01
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>

        Wan-Cheng:

        The bottom line of the statements you have quoted is that some 
fully RFC 3280-compliant RP implementations will treat all rollover 
certificates as self-issued, some will treat no rollover certificates as 
self-issued, and some will treat many rollover certificates as self-issued 
but some as not.  Thus, whether a given rollover certificate is deemed to 
be self-issued by a compliant RP is implementation dependent - probably a 
worse situation than "rollover certificates are not interpreted as 
self-issued".
        IMHO, it would really help if we had a list of CA's who encode 
their current DN's using BMPString with characters in the surrogate range, 
and whether they are compliant to UTF-16 or not, and a list of CA's who 
encode their current DN's using T61String.  Most other character 
conversions under the ASN.1 standard are simple algorithms.

                Tom Gindin

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





"Wen-Cheng Wang" <[e-mail]>
Sent by: [e-mail]
05/12/2004 05:10 AM

 
        To:     "Stefan Santesson" <[e-mail]>, "Stephen Kent" <[e-mail]>, 
"Santoni Adriano" <[e-mail]>
        cc:     <[e-mail]>, <[e-mail]>, "Steve Hanna" 
<[e-mail]>
        Subject:        Re: R: I: R: RFC3280: doubt on the use of UTF8String in encodingRDNs




> Yes, you can do a lot of cool things in theory.
>
> The cruel truth is that your name encoding roll-over certs (e.g.
> CA1-CA1-p-u-cert) is not self issued according to RFC 3280.

That is why I said that the definition of self-issued certificates in RFC
3280 (or maybe its definition in the X.509 standard itself) should
be revised or be clarified in son-of-3280 (or in an amendment of
the X.509 standard as well).

>
> RFC 3280 section 6.1:
>    A certificate is self-issued if the DNs that appear in the subject
>    and issuer fields are identical and are not empty.
>
> RFC 3280 section 4.1.2.4:
>       (a)  attribute values encoded in different types (e.g.,
>       PrintableString and BMPString) MAY be assumed to represent
>       different strings;

Remenber that RFC 3280 section 4.1.2.4 also said:

   Implementations of this profile are permitted to use the comparison
   algorithm defined in the X.500 series.

In that respect, you can not said that name rollover certificates are not
self-issued.

>
> So in current implementations of RFC 3280, many valid certificates will
> fail after introduction of name rollover certs in the chain, because
> path validation will not treat them as self-issued.

I admit that most CURRENT implementations of RFC 3280 path
validation will fail to treat name rollover certificates as self-issued, 
but
it does not mean that we should not recommend FUTURE revisions
of those implementations and new implementations to treat them as
self-issued.

>
> Further, the name constraint problem persists, adds to this but also
> exist regardless of this problem.
>
> RFC 3280 section 4.2.1.11
>    When applying restrictions of the form directoryName, an
>    implementation MUST compare DN attributes.  At a minimum,
>    implementations MUST perform the DN comparison rules specified in
>    Section 4.1.2.4.

That is why I said RFC 3280 path validation algorithm should also be
revised.

>
> Fixing next version of RFC 3280 to include better name matching rules is
> a good thing but far from enough to take care of real problems with
> current infrastructure.

Fixing next version of RFC 3280 does not magically take care of real
problems with current infrastructure, but it encourge current 
infrastructure
to migrate to solve the problems.

>
> We have to try to keep in mind what we make all this hassle for!!
>
> This is NOT about whether we should use UTF-8 or not to accommodate
> complex character sets!! This is about what we are prepared to do to
> make sure NOTHING is encoded as PrintableString WHEN PrintableString is
> sufficient.
>
> This old transition rule was created in RFC 2459 before the modern path
> validation algorithm was invented and before self-issued certificates
> was a special case.

That does not mean that name rollover certificates can not solve the
mixed name-encoding  problem.

>
> Let's just admit that we overlooked this issue when we created RFC 3280
> and reshaped path validation. It was an understandable human error,
> which lead to a defect.

Yes, RFC 3280 indeed overlooked this issue. That is why it should be
revised.

>
> So let's then also admit that REQUIRING UTF-8 when printableString is
> sufficient, is not a very good idea when all practical matters are
> measured, and that it never should have made it to more than a
> RECOMMENDATION.

Isn't it the IETF policy to encourge all new implementations to migrate
to support UTF-8? The philosophy is that if one encoding is sufficient to
cover universal characters, why should we recommend two?

>
> Whatever we say here, this is a requirement that many implementers will
> have to ignore for a many years to come.

Conformance to any IETF RFC is all voluntary. No one can enfoce any
implementer for that if the implementer chooses to ignore the requirement
or recommendation of any IETF RFC. RFC 3280 might not have the
power to enforce all implementation to migrate to UTF-8 encoding.
However, as an IETF RFC, it definitely has a great effect. At least, I
see more and more applications can correctly handle certificates with
named in UTF-8 encoding. Therefore, I prefer to see son-of-3280 to
continue requiring conformant implementations to migrate to UTF-8
encoding.

Wen-Cheng Wang






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4DK1AWW051881; Thu, 13 May 2004 13:01:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4DK1AHn051880; Thu, 13 May 2004 13:01:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av4-1-sn3.vrr.skanova.net (av4-1-sn3.vrr.skanova.net [81.228.9.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4DK19ww051861 for <[e-mail]>; Thu, 13 May 2004 13:01:09 -0700 (PDT) (envelope-from [e-mail])
Received: by av4-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 0D7A937F80; Thu, 13 May 2004 22:01:02 +0200 (CEST)
Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av4-1-sn3.vrr.skanova.net (Postfix) with ESMTP id F3C9837E62; Thu, 13 May 2004 22:01:01 +0200 (CEST)
Received: from arport (t7o913p111.telia.com [213.64.26.111]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with SMTP id 8FA3B38009; Thu, 13 May 2004 22:00:57 +0200 (CEST)
Message-ID: <00c001c43924$d691c5e0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "David P. Kemp" <[e-mail]>
Cc: <[e-mail]>
References: <005701c3e08e$9b392fe0$[e-mail]> <00c701c3e121$0ae3af90$0500a8c0@arport> <[e-mail]> <[e-mail]> <001001c43864$e11bb130$0500a8c0@arport> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
Date: Thu, 13 May 2004 21:59:41 +0200
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>

David,
I don't know if you really care, but there are reasons behind
my arguments, beyond just "opinions" or personal taste.

>SubjectAltName brings some syntax-enforced discipline
>to certificate naming.  Feel free to ignore it, and even
>to urge others to ignore it, 

*I* don't have to do this.  Putting RFC822 names in subject
DNs is the default behavior of every major CA software
package there is.

In fact 9 out of 10 certificates used for signing messages
to the PKIX-list(!) follow this standard, in spite of being
deprecated by S/MIME and RFC3280.

>but at least feel a twinge of shame when you do so.

Well, I believe the RFC3280 should in the coming revision
refrain from calling the industry standard "legacy".

Harry the PKI amateur
--------------------------

In quite a number of RP applications the subject DN is
the *only* identity information used, as most folks actually
believed that the "subject distinguished name" really is
the name of the subject.  After looking at a number of
commercial certs this looked like a fact.  That DNs are
created to suit the needs of a directory is not an absolute
truth anymore.  In particular as many RPs don't store
certificates in directories but in "flat" databases. 
In most cases external certificates are not stored at all,
except by CAs for revocation services etc!

Encrypted mail is a microscopic application which
makes the whole DIT-story of marginal interest.
That's was an "opinon" though :-)

The "art discussion"
---------------------

Now assume that you don't have an e-mail address
to stuff into the DN but you do have some kind of
unique identifier.  Why put this somewhere else than
in the DN?  An example shows how ugly it gets:

Denis' world:
DN: CN=John Smith, serialNumber=3, O=ACME, C=US
PI: OID.6.4.3.5.6.6.6.43.3, 05725277

The real world:
DN: CN=John Smith, serialNumber=05725277, O=ACME, C=US
The name space is given by the CA policy. Implicit or explicit.

Although esthetics is maybe not priority #1, I believe that
"inventing" arbitrary disambiguing numbers when there is
a perfectly valid number to use is a *very* hard sale. 
However, most of the PI motivation goes away if the unique
identifier is used as disambiguer and that's the problem in
a nutshell.  Can you fix this dilemma, please tell us how!


A solution for DoD
----------------------

Not that I believe you want my advice but here is a suggestion
for DoD:

CN=David Kemp, serialNumber=05725277, DC=staffregistry1, DC=dod, DC=mil

Using this scheme you get globally unique identifiers (GUIDs)
which is a much more needed and popular thing than finding
new ways to complicate RP applications.  Why would a
certificate ever contain more "name" info than this (+ S/MIME
support in applicable cases)?


rgds
Anders



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4DFwOMx034860; Thu, 13 May 2004 08:58:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4DFwO4V034859; Thu, 13 May 2004 08:58:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4DFwNYR034853 for <[e-mail]>; Thu, 13 May 2004 08:58:24 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 13 May 2004 08:58:27 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 13 May 2004 08:58:26 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 13 May 2004 08:58:25 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP & validation policies
Date: Thu, 13 May 2004 08:58:25 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
thread-index: AcQ4v28UxUBpGKJqTwifie+toVecpgAQoApQ
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 13 May 2004 15:58:25.0807 (UTC) FILETIME=[200489F0:01C43903]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4DFwOYR034854
Sender: [e-mail]
Precedence: 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,
As I said previous an OID is one of the possible options, but there is
no consensus to make this mandatory so SCVP will continue to support
both options. I also don't see consensus that it is mandatory that a
SCVP server will always map a request back to the OID.
I will be posting SCVP 15 shortly so you can review the latest draft.
Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Thursday, May 13, 2004 12:54 AM
To: Trevor Freeman
Cc: Florian Oelmaier; [e-mail]
Subject: Re: SCVP & validation policies

Trevor,

(text deleted)

Florian said: "it is widespread consensus on this list that
this could be done with SCVP by the use of the OID as a reference
to the validation policy as the sole configuration item."

I agree.

To respond to a request from Wen-Cheng Wang, the OID of the validation 
policy should be optional in the request. However, if the OID of the 
validation policy is not present in the request, then the OID of the 
validation policy that has been used SHALL be returned by the SCVP
server in 
the response. If the validation policy has dynamic parameters, then
these 
parameters SHALL be returned too.

Now, we need to move, Trevor.

Would you propose in an e-mail extracts of an ASN.1 syntax that would 
accommodate these requirements for both the request and the response, 
focussing on the validation policy elements ?

Thanks,

Denis

(text deleted)




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4DEakPL027498; Thu, 13 May 2004 07:36:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4DEakjo027497; Thu, 13 May 2004 07:36:46 -0700 (PDT)
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.9) with ESMTP id i4DEaerr027477 for <[e-mail]>; Thu, 13 May 2004 07:36:40 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01 (medusa01.cs.auckland.ac.nz [130.216.34.33]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id E3C9334105; Fri, 14 May 2004 02:32:54 +1200 (NZST)
Received: from pgut001 by medusa01 with local (Exim 4.30) id 1BOHKF-000821-NK; Fri, 14 May 2004 02:36:43 +1200
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-08.txt
In-Reply-To: <[e-mail]>
Message-Id: <E1BOHKF-000821-NK@medusa01>
Date: Fri, 14 May 2004 02:36:43 +1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Al Arsenault" <[e-mail]> writes:

>(And as I've pointed out numerous times before, I know of organizations that
> put the equivalent of "0514101404" in subjectAltName, as a DNS Name!  It's
> certainly possible, but that doesn't make it the "right thing" to do.

I've seen 'em in uniqueIDs, from a couple of European CAs.

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4D7riJ0059757; Thu, 13 May 2004 00:53:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4D7riCi059756; Thu, 13 May 2004 00:53:44 -0700 (PDT)
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.9) with ESMTP id i4D7rgMi059674 for <[e-mail]>; Thu, 13 May 2004 00:53:43 -0700 (PDT) (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 KAA34132; Thu, 13 May 2004 10:02:56 +0200
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 JAA20064; Thu, 13 May 2004 09:52:12 +0200
Message-ID: <[e-mail]>
Date: Thu, 13 May 2004 09:54:01 +0200
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: "'Trevor Freeman'" <[e-mail]>
CC: Florian Oelmaier <[e-mail]>, [e-mail]
Subject: Re: SCVP & validation policies
References: <011c01c43855$9ab957b0$4228a8c0@hagen>
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>

Trevor,

(text deleted)

Florian said: "it is widespread consensus on this list that
this could be done with SCVP by the use of the OID as a reference
to the validation policy as the sole configuration item."

I agree.

To respond to a request from Wen-Cheng Wang, the OID of the validation 
policy should be optional in the request. However, if the OID of the 
validation policy is not present in the request, then the OID of the 
validation policy that has been used SHALL be returned by the SCVP server in 
the response. If the validation policy has dynamic parameters, then these 
parameters SHALL be returned too.

Now, we need to move, Trevor.

Would you propose in an e-mail extracts of an ASN.1 syntax that would 
accommodate these requirements for both the request and the response, 
focussing on the validation policy elements ?

Thanks,

Denis

(text deleted)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4D1Wj6t078151; Wed, 12 May 2004 18:32:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4D1Wjn9078150; Wed, 12 May 2004 18:32:45 -0700 (PDT)
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.9) with ESMTP id i4D1Wi4s078132 for <[e-mail]>; Wed, 12 May 2004 18:32:44 -0700 (PDT) (envelope-from [e-mail])
Received: from arsenaultd2 (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with SMTP id i4D1Wd7Y007791; Wed, 12 May 2004 21:32:40 -0400 (EDT)
From: "Al Arsenault" <[e-mail]>
To: "Anders Rundgren" <[e-mail]>, "David P. Kemp" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-08.txt
Date: Wed, 12 May 2004 21:30:37 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1409
In-Reply-To: <001001c43864$e11bb130$0500a8c0@arport>
Importance: Normal
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4D1Wj4s078145
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Anders Rundgren
> Sent: Wednesday, May 12, 2004 5:01 PM
> To: David P. Kemp; [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
> 
> 
> 
> >It is my hope that PI will become an RFC in the near future, so
> >that certificates (from an un-named large PKI :-) that currently
> >handle PIs by munging them into Common Name (e.g.,
> >CN="Kemp.David.P.0514101404") will have a saner alternative.
> 
> The de-facto standard, already engraved in *millions* of certs is
> putting 0514101404 in serialNumber. 
> 
> 

The problem with that is that "0514101404" is not expected to change; it's a number which stays with you as long as you're an employee of the company, or as long as you're a customer, or even all of your life.

The serialNumber is expected to change every time the certificate changes - commonly, when a certificate expires once a year, the new certificate has a new serialNumber.  It's considered seriously bad form to issue a "renewed" certificate with a different validity period and the same serialNumber.

Thus, those who put 0514101404 in "serialNumber" are just setting themselves up for trouble later on down the road.

(And as I've pointed out numerous times before, I know of organizations that put the equivalent of "0514101404" in subjectAltName, as a DNS Name!  It's certainly possible, but that doesn't make it the "right thing" to do.

			Al Arsenault




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CMCvuR062651; Wed, 12 May 2004 15:12:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CMCvGY062650; Wed, 12 May 2004 15:12:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CMCuVT062643 for <[e-mail]>; Wed, 12 May 2004 15:12:56 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 12 May 2004 18:12:04 -0400
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
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> <[e-mail]> <[e-mail]> <001001c43864$e11bb130$0500a8c0@arport>
In-Reply-To: <001001c43864$e11bb130$0500a8c0@arport>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 May 2004 22:12:05.0026 (UTC) FILETIME=[28802020:01C4386E]
Sender: [e-mail]
Precedence: 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 is certainly technically possible to put any attribute
into the subject name syntax.  An unfortunate side effect
of an infinitely-flexible syntax is that de-facto standards
such as those you cite can arise.

DNS (and by extension, email address) is a namespace rooted
in the TLDs (.com, .edu, ...).  PIs are another
namespace rooted either in some CA-specific environment
(policy=CA) or in an independent manner (by assigning agency)
that allows multiple CAs to issue certificates to one
identifiable user.  Subject Distinguished Names are
intended to be a third namespace, typically rooted by Country.

When you say "just stuff an email address in the middle of
a DN", that is equivalent to saying "just stuff a DN in
the middle of an email address:
"dpkemp@missi.(C=US,O=DoD,CN=Dave).ncsc.mil"  Fortunately,
RFC822 prohibits such foolishness in a way that cannot be
circumvented by fools.  Unfortunately, X.509 DN syntax does
not prohibit anything, and it is up to system architects
to establish rules that enable DNs to form a namespace
rather than a cloaca for miscellaneous unrelated data.
It is as easy for CAs to ignore those rules as it is
for Harry Homeowners to ignore electrical codes and wire
their basements without grounding and with hot and neutral
lines connected randomly.  The fact that something can be
done and is in fact done millions of times does not make
it a good idea.

SubjectAltName brings some syntax-enforced discipline
to certificate naming.  Feel free to ignore it, and even
to urge others to ignore it, but at least feel a twinge
of shame when you do so.



Anders Rundgren wrote:

>>It is my hope that PI will become an RFC in the near future, so
>>that certificates (from an un-named large PKI :-) that currently
>>handle PIs by munging them into Common Name (e.g.,
>>CN="Kemp.David.P.0514101404") will have a saner alternative.
> 
> 
> The de-facto standard, already engraved in *millions* of certs is
> putting 0514101404 in serialNumber. 
> 
> This is almost as de-facto standard as putting e-mail addresses in DNs
> which in turn is almost as de-facto standard as using URIs for naming
> globally unique objects.
> 
> C:\Internet-Drafts>del draft-ietf-pkix-pi-*.txt
> 
> :-)
> 
> Pardon my complaints, let there be an RFC!  But don't expect
> this scheme to become the trend.
> 
> There is a slight problem with the whole idea.  Either RPs require
> and act upon the PI-data or they don't care about it.  This in my
> opinion makes the extension redundant or is just another way
> to screw up validation.
> 
> If you on top of this add policy extensions I believe a real disaster
> is in the making.
> 
> Anders
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CL6vA5057563; Wed, 12 May 2004 14:06:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CL6vdX057562; Wed, 12 May 2004 14:06:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from av9-2-sn1.fre.skanova.net (av9-2-sn1.fre.skanova.net [81.228.11.116]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CL6uDI057548 for <[e-mail]>; Wed, 12 May 2004 14:06:56 -0700 (PDT) (envelope-from [e-mail])
Received: by av9-2-sn1.fre.skanova.net (Postfix, from userid 502) id 0D31538015; Wed, 12 May 2004 23:06:53 +0200 (CEST)
Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av9-2-sn1.fre.skanova.net (Postfix) with ESMTP id EE3D037E71; Wed, 12 May 2004 23:06:52 +0200 (CEST)
Received: from arport (t12o913p16.telia.com [213.64.28.136]) by smtp3-1-sn1.fre.skanova.net (Postfix) with SMTP id 0BBC037E49; Wed, 12 May 2004 23:06:33 +0200 (CEST)
Message-ID: <001001c43864$e11bb130$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "David P. Kemp" <[e-mail]>, <[e-mail]>
References: <005701c3e08e$9b392fe0$[e-mail]> <00c701c3e121$0ae3af90$0500a8c0@arport> <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
Date: Wed, 12 May 2004 23:01:23 +0200
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 is my hope that PI will become an RFC in the near future, so
>that certificates (from an un-named large PKI :-) that currently
>handle PIs by munging them into Common Name (e.g.,
>CN="Kemp.David.P.0514101404") will have a saner alternative.

The de-facto standard, already engraved in *millions* of certs is
putting 0514101404 in serialNumber. 

This is almost as de-facto standard as putting e-mail addresses in DNs
which in turn is almost as de-facto standard as using URIs for naming
globally unique objects.

C:\Internet-Drafts>del draft-ietf-pkix-pi-*.txt

:-)

Pardon my complaints, let there be an RFC!  But don't expect
this scheme to become the trend.

There is a slight problem with the whole idea.  Either RPs require
and act upon the PI-data or they don't care about it.  This in my
opinion makes the extension redundant or is just another way
to screw up validation.

If you on top of this add policy extensions I believe a real disaster
is in the making.

Anders



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CJGOVk048907; Wed, 12 May 2004 12:16:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CJGOLK048906; Wed, 12 May 2004 12:16:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-in.m-online.net (mail-in.m-online.net [62.245.150.237]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CJGNqC048893 for <[e-mail]>; Wed, 12 May 2004 12:16:23 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.m-online.net (svr14.m-online.net [192.168.3.144]) by svr8.m-online.net (Postfix) with ESMTP id 3B5544BA6C; Wed, 12 May 2004 21:16:22 +0200 (CEST)
Received: from hagen (ppp-82-135-6-58.mnet-online.de [82.135.6.58]) by mail.m-online.net (Postfix) with ESMTP id E677EA92C4; Wed, 12 May 2004 21:16:21 +0200 (CEST)
From: "Florian Oelmaier" <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: SCVP & validation policies
Date: Wed, 12 May 2004 21:16:18 +0200
Organization: SyTrust
Message-ID: <011c01c43855$9ab957b0$4228a8c0@hagen>
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.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
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>

> Hi Denis,
> Any software does not have a clue abut most things in life. 
> To operate the administrator of the client has to have 
> understand what is going on. If the administrator does not 
> understand what the implications of their actions are, then 
> they make mistakes. Your premise is that simplified 
> administration is only possible in the case of SCVP by the 
> use of the OID. Given there is a vast quantity of 
> administration software which his able to present simple 
> choices to the administrator while at the same time 
> configuring multiple parameters without there knowledge mean 
> this is not the case. Trevor

There are different roles in the administration. And the "usual
administrator for client software" is a rather different role than the
role of a security administrator. In the meantime (mostly due to the bad
experiences) this is a general accepted model. In most enterprises there
are different people responsible for operating the client and for
managing the security. 

Thus I dont think it is necessary for a client administrator to
understand the implications of settings necessary for certificate
validation. From my perspective there is a move in all areas of security
to strip as many security relevant configuration setting from the client
as possible. And I think it is widespread consensus on this list that
this could be done with SCVP by the use of the OID as a reference to the
validation policy as the sole configuration item.

Florian

> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Wednesday, May 12, 2004 12:25 AM
> To: Trevor Freeman
> Cc: [e-mail]
> Subject: Re: SCVP & validation policies
> 
> Trevor,
> 
> > You also have to understand enough so that the administrative
> > configuration of the client is generating the right kind of 
> request. 
>  > > SCVP client is ?only following orders? in many instances 
> and has from a The SCVP client is "only following orders" in 
> many instances and has  > from a perspective no idea if it is 
> the right kind of request, only if it  > is well formed to 
> the rules it has been given. Both the administrator of
> > the client and the administrator of the server has to understand in
> much 
> > grater detail what the given policy is. Once you abstract though the
> > OID, you are placing a greater burden on the OOB admin to admin
> process.
> 
> The client does not have to "understand" what the validation given
> policy is.
> 
> The client only needs to know that, for a given application a 
> given OID
> for 
> the validation policy is needed. He does not need to have a 
> clue of the 
> details of the validation policy which may remain fully opaque to him.
> 
> This means that any validation specific parameter must *not* 
> be part of
> the 
> standard request.
> 
> Denis
> 
> 
> > Trevor
> > 
> >  
> > 
> >
> --------------------------------------------------------------
> ----------
> > 
> > From: James Jing [mailto:[e-mail]]
> > Sent: Tuesday, May 11, 2004 5:09 PM
> > To: Trevor Freeman; [e-mail]
> > Subject: RE: SCVP & validation policies
> > 
> >  
> > 
> > Agree that the client needs to have all the data in order 
> to build the
> 
> > request. However, I think ?understand? is too strong a requirement.
> The 
> > client may not need to ?understand? the data, some of which may be 
> > factors affecting the server only. Perhaps I am too 
> pedantic about the
> 
> > word ?understand?.
> > 
> >  
> > 
> > Back to indirection, if ?understanding? is not a 
> requirement, then the
> 
> > client need not to be aware that an OID is an indirection 
> to a set of 
> > policies.
> > 
> >  
> > 
> > James
> > 
> >  
> > 
> >
> --------------------------------------------------------------
> ----------
> > 
> > From: Trevor Freeman [mailto:[e-mail]]
> > Sent: Wednesday, 12 May 2004 9:49 AM
> > To: James Jing; [e-mail]
> > Subject: RE: SCVP & validation policies
> > 
> >  
> > 
> > The client has to understand what is required to build a 
> request i.e.
> > What data does it need to supply to the server. It does not 
> need to be
> > aware of the factors which effect the server.
> > Trevor
> > 
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]]
> > On Behalf Of James Jing
> > Sent: Tuesday, May 11, 2004 4:01 PM
> > To: [e-mail]
> > Subject: RE: SCVP & validation policies
> > 
> >  
> > 
> > I think policy OIDs should remain abstract, or at least can be
> abstract.
> > That is that there is no requirement for the client software to
> > understand the parameters.
> > 
> > I am more thinking of using SCVP to validate a certificate in the
> > context of a transaction, where the policy OID in SCVP might be used
> to
> > identify such a context to the server.
> > 
> > For example, a certificate validation request is carried out with
> regard
> > to the acceptability of the holder's creditworthiness in the context
> of
> > a credit-based transaction. In this case, the policy OID 
> could be used
> > to indicate the class of assuarances that the CA's CSP provides for,
> > resulting in the server selecting a subset of acceptable trust
> anchors.
> > 
> > James
> > 
> >  
> > 
> > -----Original Message-----
> > From: Stephen Kent [mailto:[e-mail]]
> > Sent: Friday, 7 May 2004 6:28 AM
> > To: Trevor Freeman
> > Cc: [e-mail]
> > Subject: RE: SCVP & validation policies
> > 
> >  
> > 
> > At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
> >>Hi Steve,
> >>If you want to have a shorthand notation for a validation policy,
> given
> > 
> >>we have a finite set of parameters, the I don't see the value of
> >>indirection via an OID. Using a hash of the set of inputs provides a
> >>way of expressing the same thing without introducing 
> ambiguity of does
> >>both parties have a common understating of that this means. At some
> >>point someone has to define the policy in terms of the 3280 input
> > parameters.
> >>That definition is just as applicable and consumable by the 
> client as
> a
> > 
> >>server therefore what did we gain from the shorthand notation? It
> would
> > 
> >>be pretty trivial to define some XML which would allow that set of
> >>validation parameters to be imported by any SCVP entity.
> >>Trevor
> > 
> > Trevor,
> > 
> > It is not indirection via an OID, it is identification via an OID.
> > Clients never have to be aware of the parameters if we use 
> an OID, and
> > simplification of clients is one of the goals of SCVP. So I cannot
> agree
> > with your comment that clients have to be able to consume these
> > parameters.
> > 
> > Given that as a basis, it seems that we are debating whether to use
> OIDs
> > or to create some other form of identifier via hashing parameters. I
> > don't see the latter as attractive, since it requires additional
> > specification of the canonicalization and encoding of the parameters
> to
> > ensure consistency in hash computation between client and server.
> > 
> > Steve
> > 
> >  
> > 
> > This e-mail, and any attachments hereto, is intended only for use by
> the 
> > named addressee(s) and may contain legally privileged and/or 
> > confidential information.  If you are not the intended 
> recipient, you 
> > are hereby notified that any dissemination, distribution or 
> copying of
> 
> > this e-mail, and any attachments hereto, is strictly prohibited.  If
> you 
> > have received this transmission in error, please notify me 
> immediately
> 
> > and permanently delete the original and all copies and printouts of
> this 
> > e-mail.
> > 
> 
> 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CJ0bac047776; Wed, 12 May 2004 12:00:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CJ0bE1047775; Wed, 12 May 2004 12:00:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CJ0bir047769 for <[e-mail]>; Wed, 12 May 2004 12:00:37 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 12 May 2004 12:00:41 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 May 2004 12:00:41 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 May 2004 12:00:40 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP & validation policies
Date: Wed, 12 May 2004 12:00:39 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
thread-index: AcQ4ThklIu4lLosSSIeWZksBBllP7gABLKWw
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 12 May 2004 19:00:40.0881 (UTC) FILETIME=[6B6AAA10:01C43853]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4CJ0bir047770
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
The problem of having to push policy to clients of all descriptions is a
well understood problem set. The infrastructure to do that is the main
overhead. The number of parameters associated with that process is not a
significant overhead.
Trevor

-----Original Message-----
From: Peter Sylvester [mailto:[e-mail]] 
Sent: Wednesday, May 12, 2004 11:23 AM
To: [e-mail]; Trevor Freeman
Cc: [e-mail]
Subject: RE: SCVP & validation policies

trevor,

Your clients may need to be updated each time you change anything
in the structure of your certs, or in the rules of the policies,

Any code that can be avoided, seems good to me in line with
the requirement for dumb client support.   

> 
> Hi Denis,
> Any software does not have a clue abut most things in life. To operate
> the administrator of the client has to have understand what is going
on.
> If the administrator does not understand what the implications of
their
> actions are, then they make mistakes. Your premise is that simplified
> administration is only possible in the case of SCVP by the use of the
> OID. Given there is a vast quantity of administration software which
his
> able to present simple choices to the administrator while at the same
> time configuring multiple parameters without there knowledge mean this
> is not the case.
> Trevor
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CISF20045697; Wed, 12 May 2004 11:28:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CISFsO045696; Wed, 12 May 2004 11:28:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CISErd045690 for <[e-mail]>; Wed, 12 May 2004 11:28:14 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 12 May 2004 11:28:18 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 May 2004 11:28:18 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 May 2004 11:28:17 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP & validation policies
Date: Wed, 12 May 2004 11:28:18 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
thread-index: AcQ4An82dGYpctolT6i0rcvrW0RAGAAPl/ZQ
From: "Trevor Freeman" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 12 May 2004 18:28:17.0944 (UTC) FILETIME=[E5560180:01C4384E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4CISErd045691
Sender: [e-mail]
Precedence: 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 Wen-Cheng,
In scenario 1, the use of and validation policy OID option in a request
is superfluous. The SCVP client simply submits the request and the
server uses its default policy.
In scenario 3 there are two way to achieve this with SCVP. The client
and can be configured with a set of OIDs to represent the policy, or
they can by configured wit the set of parameters to submit. In both
cases the SCVP server certifies the request matches its local policy
before processing the request.
Trevor

-----Original Message-----
From: Wen-Cheng Wang [mailto:[e-mail]] 
Sent: Wednesday, May 12, 2004 2:21 AM
To: Denis Pinkas; Trevor Freeman
Cc: Stephen Kent; [e-mail]
Subject: Re: SCVP & validation policies

I would like to support that even the validation policy OID itself is
optional for the client to use. As I stated in my earlier post, if a
client
fully trust the validation server, then it might not have to specify a
validation policy OID in its request. In that case, it means that the
client trusts the validation server to adopt the default validation
policy
predefinied by the management authority of the application domain
(such as an enterprise). For example, in scenario 1 and scenario 3 I
mentioned in my earlier post, if the client request does not specify any
validation policy OID, then server will adopt the default validation
policy. For you reference, scenario 1 and scenario 3 are as follows:

Scenario 1 (single central-managed vlidation policy)

  DPV server:
      only supports a single central-managed vlidation policy
      the validation policy implies all policy-dependent parameters

  DPV client:
      the validation request may optionally specify the vlidation policy
OID
      the validation request needs not specify any policy-dependent
          parameters

Scenario 3 (multiple central-managed vlidation policies with a default
validation policy)

  DPV server:
      supports multiple central-managed vlidation policies with one of
them
          is the default
      each validation policy implies its policy-dependent parameters

  DPV client:
      the validation request should specify the vlidation policy OID
      if the request did not specify the vlidation policy OID, then the
         server will use the default one
      the validation request needs not to specify any policy-dependent
         parameters

These are the simplest cases of the use of DPV protocol. I hope that
basic SCVP syntax should support these simplest cases more clearly.
(I mean that the ambiguity in the current syntax should be reduced.)

In contrast to these simplest cases, an extreme case of the use of
DPV protocol is the case where there is no any predefined validation
policy (and hence no default validation policy). This might be the case
where a DPV server is used as a public server. (The scenario 4 I
mentioned earlier.) Please note that in this extreme case, the client
has
no way to specify any validation policy OID in its request since there
is no any predefined one.  In this extreme case, the client will have to
submit the full set of parameters for path validation ALGORITHM. I
would like to see SCVP to provide an extension mechanism to
let the client submit the full set of parameters for path validation
ALGORITHM. However, please do not confuse "parameters for
validation ALGORITHM" with "parameters for validation POLICY".
Also, please make a clear separation of basic SCVP syntax and
the extension mechanism for submitting parameters for path
validation ALGORITHM.

Wen-Cheng Wang

>
> Trevor,
>
> > Hi Dennis,
> > The OID is optional for the client to use. Servers don't have to
support
> > this.
>
> I disagree. The "RFC 3280 compliantbasic validation policy", i.e the
one
> which only includes basic path validation, with no extra and no
shortcuts,
> as defined by RFC 3280, will have an OID. Since this policy does not
> contains values such as root keys, this validation policy needs
additional
> parameters.
>
> Intelligent clients may use this one and specify parameters.
>
> Thin clients will simply refer to an OID which refers globally to a
> validation algorithm and its parameters.
>
> I have talked to customers and their position is to have flexible
validation
> policies. As an example, some says: if we want to take purposely the
risk
of
> not testing ARLs, it is our choice. The validation policy should not
mandate
> to test ARLs, but if for some validation policies it is adequate to do
so,
> it should be possible to do so.
>
> > It become a matter of mutual agreement between the client and
> > server what the OID represents.
>
> Not necessarilly. Since the OID is not in the arc of the server, it
may be
> defined by anyone. If that definition is separately accessible both to
the
> client and to the server then it can be supported by the server and
the
> client may refer to it. In such a case there is no need for a mutual
agreement.
>
> > An SCVP server must either comply with any request or return an
error
>
> True.
>
>  > so I don't see the validation policy OID
> > needs any special treatment beyond want SCVP already defines.
>
> I don't see the relationship between the true statement above and the
> conclusion.
>
> As already stated on this list, SCVP stands for "Simple", otherwise we
will
> have to drop the "S", and then we would have "CVP". :-|
>
> Denis
>
> > Trevor




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CIMdUb045305; Wed, 12 May 2004 11:22:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CIMdQl045304; Wed, 12 May 2004 11:22:39 -0700 (PDT)
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.11/8.12.9) with ESMTP id i4CIMbwG045297 for <[e-mail]>; Wed, 12 May 2004 11:22:38 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i4CIMeN18865; Wed, 12 May 2004 20:22:40 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 12 May 2004 20:22:40 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i4CIMdE16565; Wed, 12 May 2004 20:22:39 +0200 (MEST)
Date: Wed, 12 May 2004 20:22:39 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP & validation policies
Cc: [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>

trevor,

Your clients may need to be updated each time you change anything
in the structure of your certs, or in the rules of the policies,

Any code that can be avoided, seems good to me in line with
the requirement for dumb client support.   

> 
> Hi Denis,
> Any software does not have a clue abut most things in life. To operate
> the administrator of the client has to have understand what is going on.
> If the administrator does not understand what the implications of their
> actions are, then they make mistakes. Your premise is that simplified
> administration is only possible in the case of SCVP by the use of the
> OID. Given there is a vast quantity of administration software which his
> able to present simple choices to the administrator while at the same
> time configuring multiple parameters without there knowledge mean this
> is not the case.
> Trevor
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CI9fMw043764; Wed, 12 May 2004 11:09:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CI9fic043763; Wed, 12 May 2004 11:09:41 -0700 (PDT)
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.11/8.12.9) with ESMTP id i4CI9eYU043751 for <[e-mail]>; Wed, 12 May 2004 11:09:40 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i4CI9YN18602; Wed, 12 May 2004 20:09:34 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 12 May 2004 20:09:34 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i4CI9XG16517; Wed, 12 May 2004 20:09:33 +0200 (MEST)
Date: Wed, 12 May 2004 20:09:33 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP & validation policies
Cc: [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>

Denis, 

I assume you mean 'minimal' instead of 'standard',
'the standard rerequest for a very dumb client'
 
> This means that any validation specific parameter must *not* be part of
> the standard request.
> 
> Denis



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CHgs5i041686; Wed, 12 May 2004 10:42:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CHgswM041685; Wed, 12 May 2004 10:42:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CHgs5m041678 for <[e-mail]>; Wed, 12 May 2004 10:42:54 -0700 (PDT) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Wed, 12 May 2004 11:45:17 -0400
From: "David P. Kemp" <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
References: <005701c3e08e$9b392fe0$[e-mail]> <00c701c3e121$0ae3af90$0500a8c0@arport> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 12 May 2004 15:45:17.0878 (UTC) FILETIME=[1FF65D60:01C43838]
Sender: [e-mail]
Precedence: 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,

It is my hope that PI will become an RFC in the near future, so
that certificates (from an un-named large PKI :-) that currently
handle PIs by munging them into Common Name (e.g.,
CN="Kemp.David.P.0514101404") will have a saner alternative.

Comments:

"Assigner Authority and Type" could and should be better explained,
in the I-D / RFC, but it is also clear what it means without such
an explanation.  See www.acq.osd.mil/uid/policy.html,
"Guide to Uniquely Identifying Items" for an example.  The
guide defines five "Issuing Agencies" (assigner authorities)
where each issuing agency defines the type of identifier it
assigns.  The issuing agencies (and types) are:

   1. EAN-International (EAN.UCC company prefix that goes on the
barcode of everything you buy in the supermarket)

   2. Telcordia Technologies (ANSI T1.220 numbers)

   3. Dun & Bradstreet (DUNS number)

   4. Allied Committee 135 (CAGE code - look up your favorite
company's number at www.dlis.dla.mil/cage_welcome.asp)

   5. European Health Industry Business Communications Council
(EHIBCC number)

There should not be a large number of PI assigner authorities,
but there will be more than five and the list will grow, so they
can't be enumerated within the RFC itself.   It is reasonable
to identify them by IANA-assigned value, or by OID.  It is not
completely unreasonable to identify them by URI, but there is
an impedance mismatch between the goals of PI (physical
organizations with stable business processes to establish
reliable identifiers) and the mechanism of URI (put up a
document/resource somewhere in cyberspace).  Not that a URI
couldn't point to a substantial, permanent organization, or
that the target of an OID couldn't be ephemeral, but OIDs
do have a more substantial "flavor" than URIs.

More to the point, an OID tells a machine implementation what
to do with a PI, whereas a URI is presumably intended to cause
the implementation to make an online access to find out what
to do.  That is an unreasonable burden.

I believe that the syntax of PI-08 is fine as is, and that with
Jim Schaad's corrections and perhaps some more explanatory text
the draft is ready to become an RFC.

Dave



Denis Pinkas wrote:
> 
> 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



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CG5uIe034533; Wed, 12 May 2004 09:05:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CG5ujK034532; Wed, 12 May 2004 09:05:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CG5tHx034526 for <[e-mail]>; Wed, 12 May 2004 09:05:55 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Wed, 12 May 2004 09:05:58 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 May 2004 09:05:52 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 May 2004 09:05:57 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP & validation policies
Date: Wed, 12 May 2004 09:05:56 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
thread-index: AcQ38jxRpgWQ5+FbQcCKCGuLYN1ZZgAR7fGw
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 12 May 2004 16:05:57.0772 (UTC) FILETIME=[02FF2CC0:01C4383B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4CG5tHx034527
Sender: [e-mail]
Precedence: 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,
Any software does not have a clue abut most things in life. To operate
the administrator of the client has to have understand what is going on.
If the administrator does not understand what the implications of their
actions are, then they make mistakes. Your premise is that simplified
administration is only possible in the case of SCVP by the use of the
OID. Given there is a vast quantity of administration software which his
able to present simple choices to the administrator while at the same
time configuring multiple parameters without there knowledge mean this
is not the case.
Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Wednesday, May 12, 2004 12:25 AM
To: Trevor Freeman
Cc: [e-mail]
Subject: Re: SCVP & validation policies

Trevor,

> You also have to understand enough so that the administrative 
> configuration of the client is generating the right kind of request. 
 > > SCVP client is ?only following orders? in many instances and has
from a The SCVP client is "only following orders" in many instances and
has
 > from a perspective no idea if it is the right kind of request, only
if it
 > is well formed to the rules it has been given. Both the administrator
of
> the client and the administrator of the server has to understand in
much 
> grater detail what the given policy is. Once you abstract though the 
> OID, you are placing a greater burden on the OOB admin to admin
process.

The client does not have to "understand" what the validation given
policy is.

The client only needs to know that, for a given application a given OID
for 
the validation policy is needed. He does not need to have a clue of the 
details of the validation policy which may remain fully opaque to him.

This means that any validation specific parameter must *not* be part of
the 
standard request.

Denis


> Trevor
> 
>  
> 
>
------------------------------------------------------------------------
> 
> From: James Jing [mailto:[e-mail]]
> Sent: Tuesday, May 11, 2004 5:09 PM
> To: Trevor Freeman; [e-mail]
> Subject: RE: SCVP & validation policies
> 
>  
> 
> Agree that the client needs to have all the data in order to build the

> request. However, I think ?understand? is too strong a requirement.
The 
> client may not need to ?understand? the data, some of which may be 
> factors affecting the server only. Perhaps I am too pedantic about the

> word ?understand?.
> 
>  
> 
> Back to indirection, if ?understanding? is not a requirement, then the

> client need not to be aware that an OID is an indirection to a set of 
> policies.
> 
>  
> 
> James
> 
>  
> 
>
------------------------------------------------------------------------
> 
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Wednesday, 12 May 2004 9:49 AM
> To: James Jing; [e-mail]
> Subject: RE: SCVP & validation policies
> 
>  
> 
> The client has to understand what is required to build a request i.e.
> What data does it need to supply to the server. It does not need to be
> aware of the factors which effect the server.
> Trevor
> 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of James Jing
> Sent: Tuesday, May 11, 2004 4:01 PM
> To: [e-mail]
> Subject: RE: SCVP & validation policies
> 
>  
> 
> I think policy OIDs should remain abstract, or at least can be
abstract.
> That is that there is no requirement for the client software to
> understand the parameters.
> 
> I am more thinking of using SCVP to validate a certificate in the
> context of a transaction, where the policy OID in SCVP might be used
to
> identify such a context to the server.
> 
> For example, a certificate validation request is carried out with
regard
> to the acceptability of the holder's creditworthiness in the context
of
> a credit-based transaction. In this case, the policy OID could be used
> to indicate the class of assuarances that the CA's CSP provides for,
> resulting in the server selecting a subset of acceptable trust
anchors.
> 
> James
> 
>  
> 
> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Friday, 7 May 2004 6:28 AM
> To: Trevor Freeman
> Cc: [e-mail]
> Subject: RE: SCVP & validation policies
> 
>  
> 
> At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
>>Hi Steve,
>>If you want to have a shorthand notation for a validation policy,
given
> 
>>we have a finite set of parameters, the I don't see the value of
>>indirection via an OID. Using a hash of the set of inputs provides a
>>way of expressing the same thing without introducing ambiguity of does
>>both parties have a common understating of that this means. At some
>>point someone has to define the policy in terms of the 3280 input
> parameters.
>>That definition is just as applicable and consumable by the client as
a
> 
>>server therefore what did we gain from the shorthand notation? It
would
> 
>>be pretty trivial to define some XML which would allow that set of
>>validation parameters to be imported by any SCVP entity.
>>Trevor
> 
> Trevor,
> 
> It is not indirection via an OID, it is identification via an OID.
> Clients never have to be aware of the parameters if we use an OID, and
> simplification of clients is one of the goals of SCVP. So I cannot
agree
> with your comment that clients have to be able to consume these
> parameters.
> 
> Given that as a basis, it seems that we are debating whether to use
OIDs
> or to create some other form of identifier via hashing parameters. I
> don't see the latter as attractive, since it requires additional
> specification of the canonicalization and encoding of the parameters
to
> ensure consistency in hash computation between client and server.
> 
> Steve
> 
>  
> 
> This e-mail, and any attachments hereto, is intended only for use by
the 
> named addressee(s) and may contain legally privileged and/or 
> confidential information.  If you are not the intended recipient, you 
> are hereby notified that any dissemination, distribution or copying of

> this e-mail, and any attachments hereto, is strictly prohibited.  If
you 
> have received this transmission in error, please notify me immediately

> and permanently delete the original and all copies and printouts of
this 
> e-mail.
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CCEuPj014071; Wed, 12 May 2004 05:14:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CCEuhh014070; Wed, 12 May 2004 05:14:56 -0700 (PDT)
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.11/8.12.9) with ESMTP id i4CCEt9V014059 for <[e-mail]>; Wed, 12 May 2004 05:14:55 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i4CCEtN12679; Wed, 12 May 2004 14:14:55 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 12 May 2004 14:14:55 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i4CCEs614503; Wed, 12 May 2004 14:14:54 +0200 (MEST)
Date: Wed, 12 May 2004 14:14:54 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: SCVP & validation policies
Cc: [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>

> 
> Hi Peter,
> I think saying the client must validate the ku itself is a big jump, so
> allowing the client to pass lets them choose how must certificate
> processing they perform.
Do you think that it is good, or not?
 
I am not sure that is a good and/or whether this corresponds to the
idea of totally centralized validation, i.e. minimal processing
at the client side.

I tend to say that the client should only be required to
use the public key.

> 
> For the requestor, I don't see any other processing than as binary blob
> is necessary. Therefore if you have an octet string, the server just
> does a binary companies on the data.

This is not conformant with the requirements, the server needs some
way to match the identifiers with the authenticated identities. To me, an
an almost opaque octet string doesn't seem the right approach.
In fact, you don't have a binary blob, since you don't allow zeros,
for example, if a client want to put a hash of something.


I propose the following compromise:

  Identifiers ::= SEQUENCE OF { 
          CHOICE {
               opaqueId OCTET STRING,
               nameId GeneralName
          }

and a statement says that in order to compare for loop detection, a server
will do a comparision of the encoded element (including the tag).

and use this as the type for requestor and responder



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CC835v013248; Wed, 12 May 2004 05:08:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CC83C9013247; Wed, 12 May 2004 05:08:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CC7tIf013226 for <[e-mail]>; Wed, 12 May 2004 05:07:56 -0700 (PDT) (envelope-from [e-mail])
Received: from ms21.chttl.com.tw (ms21 [10.144.2.121]) by fw.chttl.com.tw (8.12.10/8.12.10) with ESMTP id i4CC7PGG008856; Wed, 12 May 2004 20:07:26 +0800
Received: (from root@localhost) by ms21.chttl.com.tw (8.12.10/8.12.10) id i4CC7QLU029080; Wed, 12 May 2004 20:07:26 +0800
Received: from wcwang ([10.144.133.79]) by ms21.chttl.com.tw (8.12.10/8.12.10) with SMTP id i4CC7OL5028759; Wed, 12 May 2004 20:07:24 +0800
Message-ID: <01b301c43819$ae046d00$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Santoni Adriano" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Steve Hanna" <[e-mail]>
References: <[e-mail]>
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String inencodingRDNs
Date: Wed, 12 May 2004 20:07:20 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: [e-mail]
Precedence: 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,

Although I personally prefer to remain it as a 'MUST', but if
PKIX WG majority decide to change it to be a 'SHOULD',
I will accept that.

Another compromise is not to REQUIRE CAs established
before the deadline to migrate to UTF8String encoding. That is,
if an old CA already use PrintableString encoding it can continue
to use PrintableString encoding. One day if the old CA need
perform to key rollover, it is STRONGLY RECOMMENDED (MUST?)
to take that opportunity to migrate to UTF8String encoding.
For CAs established after the deadline, it is STRONGLY
RECOMMENDED (MUST?) to adopt UTF8String encoding
from the beginning. By doing so, I believe that the infrastructure
will ultimately uniform the name encoding.

As for the deadline, since the deadline REQUIRED by RFC 3280
had already been past and it did not come true, a new deadline will
be needed.

Wen-Cheng Wang

> 
> Wen-Cheng,
> 
> I think we agree on the theory parts. No need to repeat them.
> 
> The only disagreement is whether RFC 3280 should REQUIRE UTF-8 where
> printable string is sufficient.
> 
> I think it should not do so. It should limit itself to a recommendation
> (SHOULD)
> 
> RFC 3280 is an important profile, and while it may seem as a voluntary
> profile for many, it is actually something that gets imposed as real
> requirements for others.
> 
> Requiring UTF-8 causes interoperability problems, also among those who
> have faithfully followed RFC 3280, and thus it is a bad requirement.
> 
> I also pledge that name encoding rollover certificates, as specified in
> RFC 3280 is in error and thus has little merit in the real world.
> Migration should thus be allowed in such pase that no name
> encoding-rollover certificates are needed.
> 
> 
> ----
> Except from this I agree that we should try to fix X.509 name matching
> in RFC 3280 name constraining, which is a bug. But that is a separate
> issue.
> 
> /Stefan
> 
> > -----Original Message-----
> > From: Wen-Cheng Wang [mailto:[e-mail]]
> > Sent: den 12 maj 2004 11:11
> > To: Stefan Santesson; Stephen Kent; Santoni Adriano
> > Cc: [e-mail]; [e-mail]; Steve Hanna
> > Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
> > encodingRDNs
> > 
> > > Yes, you can do a lot of cool things in theory.
> > >
> > > The cruel truth is that your name encoding roll-over certs (e.g.
> > > CA1-CA1-p-u-cert) is not self issued according to RFC 3280.
> > 
> > That is why I said that the definition of self-issued certificates in
> RFC
> > 3280 (or maybe its definition in the X.509 standard itself) should
> > be revised or be clarified in son-of-3280 (or in an amendment of
> > the X.509 standard as well).
> > 
> > >
> > > RFC 3280 section 6.1:
> > >    A certificate is self-issued if the DNs that appear in the
> subject
> > >    and issuer fields are identical and are not empty.
> > >
> > > RFC 3280 section 4.1.2.4:
> > >       (a)  attribute values encoded in different types (e.g.,
> > >       PrintableString and BMPString) MAY be assumed to represent
> > >       different strings;
> > 
> > Remenber that RFC 3280 section 4.1.2.4 also said:
> > 
> >    Implementations of this profile are permitted to use the comparison
> >    algorithm defined in the X.500 series.
> > 
> > In that respect, you can not said that name rollover certificates are
> not
> > self-issued.
> > 
> > >
> > > So in current implementations of RFC 3280, many valid certificates
> will
> > > fail after introduction of name rollover certs in the chain, because
> > > path validation will not treat them as self-issued.
> > 
> > I admit that most CURRENT implementations of RFC 3280 path
> > validation will fail to treat name rollover certificates as
> self-issued,
> > but
> > it does not mean that we should not recommend FUTURE revisions
> > of those implementations and new implementations to treat them as
> > self-issued.
> > 
> > >
> > > Further, the name constraint problem persists, adds to this but also
> > > exist regardless of this problem.
> > >
> > > RFC 3280 section 4.2.1.11
> > >    When applying restrictions of the form directoryName, an
> > >    implementation MUST compare DN attributes.  At a minimum,
> > >    implementations MUST perform the DN comparison rules specified in
> > >    Section 4.1.2.4.
> > 
> > That is why I said RFC 3280 path validation algorithm should also be
> > revised.
> > 
> > >
> > > Fixing next version of RFC 3280 to include better name matching
> rules is
> > > a good thing but far from enough to take care of real problems with
> > > current infrastructure.
> > 
> > Fixing next version of RFC 3280 does not magically take care of real
> > problems with current infrastructure, but it encourge current
> > infrastructure
> > to migrate to solve the problems.
> > 
> > >
> > > We have to try to keep in mind what we make all this hassle for!!
> > >
> > > This is NOT about whether we should use UTF-8 or not to accommodate
> > > complex character sets!! This is about what we are prepared to do to
> > > make sure NOTHING is encoded as PrintableString WHEN PrintableString
> is
> > > sufficient.
> > >
> > > This old transition rule was created in RFC 2459 before the modern
> path
> > > validation algorithm was invented and before self-issued
> certificates
> > > was a special case.
> > 
> > That does not mean that name rollover certificates can not solve the
> > mixed name-encoding  problem.
> > 
> > >
> > > Let's just admit that we overlooked this issue when we created RFC
> 3280
> > > and reshaped path validation. It was an understandable human error,
> > > which lead to a defect.
> > 
> > Yes, RFC 3280 indeed overlooked this issue. That is why it should be
> > revised.
> > 
> > >
> > > So let's then also admit that REQUIRING UTF-8 when printableString
> is
> > > sufficient, is not a very good idea when all practical matters are
> > > measured, and that it never should have made it to more than a
> > > RECOMMENDATION.
> > 
> > Isn't it the IETF policy to encourge all new implementations to
> migrate
> > to support UTF-8? The philosophy is that if one encoding is sufficient
> to
> > cover universal characters, why should we recommend two?
> > 
> > >
> > > Whatever we say here, this is a requirement that many implementers
> will
> > > have to ignore for a many years to come.
> > 
> > Conformance to any IETF RFC is all voluntary. No one can enfoce any
> > implementer for that if the implementer chooses to ignore the
> requirement
> > or recommendation of any IETF RFC. RFC 3280 might not have the
> > power to enforce all implementation to migrate to UTF-8 encoding.
> > However, as an IETF RFC, it definitely has a great effect. At least, I
> > see more and more applications can correctly handle certificates with
> > named in UTF-8 encoding. Therefore, I prefer to see son-of-3280 to
> > continue requiring conformant implementations to migrate to UTF-8
> > encoding.
> > 
> > Wen-Cheng Wang
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4CAOvnK005210; Wed, 12 May 2004 03:24:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4CAOvQ7005209; Wed, 12 May 2004 03:24:57 -0700 (PDT)
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.9) with ESMTP id i4CAOtGE005185 for <[e-mail]>; Wed, 12 May 2004 03:24:56 -0700 (PDT) (envelope-from [e-mail])
Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.22]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 May 2004 11:24:51 +0100
Received: from 65.53.196.22 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 12 May 2004 11:24:51 +0100
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); Wed, 12 May 2004 11:24:51 +0100
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encodingRDNs
Date: Wed, 12 May 2004 11:24:43 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: R: I: R: RFC3280: doubt on the use of UTF8String in encodingRDNs
Thread-Index: AcQ4ARpDL01IydVqQZCUq3EkBtxLuQAB08Yg
From: "Stefan Santesson" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Santoni Adriano" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Steve Hanna" <[e-mail]>
X-OriginalArrivalTime: 12 May 2004 10:24:51.0484 (UTC) FILETIME=[5C2375C0:01C4380B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4CAOuGE005204
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Wen-Cheng,

I think we agree on the theory parts. No need to repeat them.

The only disagreement is whether RFC 3280 should REQUIRE UTF-8 where
printable string is sufficient.

I think it should not do so. It should limit itself to a recommendation
(SHOULD)

RFC 3280 is an important profile, and while it may seem as a voluntary
profile for many, it is actually something that gets imposed as real
requirements for others.

Requiring UTF-8 causes interoperability problems, also among those who
have faithfully followed RFC 3280, and thus it is a bad requirement.

I also pledge that name encoding rollover certificates, as specified in
RFC 3280 is in error and thus has little merit in the real world.
Migration should thus be allowed in such pase that no name
encoding-rollover certificates are needed.


----
Except from this I agree that we should try to fix X.509 name matching
in RFC 3280 name constraining, which is a bug. But that is a separate
issue.

/Stefan

> -----Original Message-----
> From: Wen-Cheng Wang [mailto:[e-mail]]
> Sent: den 12 maj 2004 11:11
> To: Stefan Santesson; Stephen Kent; Santoni Adriano
> Cc: [e-mail]; [e-mail]; Steve Hanna
> Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
> encodingRDNs
> 
> > Yes, you can do a lot of cool things in theory.
> >
> > The cruel truth is that your name encoding roll-over certs (e.g.
> > CA1-CA1-p-u-cert) is not self issued according to RFC 3280.
> 
> That is why I said that the definition of self-issued certificates in
RFC
> 3280 (or maybe its definition in the X.509 standard itself) should
> be revised or be clarified in son-of-3280 (or in an amendment of
> the X.509 standard as well).
> 
> >
> > RFC 3280 section 6.1:
> >    A certificate is self-issued if the DNs that appear in the
subject
> >    and issuer fields are identical and are not empty.
> >
> > RFC 3280 section 4.1.2.4:
> >       (a)  attribute values encoded in different types (e.g.,
> >       PrintableString and BMPString) MAY be assumed to represent
> >       different strings;
> 
> Remenber that RFC 3280 section 4.1.2.4 also said:
> 
>    Implementations of this profile are permitted to use the comparison
>    algorithm defined in the X.500 series.
> 
> In that respect, you can not said that name rollover certificates are
not
> self-issued.
> 
> >
> > So in current implementations of RFC 3280, many valid certificates
will
> > fail after introduction of name rollover certs in the chain, because
> > path validation will not treat them as self-issued.
> 
> I admit that most CURRENT implementations of RFC 3280 path
> validation will fail to treat name rollover certificates as
self-issued,
> but
> it does not mean that we should not recommend FUTURE revisions
> of those implementations and new implementations to treat them as
> self-issued.
> 
> >
> > Further, the name constraint problem persists, adds to this but also
> > exist regardless of this problem.
> >
> > RFC 3280 section 4.2.1.11
> >    When applying restrictions of the form directoryName, an
> >    implementation MUST compare DN attributes.  At a minimum,
> >    implementations MUST perform the DN comparison rules specified in
> >    Section 4.1.2.4.
> 
> That is why I said RFC 3280 path validation algorithm should also be
> revised.
> 
> >
> > Fixing next version of RFC 3280 to include better name matching
rules is
> > a good thing but far from enough to take care of real problems with
> > current infrastructure.
> 
> Fixing next version of RFC 3280 does not magically take care of real
> problems with current infrastructure, but it encourge current
> infrastructure
> to migrate to solve the problems.
> 
> >
> > We have to try to keep in mind what we make all this hassle for!!
> >
> > This is NOT about whether we should use UTF-8 or not to accommodate
> > complex character sets!! This is about what we are prepared to do to
> > make sure NOTHING is encoded as PrintableString WHEN PrintableString
is
> > sufficient.
> >
> > This old transition rule was created in RFC 2459 before the modern
path
> > validation algorithm was invented and before self-issued
certificates
> > was a special case.
> 
> That does not mean that name rollover certificates can not solve the
> mixed name-encoding  problem.
> 
> >
> > Let's just admit that we overlooked this issue when we created RFC
3280
> > and reshaped path validation. It was an understandable human error,
> > which lead to a defect.
> 
> Yes, RFC 3280 indeed overlooked this issue. That is why it should be
> revised.
> 
> >
> > So let's then also admit that REQUIRING UTF-8 when printableString
is
> > sufficient, is not a very good idea when all practical matters are
> > measured, and that it never should have made it to more than a
> > RECOMMENDATION.
> 
> Isn't it the IETF policy to encourge all new implementations to
migrate
> to support UTF-8? The philosophy is that if one encoding is sufficient
to
> cover universal characters, why should we recommend two?
> 
> >
> > Whatever we say here, this is a requirement that many implementers
will
> > have to ignore for a many years to come.
> 
> Conformance to any IETF RFC is all voluntary. No one can enfoce any
> implementer for that if the implementer chooses to ignore the
requirement
> or recommendation of any IETF RFC. RFC 3280 might not have the
> power to enforce all implementation to migrate to UTF-8 encoding.
> However, as an IETF RFC, it definitely has a great effect. At least, I
> see more and more applications can correctly handle certificates with
> named in UTF-8 encoding. Therefore, I prefer to see son-of-3280 to
> continue requiring conformant implementations to migrate to UTF-8
> encoding.
> 
> Wen-Cheng Wang




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C9Let7095269; Wed, 12 May 2004 02:21:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4C9LdFA095268; Wed, 12 May 2004 02:21:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C9LcD1095224 for <[e-mail]>; Wed, 12 May 2004 02:21:38 -0700 (PDT) (envelope-from [e-mail])
Received: from ms21.chttl.com.tw (ms21 [10.144.2.121]) by fw.chttl.com.tw (8.12.10/8.12.10) with ESMTP id i4C9KfGG027527; Wed, 12 May 2004 17:20:41 +0800
Received: (from root@localhost) by ms21.chttl.com.tw (8.12.10/8.12.10) id i4C9KfCx025690; Wed, 12 May 2004 17:20:41 +0800
Received: from wcwang ([10.144.133.79]) by ms21.chttl.com.tw (8.12.10/8.12.10) with SMTP id i4C9KfL5025586; Wed, 12 May 2004 17:20:41 +0800
Message-ID: <004501c43802$6350b460$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Trevor Freeman" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: SCVP & validation policies
Date: Wed, 12 May 2004 17:20:37 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would like to support that even the validation policy OID itself is
optional for the client to use. As I stated in my earlier post, if a client
fully trust the validation server, then it might not have to specify a
validation policy OID in its request. In that case, it means that the
client trusts the validation server to adopt the default validation policy
predefinied by the management authority of the application domain
(such as an enterprise). For example, in scenario 1 and scenario 3 I
mentioned in my earlier post, if the client request does not specify any
validation policy OID, then server will adopt the default validation
policy. For you reference, scenario 1 and scenario 3 are as follows:

Scenario 1 (single central-managed vlidation policy)

  DPV server:
      only supports a single central-managed vlidation policy
      the validation policy implies all policy-dependent parameters

  DPV client:
      the validation request may optionally specify the vlidation policy OID
      the validation request needs not specify any policy-dependent
          parameters

Scenario 3 (multiple central-managed vlidation policies with a default
validation policy)

  DPV server:
      supports multiple central-managed vlidation policies with one of them
          is the default
      each validation policy implies its policy-dependent parameters

  DPV client:
      the validation request should specify the vlidation policy OID
      if the request did not specify the vlidation policy OID, then the
         server will use the default one
      the validation request needs not to specify any policy-dependent
         parameters

These are the simplest cases of the use of DPV protocol. I hope that
basic SCVP syntax should support these simplest cases more clearly.
(I mean that the ambiguity in the current syntax should be reduced.)

In contrast to these simplest cases, an extreme case of the use of
DPV protocol is the case where there is no any predefined validation
policy (and hence no default validation policy). This might be the case
where a DPV server is used as a public server. (The scenario 4 I
mentioned earlier.) Please note that in this extreme case, the client has
no way to specify any validation policy OID in its request since there
is no any predefined one.  In this extreme case, the client will have to
submit the full set of parameters for path validation ALGORITHM. I
would like to see SCVP to provide an extension mechanism to
let the client submit the full set of parameters for path validation
ALGORITHM. However, please do not confuse "parameters for
validation ALGORITHM" with "parameters for validation POLICY".
Also, please make a clear separation of basic SCVP syntax and
the extension mechanism for submitting parameters for path
validation ALGORITHM.

Wen-Cheng Wang

>
> Trevor,
>
> > Hi Dennis,
> > The OID is optional for the client to use. Servers don't have to support
> > this.
>
> I disagree. The "RFC 3280 compliantbasic validation policy", i.e the one
> which only includes basic path validation, with no extra and no shortcuts,
> as defined by RFC 3280, will have an OID. Since this policy does not
> contains values such as root keys, this validation policy needs additional
> parameters.
>
> Intelligent clients may use this one and specify parameters.
>
> Thin clients will simply refer to an OID which refers globally to a
> validation algorithm and its parameters.
>
> I have talked to customers and their position is to have flexible
validation
> policies. As an example, some says: if we want to take purposely the risk
of
> not testing ARLs, it is our choice. The validation policy should not
mandate
> to test ARLs, but if for some validation policies it is adequate to do so,
> it should be possible to do so.
>
> > It become a matter of mutual agreement between the client and
> > server what the OID represents.
>
> Not necessarilly. Since the OID is not in the arc of the server, it may be
> defined by anyone. If that definition is separately accessible both to the
> client and to the server then it can be supported by the server and the
> client may refer to it. In such a case there is no need for a mutual
agreement.
>
> > An SCVP server must either comply with any request or return an error
>
> True.
>
>  > so I don't see the validation policy OID
> > needs any special treatment beyond want SCVP already defines.
>
> I don't see the relationship between the true statement above and the
> conclusion.
>
> As already stated on this list, SCVP stands for "Simple", otherwise we
will
> have to drop the "S", and then we would have "CVP". :-|
>
> Denis
>
> > Trevor



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C9BFge091427; Wed, 12 May 2004 02:11:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4C9BF67091426; Wed, 12 May 2004 02:11:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C9BEa6091340 for <[e-mail]>; Wed, 12 May 2004 02:11:14 -0700 (PDT) (envelope-from [e-mail])
Received: from ms8.chttl.com.tw (ms8 [10.144.2.118]) by fw.chttl.com.tw (8.12.10/8.12.10) with ESMTP id i4C9AdGG026609; Wed, 12 May 2004 17:10:40 +0800
Received: (from root@localhost) by ms8.chttl.com.tw (8.12.10/8.12.10) id i4C9Ad6X024382; Wed, 12 May 2004 17:10:39 +0800
Received: from wcwang ([10.144.133.79]) by ms8.chttl.com.tw (8.12.10/8.12.10) with SMTP id i4C9AcZl024279; Wed, 12 May 2004 17:10:38 +0800
Message-ID: <003801c43800$fc933dc0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Santoni Adriano" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Steve Hanna" <[e-mail]>
References: <[e-mail]>
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in encodingRDNs
Date: Wed, 12 May 2004 17:10:35 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Yes, you can do a lot of cool things in theory.
>
> The cruel truth is that your name encoding roll-over certs (e.g.
> CA1-CA1-p-u-cert) is not self issued according to RFC 3280.

That is why I said that the definition of self-issued certificates in RFC
3280 (or maybe its definition in the X.509 standard itself) should
be revised or be clarified in son-of-3280 (or in an amendment of
the X.509 standard as well).

>
> RFC 3280 section 6.1:
>    A certificate is self-issued if the DNs that appear in the subject
>    and issuer fields are identical and are not empty.
>
> RFC 3280 section 4.1.2.4:
>       (a)  attribute values encoded in different types (e.g.,
>       PrintableString and BMPString) MAY be assumed to represent
>       different strings;

Remenber that RFC 3280 section 4.1.2.4 also said:

   Implementations of this profile are permitted to use the comparison
   algorithm defined in the X.500 series.

In that respect, you can not said that name rollover certificates are not
self-issued.

>
> So in current implementations of RFC 3280, many valid certificates will
> fail after introduction of name rollover certs in the chain, because
> path validation will not treat them as self-issued.

I admit that most CURRENT implementations of RFC 3280 path
validation will fail to treat name rollover certificates as self-issued, but
it does not mean that we should not recommend FUTURE revisions
of those implementations and new implementations to treat them as
self-issued.

>
> Further, the name constraint problem persists, adds to this but also
> exist regardless of this problem.
>
> RFC 3280 section 4.2.1.11
>    When applying restrictions of the form directoryName, an
>    implementation MUST compare DN attributes.  At a minimum,
>    implementations MUST perform the DN comparison rules specified in
>    Section 4.1.2.4.

That is why I said RFC 3280 path validation algorithm should also be
revised.

>
> Fixing next version of RFC 3280 to include better name matching rules is
> a good thing but far from enough to take care of real problems with
> current infrastructure.

Fixing next version of RFC 3280 does not magically take care of real
problems with current infrastructure, but it encourge current infrastructure
to migrate to solve the problems.

>
> We have to try to keep in mind what we make all this hassle for!!
>
> This is NOT about whether we should use UTF-8 or not to accommodate
> complex character sets!! This is about what we are prepared to do to
> make sure NOTHING is encoded as PrintableString WHEN PrintableString is
> sufficient.
>
> This old transition rule was created in RFC 2459 before the modern path
> validation algorithm was invented and before self-issued certificates
> was a special case.

That does not mean that name rollover certificates can not solve the
mixed name-encoding  problem.

>
> Let's just admit that we overlooked this issue when we created RFC 3280
> and reshaped path validation. It was an understandable human error,
> which lead to a defect.

Yes, RFC 3280 indeed overlooked this issue. That is why it should be
revised.

>
> So let's then also admit that REQUIRING UTF-8 when printableString is
> sufficient, is not a very good idea when all practical matters are
> measured, and that it never should have made it to more than a
> RECOMMENDATION.

Isn't it the IETF policy to encourge all new implementations to migrate
to support UTF-8? The philosophy is that if one encoding is sufficient to
cover universal characters, why should we recommend two?

>
> Whatever we say here, this is a requirement that many implementers will
> have to ignore for a many years to come.

Conformance to any IETF RFC is all voluntary. No one can enfoce any
implementer for that if the implementer chooses to ignore the requirement
or recommendation of any IETF RFC. RFC 3280 might not have the
power to enforce all implementation to migrate to UTF-8 encoding.
However, as an IETF RFC, it definitely has a great effect. At least, I
see more and more applications can correctly handle certificates with
named in UTF-8 encoding. Therefore, I prefer to see son-of-3280 to
continue requiring conformant implementations to migrate to UTF-8
encoding.

Wen-Cheng Wang



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C8dZHo079650; Wed, 12 May 2004 01:39:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4C8dZpi079649; Wed, 12 May 2004 01:39:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ntexch03.office.corp.sia.it (clients.sia.it [193.203.230.22] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C8dTnH079589 for <[e-mail]>; Wed, 12 May 2004 01:39:34 -0700 (PDT) (envelope-from [e-mail])
Received: by ntexch03.office.corp.sia.it with Internet Mail Service (5.5.2657.72) id <JZ9SPN4A>; Wed, 12 May 2004 10:39:23 +0200
Message-ID: <[e-mail]>
From: Santoni Adriano <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>
Cc: [e-mail], [e-mail], Steve Hanna <[e-mail]>, Wen-Cheng Wang <[e-mail]>, Stephen Kent <[e-mail]>
Subject: R: R: I: R: RFC3280: doubt on the use of UTF8String in encoding R DNs
Date: Wed, 12 May 2004 10:39:27 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4C8dYnH079642
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thank you for this additional contribution.

"So let's then also admit that REQUIRING UTF-8 when printableString is
sufficient, is not a very good idea when all practical matters are measured,
..."

This is exactly the point, IMHO. UTF-8 is a clever encoding, probably the
best when we CAs have to put names like "Papadopulos" or "Wen-Cheng Wang"
into a certificate in its original and "true" character set.

"...and that it never should have made it to more than a RECOMMENDATION."

This sounds very sensible. I buy it!

Adriano

-----Messaggio originale-----
Da: Stefan Santesson [mailto:[e-mail]] 
Inviato: martedì 11 maggio 2004 15.33
A: Wen-Cheng Wang; Stephen Kent; Santoni Adriano
Cc: [e-mail]; [e-mail]; Steve Hanna
Oggetto: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encoding
RDNs


Yes, you can do a lot of cool things in theory.

The cruel truth is that your name encoding roll-over certs (e.g.
CA1-CA1-p-u-cert) is not self issued according to RFC 3280.

RFC 3280 section 6.1:
   A certificate is self-issued if the DNs that appear in the subject
   and issuer fields are identical and are not empty. 

RFC 3280 section 4.1.2.4:
      (a)  attribute values encoded in different types (e.g.,
      PrintableString and BMPString) MAY be assumed to represent
      different strings;

So in current implementations of RFC 3280, many valid certificates will fail
after introduction of name rollover certs in the chain, because path
validation will not treat them as self-issued.

Further, the name constraint problem persists, adds to this but also exist
regardless of this problem.

RFC 3280 section 4.2.1.11
   When applying restrictions of the form directoryName, an
   implementation MUST compare DN attributes.  At a minimum,
   implementations MUST perform the DN comparison rules specified in
   Section 4.1.2.4.

Fixing next version of RFC 3280 to include better name matching rules is a
good thing but far from enough to take care of real problems with current
infrastructure.

We have to try to keep in mind what we make all this hassle for!!

This is NOT about whether we should use UTF-8 or not to accommodate complex
character sets!! This is about what we are prepared to do to make sure
NOTHING is encoded as PrintableString WHEN PrintableString is sufficient.

This old transition rule was created in RFC 2459 before the modern path
validation algorithm was invented and before self-issued certificates was a
special case.

Let's just admit that we overlooked this issue when we created RFC 3280 and
reshaped path validation. It was an understandable human error, which lead
to a defect.

So let's then also admit that REQUIRING UTF-8 when printableString is
sufficient, is not a very good idea when all practical matters are measured,
and that it never should have made it to more than a RECOMMENDATION.

Whatever we say here, this is a requirement that many implementers will have
to ignore for a many years to come.


Stefan Santesson
Program Manager, Windows Security
> -----Original Message-----
> From: Wen-Cheng Wang [mailto:[e-mail]]
> Sent: den 7 maj 2004 04:29
> To: Stefan Santesson; Stephen Kent; Santoni Adriano
> Cc: [e-mail]; [e-mail]; Steve Hanna
> Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> I do'nt see why name rollover certificates can not solve the mixed 
> encoding problem if the definition of a self-issued certificate and 
> the path validation algorithm in RFC 3280 is revised?
> 
> Let me use an example to explain this.
> 
> Suppose the original certificate chain is:
> 
>    Trust-Anchor ...... CA1-CA2-p-p-cert CA2-EE1-p-p-cert
> 
> where "p-p" means "issuer name in PrintableString" and "subject name 
> in PrintableString".
> 
> Suppose CA2 take the name rollover, it will issue the following two 
> self-issued certificates:
>          CA2-CA2-p-u-cert
>              (i.e., issuer name in PrintableString,
>                      subject name in UTF8String)
>          CA2-CA2-u-p-cert
>              (i.e., issuer name in UTF8String,
>                      subject name in PrintableString)
> 
> Suppose CA1 also take the name rollover, it will issue
> the following two self-issued certificates:
>          CA1-CA1-p-u-cert
>              (i.e., issuer name in PrintableString,
>                      subject name in UTF8String)
>          CA1-CA1-u-p-cert
>              (i.e., issuer name in UTF8String,
>                      subject name in PrintableString)
> 
> Suppose CA2 start to issue EE certificate with UTF8String encoding, 
> and it issues the following EE certificate:
>          CA2-EE2-u-u-cert
> 
> Then,
> EE1 can still be reached by the original certificate chain:
> 
> Trust-Anchor ...... CA1-CA2-p-p-cert CA2-EE1-p-p-cert
> 
> EE1 can also be reached by the following new certificate chain:
> 
> Trust-Anchor ...... CA1-CA1-u-p-cert CA1-CA2-p-p-cert
>          CA2-EE1-p-p-cert
> (Assume there is another CA issues a cross-certificate to CA1 in 
> UTF8String encoding.)
> 
> EE2 can be reached by the following new certificate chain:
> 
> Trust-Anchor ...... CA1-CA2-p-p-cert CA2-CA2-p-u-cert
>          CA2-EE2-u-u-cert
> 
> One day, if CA1 renews the cross-certificate to CA2 and adopts 
> UTF8String encoding in the new cross-certificate, it will issue the 
> following cross-certificate:
>          CA1-CA2-u-u-cert
> 
> Then,
> EE1 can also be reached by the following new certificate chain:
> 
> Trust-Anchor ...... CA1-CA1-p-u-cert CA1-CA2-u-u-cert
>          CA2-CA2-u-p-cert CA2-EE1-p-p-cert
> 
> EE2 can also be reached by the following new certificate chain:
> 
> Trust-Anchor ...... CA1-CA2-u-u-cert CA2-EE2-u-u-cert
> 
> As you can see, in theory you can always find at least one certificate 
> chain to EE1 (i.e., old cert with PrintableString) or EE2 (i.e., new
cert
> with UTF8String). However, as I said before, we should discuss how to 
> amend RFC 3280 to support such certificate chaining.
> 
> Wen-Cheng Wang
> 
> ----- Original Message -----
> From: "Stefan Santesson" <[e-mail]>
> To: "Wen-Cheng Wang" <[e-mail]>; "Stephen Kent"
<[e-mail]>;
> "Santoni Adriano" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> Sent: Thursday, May 06, 2004 9:32 PM
> Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> 
> >
> > Name rollover certificates only takes care of CA name changes. It 
> > doesn't solve the problem if subject names have mixed encoding in
the
> > forest of user certificates, while the CAs names are intact.
> >
> > Neither does it solve when the constraint is placed above the CA 
> > rollover.
> >
> > Finally, CA name rollover will most likely bust path validation
using
> > other constraining mechanisms because they may just not be
recognized as
> > self issued due to different name encoding.
> >
> > Stefan Santesson
> > Program Manager, Windows Security
> >


*******************Internet Email Confidentiality Footer******************* 
Qualsiasi utilizzo non autorizzato del presente messaggio nonche' dei suoi
allegati e' vietato e potrebbe costituire reato. Se lei ha ricevuto
erroneamente il presente messaggio, Le saremmo grati se, via e-mail, ce ne
comunicasse la ricezione e provvedesse alla distruzione del messaggio stesso
e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente
messaggio nonche' nei suoi eventuali allegati devono essere attribuite
esclusivamente al mittente e non possono essere considerate come trasmesse o
autorizzate da SIA S.p.A.; le medesime dichiarazioni non impegnano SIA
S.p.A. nei confronti del destinatario o di terzi. 
SIA S.p.A. non si assume alcuna responsabilita' per eventuali
intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited
and could constitute an offence. If you are not the intended addressee
please advise immediately the sender by using the reply facility in your
e-mail software and destroy the message and its attachments. The statements
and opinions expressed in this e-mail message are those of the author of the
message and do not necessarily represent those of SIA. Besides, The contents
of this message shall be understood as neither given nor endorsed by SIA
S.p.A.. 
SIA S.p.A. does not accept liability for corruption, interception or
amendment, if any, or the consequences thereof. 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C7P64w052768; Wed, 12 May 2004 00:25:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4C7P6rQ052767; Wed, 12 May 2004 00:25:06 -0700 (PDT)
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.9) with ESMTP id i4C7P4Zb052684 for <[e-mail]>; Wed, 12 May 2004 00:25:05 -0700 (PDT) (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 JAA59042; Wed, 12 May 2004 09:34:21 +0200
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 JAA11982; Wed, 12 May 2004 09:23:42 +0200
Message-ID: <[e-mail]>
Date: Wed, 12 May 2004 09:25:28 +0200
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: Trevor Freeman <[e-mail]>
CC: [e-mail]
Subject: Re: SCVP & validation policies
References: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4C7P5Zb052762
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor,

> You also have to understand enough so that the administrative 
> configuration of the client is generating the right kind of request. 
 > > SCVP client is ?only following orders? in many instances and has from a The SCVP client is “only following orders” in many instances and has
 > from a perspective no idea if it is the right kind of request, only if it
 > is well formed to the rules it has been given. Both the administrator of
> the client and the administrator of the server has to understand in much 
> grater detail what the given policy is. Once you abstract though the 
> OID, you are placing a greater burden on the OOB admin to admin process.

The client does not have to "understand" what the validation given policy is.

The client only needs to know that, for a given application a given OID for 
the validation policy is needed. He does not need to have a clue of the 
details of the validation policy which may remain fully opaque to him.

This means that any validation specific parameter must *not* be part of the 
standard request.

Denis


> Trevor
> 
>  
> 
> ------------------------------------------------------------------------
> 
> From: James Jing [mailto:[e-mail]]
> Sent: Tuesday, May 11, 2004 5:09 PM
> To: Trevor Freeman; [e-mail]
> Subject: RE: SCVP & validation policies
> 
>  
> 
> Agree that the client needs to have all the data in order to build the 
> request. However, I think ?understand? is too strong a requirement. The 
> client may not need to ?understand? the data, some of which may be 
> factors affecting the server only. Perhaps I am too pedantic about the 
> word ?understand?.
> 
>  
> 
> Back to indirection, if ?understanding? is not a requirement, then the 
> client need not to be aware that an OID is an indirection to a set of 
> policies.
> 
>  
> 
> James
> 
>  
> 
> ------------------------------------------------------------------------
> 
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Wednesday, 12 May 2004 9:49 AM
> To: James Jing; [e-mail]
> Subject: RE: SCVP & validation policies
> 
>  
> 
> The client has to understand what is required to build a request i.e.
> What data does it need to supply to the server. It does not need to be
> aware of the factors which effect the server.
> Trevor
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of James Jing
> Sent: Tuesday, May 11, 2004 4:01 PM
> To: [e-mail]
> Subject: RE: SCVP & validation policies
> 
>  
> 
> I think policy OIDs should remain abstract, or at least can be abstract.
> That is that there is no requirement for the client software to
> understand the parameters.
> 
> I am more thinking of using SCVP to validate a certificate in the
> context of a transaction, where the policy OID in SCVP might be used to
> identify such a context to the server.
> 
> For example, a certificate validation request is carried out with regard
> to the acceptability of the holder's creditworthiness in the context of
> a credit-based transaction. In this case, the policy OID could be used
> to indicate the class of assuarances that the CA's CSP provides for,
> resulting in the server selecting a subset of acceptable trust anchors.
> 
> James
> 
>  
> 
> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Friday, 7 May 2004 6:28 AM
> To: Trevor Freeman
> Cc: [e-mail]
> Subject: RE: SCVP & validation policies
> 
>  
> 
> At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
>>Hi Steve,
>>If you want to have a shorthand notation for a validation policy, given
> 
>>we have a finite set of parameters, the I don't see the value of
>>indirection via an OID. Using a hash of the set of inputs provides a
>>way of expressing the same thing without introducing ambiguity of does
>>both parties have a common understating of that this means. At some
>>point someone has to define the policy in terms of the 3280 input
> parameters.
>>That definition is just as applicable and consumable by the client as a
> 
>>server therefore what did we gain from the shorthand notation? It would
> 
>>be pretty trivial to define some XML which would allow that set of
>>validation parameters to be imported by any SCVP entity.
>>Trevor
> 
> Trevor,
> 
> It is not indirection via an OID, it is identification via an OID.
> Clients never have to be aware of the parameters if we use an OID, and
> simplification of clients is one of the goals of SCVP. So I cannot agree
> with your comment that clients have to be able to consume these
> parameters.
> 
> Given that as a basis, it seems that we are debating whether to use OIDs
> or to create some other form of identifier via hashing parameters. I
> don't see the latter as attractive, since it requires additional
> specification of the canonicalization and encoding of the parameters to
> ensure consistency in hash computation between client and server.
> 
> Steve
> 
>  
> 
> This e-mail, and any attachments hereto, is intended only for use by the 
> named addressee(s) and may contain legally privileged and/or 
> confidential information.  If you are not the intended recipient, you 
> are hereby notified that any dissemination, distribution or copying of 
> this e-mail, and any attachments hereto, is strictly prohibited.  If you 
> have received this transmission in error, please notify me immediately 
> and permanently delete the original and all copies and printouts of this 
> e-mail.
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C15SuY077623; Tue, 11 May 2004 18:05:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4C15SsG077622; Tue, 11 May 2004 18:05:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C15R2C077604 for <[e-mail]>; Tue, 11 May 2004 18:05:27 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 11 May 2004 18:05:28 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 May 2004 18:05:27 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 May 2004 18:05:18 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-a742e905-c6e4-4c09-8d0f-2771da0c3bda"
Subject: RE: SCVP & validation policies
Date: Tue, 11 May 2004 18:05:29 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
thread-index: AcQ3snpRSDr1tTG9S92N6pIM1cyrMQAAQFaAAAI2WyA=
From: "Trevor Freeman" <[e-mail]>
To: "James Jing" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 12 May 2004 01:05:18.0270 (UTC) FILETIME=[30F18DE0:01C437BD]
Sender: [e-mail]
Precedence: 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.

------=_NextPartTM-000-a742e905-c6e4-4c09-8d0f-2771da0c3bda
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C437BD.33B87440"

------_=_NextPart_001_01C437BD.33B87440
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

You also have to understand enough so that the administrative
configuration of the client is generating the right kind of request. The
SCVP client is "only following orders" in many instances and has from a
perspective no idea if it is the right kind of request, only if it is
well formed to the rules it has been given. Both the administrator of
the client and the administrator of the server has to understand in much
grater detail what the given policy is. Once you abstract though the
OID, you are placing a greater burden on the OOB admin to admin process.

Trevor

=20

________________________________

From: James Jing [mailto:[e-mail]]=20
Sent: Tuesday, May 11, 2004 5:09 PM
To: Trevor Freeman; [e-mail]
Subject: RE: SCVP & validation policies

=20

Agree that the client needs to have all the data in order to build the
request. However, I think "understand" is too strong a requirement. The
client may not need to "understand" the data, some of which may be
factors affecting the server only. Perhaps I am too pedantic about the
word "understand".

=20

Back to indirection, if "understanding" is not a requirement, then the
client need not to be aware that an OID is an indirection to a set of
policies.

=20

James

=20

________________________________

From: Trevor Freeman [mailto:[e-mail]]=20
Sent: Wednesday, 12 May 2004 9:49 AM
To: James Jing; [e-mail]
Subject: RE: SCVP & validation policies

=20

The client has to understand what is required to build a request i.e.=20
What data does it need to supply to the server. It does not need to be=20
aware of the factors which effect the server.=20
Trevor=20

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

On Behalf Of James Jing=20
Sent: Tuesday, May 11, 2004 4:01 PM=20
To: [e-mail]=20
Subject: RE: SCVP & validation policies=20

=20

I think policy OIDs should remain abstract, or at least can be abstract.

That is that there is no requirement for the client software to=20
understand the parameters.=20

I am more thinking of using SCVP to validate a certificate in the=20
context of a transaction, where the policy OID in SCVP might be used to=20
identify such a context to the server.=20

For example, a certificate validation request is carried out with regard

to the acceptability of the holder's creditworthiness in the context of=20
a credit-based transaction. In this case, the policy OID could be used=20
to indicate the class of assuarances that the CA's CSP provides for,=20
resulting in the server selecting a subset of acceptable trust anchors.=20

James=20

=20

-----Original Message-----=20
From: Stephen Kent [mailto:[e-mail]]=20
Sent: Friday, 7 May 2004 6:28 AM=20
To: Trevor Freeman=20
Cc: [e-mail]=20
Subject: RE: SCVP & validation policies=20

=20

At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:=20
>Hi Steve,=20
>If you want to have a shorthand notation for a validation policy, given


>we have a finite set of parameters, the I don't see the value of=20
>indirection via an OID. Using a hash of the set of inputs provides a=20
>way of expressing the same thing without introducing ambiguity of does=20
>both parties have a common understating of that this means. At some=20
>point someone has to define the policy in terms of the 3280 input=20
parameters.=20
>That definition is just as applicable and consumable by the client as a


>server therefore what did we gain from the shorthand notation? It would


>be pretty trivial to define some XML which would allow that set of=20
>validation parameters to be imported by any SCVP entity.=20
>Trevor=20

Trevor,=20

It is not indirection via an OID, it is identification via an OID.=20
Clients never have to be aware of the parameters if we use an OID, and=20
simplification of clients is one of the goals of SCVP. So I cannot agree

with your comment that clients have to be able to consume these=20
parameters.=20

Given that as a basis, it seems that we are debating whether to use OIDs

or to create some other form of identifier via hashing parameters. I=20
don't see the latter as attractive, since it requires additional=20
specification of the canonicalization and encoding of the parameters to=20
ensure consistency in hash computation between client and server.=20

Steve=20

=20

This e-mail, and any attachments hereto, is intended only for use by the
named addressee(s) and may contain legally privileged and/or
confidential information.  If you are not the intended recipient, you
are hereby notified that any dissemination, distribution or copying of
this e-mail, and any attachments hereto, is strictly prohibited.  If you
have received this transmission in error, please notify me immediately
and permanently delete the original and all copies and printouts of this
e-mail.


------_=_NextPart_001_01C437BD.33B87440
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<title>RE: SCVP &amp; validation policies</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: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:blue;
	text-decoration:underline;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p
	{margin-right:0pt;
	margin-left:0pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle19
	{font-family:Arial;
	color:navy;}
span.EmailStyle20
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<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'>You also have to understand enough =
so that
the administrative configuration of the client is generating the right =
kind of
request. The SCVP client is &#8220;only following orders&#8221; in many =
instances
and has from a perspective no idea if it is the right kind of request, =
only if
it is well formed to the rules it has been given. Both the administrator =
of the
client and the administrator of the server has to understand in much =
grater
detail what the given policy is. Once you abstract though the OID, you =
are
placing a greater burden on the OOB admin to admin =
process.</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</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;</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=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'> James =
Jing
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Tuesday, May 11, =
2004 5:09
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Trevor Freeman; =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: SCVP &amp; =
validation
policies</span></font></p>

</div>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-AU
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Agree that the =
client
needs to have all the data in order to build the request. However, I =
think
&#8220;understand&#8221; is too strong a requirement. The client may not =
need
to &#8220;understand&#8221; the data, some of which may be factors =
affecting
the server only. Perhaps I am too pedantic about the word
&#8220;understand&#8221;.</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-AU
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>Back to =
indirection, if
&#8220;understanding&#8221; is not a requirement, then the client need =
not to
be aware that an OID is an indirection to a set of =
policies.</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-AU
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>James</span></fon=
t></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-AU
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>&nbsp;</span></fo=
nt></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=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'> =
Trevor Freeman [mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, 12 May =
2004 9:49
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> James Jing; =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: SCVP &amp; =
validation
policies</span></font></p>

</div>

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

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>The
client has to understand what is required to build a request =
i.e.</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>What =
data does it
need to supply to the server. It does not need to be</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>aware of the
factors which effect the server.</span></font><span lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Trevor</span></font><span
lang=3DEN-AU> </span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>-----Original
Message-----</span></font><span lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>From: [e-mail]
[<a =
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>On =
Behalf Of
James Jing</span></font><span lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Sent: Tuesday,
May 11, 2004 4:01 PM</span></font><span lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>To: =
[e-mail]</span></font><span lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Subject: RE: SCVP
&amp; validation policies</span></font><span lang=3DEN-AU> </span></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>I
think policy OIDs should remain abstract, or at least can be =
abstract.</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>That =
is that
there is no requirement for the client software to</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>understand the
parameters.</span></font><span lang=3DEN-AU> </span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>I
am more thinking of using SCVP to validate a certificate in =
the</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>context of a
transaction, where the policy OID in SCVP might be used =
to</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>identify such a
context to the server. </span></font></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>For
example, a certificate validation request is carried out with =
regard</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>to =
the
acceptability of the holder's creditworthiness in the context =
of</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>a =
credit-based
transaction. In this case, the policy OID could be =
used</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>to =
indicate the
class of assuarances that the CA's CSP provides for,</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>resulting in the
server selecting a subset of acceptable trust =
anchors.</span></font><span
lang=3DEN-AU> </span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>James</span></font><span
lang=3DEN-AU> </span></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>-----Original
Message-----</span></font><span lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>From: Stephen
Kent [<a href=3D"mailto:[e-mail]">mailto:[e-mail]</a>] =
</span></font><span
lang=3DEN-AU><br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Sent: Friday, 7
May 2004 6:28 AM</span></font><span lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>To: =
Trevor Freeman</span></font><span lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>Cc: =
[e-mail]</span></font><span lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Subject: RE: SCVP
&amp; validation policies</span></font><span lang=3DEN-AU> </span></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>At
12:10 PM -0700 5/6/04, Trevor Freeman wrote:</span></font><span =
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;Hi Steve,</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;If you want
to have a shorthand notation for a validation policy, =
given</span></font><span
lang=3DEN-AU> </span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;we
have a finite set of parameters, the I don't see the value of =
</span></font><span
lang=3DEN-AU><br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;indirection
via an OID. Using a hash of the set of inputs provides a =
</span></font><span
lang=3DEN-AU><br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;way of
expressing the same thing without introducing ambiguity of does =
</span></font><span
lang=3DEN-AU><br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;both parties
have a common understating of that this means. At some =
</span></font><span
lang=3DEN-AU><br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;point someone
has to define the policy in terms of the 3280 input</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>parameters.</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;That
definition is just as applicable and consumable by the client as =
a</span></font><span
lang=3DEN-AU> </span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;server
therefore what did we gain from the shorthand notation? It =
would</span></font><span
lang=3DEN-AU> </span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;be
pretty trivial to define some XML which would allow that set of =
</span></font><span
lang=3DEN-AU><br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;validation
parameters to be imported by any SCVP entity.</span></font><span =
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>&gt;Trevor</span></font><span lang=3DEN-AU> =
</span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Trevor</span></font><font
size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>,</span></font><span
lang=3DEN-AU> </span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>It
is not indirection via an OID, it is identification via an OID. =
</span></font><span
lang=3DEN-AU><br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Clients never
have to be aware of the parameters if we use an OID, =
and</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>simplification of
clients is one of the goals of SCVP. So I cannot =
agree</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>with =
your comment
that clients have to be able to consume these</span></font><span =
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>parameters.</span></font><span
lang=3DEN-AU> </span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Given
that as a basis, it seems that we are debating whether to use =
OIDs</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU style=3D'font-size:10.0pt'>or =
to create some
other form of identifier via hashing parameters. I</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>don't see the
latter as attractive, since it requires additional</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>specification of
the canonicalization and encoding of the parameters =
to</span></font><span
lang=3DEN-AU> <br>
</span><font size=3D2><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>ensure consistency
in hash computation between client and server.</span></font><span =
lang=3DEN-AU> </span></p>

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>Steve</span></font><span
lang=3DEN-AU> </span></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span lang=3DEN-AU =
style=3D'font-size:10.0pt'>This
e-mail, and any attachments hereto, is intended only for use by the =
named
addressee(s) and may contain legally privileged and/or confidential
information.&nbsp; If you are not the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this e-mail, =
and
any attachments hereto, is strictly prohibited.&nbsp; If you have =
received this
transmission in error, please notify me immediately and permanently =
delete the
original and all copies and printouts of this e-mail.</span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C437BD.33B87440--

------=_NextPartTM-000-a742e905-c6e4-4c09-8d0f-2771da0c3bda--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C09M4a074528; Tue, 11 May 2004 17:09:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4C09MRU074527; Tue, 11 May 2004 17:09:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from figg.securenet.com.au (ns2.isecure.com.au [202.125.4.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4C09LAq074482 for <[e-mail]>; Tue, 11 May 2004 17:09:21 -0700 (PDT) (envelope-from [e-mail])
Received: from iron.securenet.com.au (iron.isecure.com.au [202.125.4.94] (may be forged)) by figg.securenet.com.au (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4C096i3002804; Wed, 12 May 2004 10:09:06 +1000
Received: (from uucp@localhost) by iron.securenet.com.au (8.12.6/8.12.6) id i4C096WK000025; Wed, 12 May 2004 10:09:06 +1000 (EST)
Received: from nodnsquery(10.11.3.10) by iron.securenet.com.au via csmap (V6.0) id srcAAAt4aada; Wed, 12 May 04 10:09:06 +1000
Received: from cbrms01.securenet.com.au (localhost [127.0.0.1]) by gibbons.securenet.com.au (8.12.3/8.12.3/Debian-7woody) with ESMTP id i4C0956Y028363; Wed, 12 May 2004 10:09:05 +1000
Received: from AMALTHEA.securenet.com.au ([192.168.100.30]) by cbrms01.securenet.com.au with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 May 2004 10:04:35 +1000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C437B5.4BDF985F"
Subject: RE: SCVP & validation policies
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Wed, 12 May 2004 10:08:47 +1000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
Thread-Index: AcQ3snpRSDr1tTG9S92N6pIM1cyrMQAAQFaA
From: "James Jing" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 12 May 2004 00:04:35.0327 (UTC) FILETIME=[B59490F0:01C437B4]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C437B5.4BDF985F
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

Agree that the client needs to have all the data in order to build the
request. However, I think "understand" is too strong a requirement. The
client may not need to "understand" the data, some of which may be
factors affecting the server only. Perhaps I am too pedantic about the
word "understand".

=20

Back to indirection, if "understanding" is not a requirement, then the
client need not to be aware that an OID is an indirection to a set of
policies.

=20

James

=20

  _____ =20

From: Trevor Freeman [mailto:[e-mail]]=20
Sent: Wednesday, 12 May 2004 9:49 AM
To: James Jing; [e-mail]
Subject: RE: SCVP & validation policies

=20

The client has to understand what is required to build a request i.e.=20
What data does it need to supply to the server. It does not need to be=20
aware of the factors which effect the server.=20
Trevor=20

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

On Behalf Of James Jing=20
Sent: Tuesday, May 11, 2004 4:01 PM=20
To: [e-mail]=20
Subject: RE: SCVP & validation policies=20

=20

I think policy OIDs should remain abstract, or at least can be abstract.

That is that there is no requirement for the client software to=20
understand the parameters.=20

I am more thinking of using SCVP to validate a certificate in the=20
context of a transaction, where the policy OID in SCVP might be used to=20
identify such a context to the server.=20

For example, a certificate validation request is carried out with regard

to the acceptability of the holder's creditworthiness in the context of=20
a credit-based transaction. In this case, the policy OID could be used=20
to indicate the class of assuarances that the CA's CSP provides for,=20
resulting in the server selecting a subset of acceptable trust anchors.=20

James=20

=20

-----Original Message-----=20
From: Stephen Kent [mailto:[e-mail]]=20
Sent: Friday, 7 May 2004 6:28 AM=20
To: Trevor Freeman=20
Cc: [e-mail]=20
Subject: RE: SCVP & validation policies=20

=20

At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:=20
>Hi Steve,=20
>If you want to have a shorthand notation for a validation policy, given


>we have a finite set of parameters, the I don't see the value of=20
>indirection via an OID. Using a hash of the set of inputs provides a=20
>way of expressing the same thing without introducing ambiguity of does=20
>both parties have a common understating of that this means. At some=20
>point someone has to define the policy in terms of the 3280 input=20
parameters.=20
>That definition is just as applicable and consumable by the client as a


>server therefore what did we gain from the shorthand notation? It would


>be pretty trivial to define some XML which would allow that set of=20
>validation parameters to be imported by any SCVP entity.=20
>Trevor=20

Trevor,=20

It is not indirection via an OID, it is identification via an OID.=20
Clients never have to be aware of the parameters if we use an OID, and=20
simplification of clients is one of the goals of SCVP. So I cannot agree

with your comment that clients have to be able to consume these=20
parameters.=20

Given that as a basis, it seems that we are debating whether to use OIDs

or to create some other form of identifier via hashing parameters. I=20
don't see the latter as attractive, since it requires additional=20
specification of the canonicalization and encoding of the parameters to=20
ensure consistency in hash computation between client and server.=20

Steve=20

=20

This e-mail, and any attachments hereto, is intended only for use by the
named addressee(s) and may contain legally privileged and/or
confidential information.  If you are not the intended recipient, you
are hereby notified that any dissemination, distribution or copying of
this e-mail, and any attachments hereto, is strictly prohibited.  If you
have received this transmission in error, please notify me immediately
and permanently delete the original and all copies and printouts of this
e-mail.


------_=_NextPart_001_01C437B5.4BDF985F
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>RE: SCVP &amp; validation policies</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:blue;
	text-decoration:underline;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=3DEN-AU link=3Dblue vlink=3Dblue>

<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'>Agree that the client needs to have =
all
the data in order to build the request. However, I think =
&#8220;understand&#8221;
is too strong a requirement. The client may not need to =
&#8220;understand&#8221;
the data, some of which may be factors affecting the server only. =
Perhaps I am
too pedantic about the word =
&#8220;understand&#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'>Back to indirection, if =
&#8220;understanding&#8221;
is not a requirement, then the client need not to be aware that an OID =
is an
indirection to a set of policies.<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'>James<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 lang=3DEN-US 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 lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</spa=
n></font></b><font
size=3D2 face=3DTahoma><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:Tahoma'>
Trevor Freeman [mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, 12 May =
2004 9:49
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> James Jing; =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: SCVP &amp; =
validation
policies</span></font><span lang=3DEN-US><o:p></o:p></span></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><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>The
client has to understand what is required to build a request =
i.e.</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>What data does it need =
to supply to
the server. It does not need to be</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>aware of the factors =
which effect
the server.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Trevor</span></font> =
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>-----Original
Message-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>From: =
[e-mail]
[<a =
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>On Behalf Of James =
Jing</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Sent: Tuesday, May 11, =
2004 4:01 PM</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>To: =
[e-mail]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Subject: RE: SCVP &amp; =
validation
policies</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>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>I think
policy OIDs should remain abstract, or at least can be =
abstract.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>That is that there is no
requirement for the client software to</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>understand the =
parameters.</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>I am more
thinking of using SCVP to validate a certificate in the</span></font> =
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>context of a =
transaction, where the
policy OID in SCVP might be used to</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>identify such a context =
to the
server. </span></font><o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>For
example, a certificate validation request is carried out with =
regard</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>to the acceptability of =
the
holder's creditworthiness in the context of</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>a credit-based =
transaction. In this
case, the policy OID could be used</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>to indicate the class of
assuarances that the CA's CSP provides for,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>resulting in the server =
selecting a
subset of acceptable trust anchors.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>James</span></font>
<o:p></o:p></p>

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

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>-----Original
Message-----</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>From: Stephen Kent [<a
href=3D"mailto:[e-mail]">mailto:[e-mail]</a>] </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>Sent: Friday, 7 May 2004 =
6:28 AM</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>To: Trevor =
Freeman</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>Cc: =
[e-mail]</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>Subject: RE: SCVP &amp; =
validation
policies</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>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>At 12:10
PM -0700 5/6/04, Trevor Freeman wrote:</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;Hi =
Steve,</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;If you want to have =
a shorthand
notation for a validation policy, given</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;we
have a finite set of parameters, the I don't see the value of =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;indirection via an =
OID. Using a
hash of the set of inputs provides a </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;way of expressing =
the same
thing without introducing ambiguity of does </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;both parties have a =
common
understating of that this means. At some </span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;point someone has to =
define the
policy in terms of the 3280 input</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>parameters.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;That definition is =
just as
applicable and consumable by the client as a</span></font> =
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;server
therefore what did we gain from the shorthand notation? It =
would</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>&gt;be
pretty trivial to define some XML which would allow that set of =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;validation =
parameters to be
imported by any SCVP entity.</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>&gt;Trevor</span></font> =
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Trevor,</span></font>
<o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>It is not
indirection via an OID, it is identification via an OID. =
</span></font><br>
<font size=3D2><span style=3D'font-size:10.0pt'>Clients never have to be =
aware of
the parameters if we use an OID, and</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>simplification of =
clients is one of
the goals of SCVP. So I cannot agree</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>with your comment that =
clients have
to be able to consume these</span></font> <br>
<font size=3D2><span =
style=3D'font-size:10.0pt'>parameters.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Given
that as a basis, it seems that we are debating whether to use =
OIDs</span></font>
<br>
<font size=3D2><span style=3D'font-size:10.0pt'>or to create some other =
form of
identifier via hashing parameters. I</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>don't see the latter as =
attractive,
since it requires additional</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>specification of the
canonicalization and encoding of the parameters to</span></font> <br>
<font size=3D2><span style=3D'font-size:10.0pt'>ensure consistency in =
hash
computation between client and server.</span></font> <o:p></o:p></p>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>Steve</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>

<p><font size=3D2 face=3D"Times New Roman"><span =
style=3D'font-size:10.0pt'>This
e-mail, and any attachments hereto, is intended only for use by the =
named
addressee(s) and may contain legally privileged and/or confidential
information.&nbsp; If you are not the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this e-mail, =
and
any attachments hereto, is strictly prohibited.&nbsp; If you have =
received this
transmission in error, please notify me immediately and permanently =
delete the
original and all copies and printouts of this =
e-mail.</span></font><o:p></o:p></p>

</div>

</body>

</html>

------_=_NextPart_001_01C437B5.4BDF985F--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BNmZBb073269; Tue, 11 May 2004 16:48:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BNmZGc073268; Tue, 11 May 2004 16:48:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BNmYau073261 for <[e-mail]>; Tue, 11 May 2004 16:48:34 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 11 May 2004 16:48:37 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 May 2004 16:48:37 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 May 2004 16:48:19 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP & validation policies
Date: Tue, 11 May 2004 16:48:36 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
thread-index: AcQzsteWPNjAnYrQQkSngFTDmZEpQQD94Z8QAAHsxEA=
From: "Trevor Freeman" <[e-mail]>
To: "James Jing" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 11 May 2004 23:48:19.0729 (UTC) FILETIME=[70142010:01C437B2]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4BNmZau073263
Sender: [e-mail]
Precedence: 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 client has to understand what is required to build a request i.e.
What data does it need to supply to the server. It does not need to be
aware of the factors which effect the server.
Trevor

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of James Jing
Sent: Tuesday, May 11, 2004 4:01 PM
To: [e-mail]
Subject: RE: SCVP & validation policies


I think policy OIDs should remain abstract, or at least can be abstract.
That is that there is no requirement for the client software to
understand the parameters.

I am more thinking of using SCVP to validate a certificate in the
context of a transaction, where the policy OID in SCVP might be used to
identify such a context to the server. 

For example, a certificate validation request is carried out with regard
to the acceptability of the holder's creditworthiness in the context of
a credit-based transaction. In this case, the policy OID could be used
to indicate the class of assuarances that the CA's CSP provides for,
resulting in the server selecting a subset of acceptable trust anchors.

James



-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Friday, 7 May 2004 6:28 AM
To: Trevor Freeman
Cc: [e-mail]
Subject: RE: SCVP & validation policies


At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
>Hi Steve,
>If you want to have a shorthand notation for a validation policy, given

>we have a finite set of parameters, the I don't see the value of 
>indirection via an OID. Using a hash of the set of inputs provides a 
>way of expressing the same thing without introducing ambiguity of does 
>both parties have a common understating of that this means. At some 
>point someone has to define the policy in terms of the 3280 input
parameters.
>That definition is just as applicable and consumable by the client as a

>server therefore what did we gain from the shorthand notation? It would

>be pretty trivial to define some XML which would allow that set of 
>validation parameters to be imported by any SCVP entity.
>Trevor

Trevor,

It is not indirection via an OID, it is identification via an OID. 
Clients never have to be aware of the parameters if we use an OID, and
simplification of clients is one of the goals of SCVP. So I cannot agree
with your comment that clients have to be able to consume these
parameters.

Given that as a basis, it seems that we are debating whether to use OIDs
or to create some other form of identifier via hashing parameters. I
don't see the latter as attractive, since it requires additional
specification of the canonicalization and encoding of the parameters to
ensure consistency in hash computation between client and server.

Steve






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BN8DDl070660; Tue, 11 May 2004 16:08:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BN8Dig070659; Tue, 11 May 2004 16:08:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BN8D1P070653 for <[e-mail]>; Tue, 11 May 2004 16:08:13 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 11 May 2004 16:08:18 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 May 2004 16:08:18 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 May 2004 16:08:00 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP & validation policies
Date: Tue, 11 May 2004 16:08:17 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
thread-index: AcQ3qmiKcqXx3k4PSf2S0mo5HXNBWAAAWM1w
From: "Trevor Freeman" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 11 May 2004 23:08:00.0526 (UTC) FILETIME=[CE1F0AE0:01C437AC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4BN8D1P070654
Sender: [e-mail]
Precedence: 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 Florian,
A server is under no obligation to process the request. 
If you have a badly configured client, then it will be fixed. If the
request is accurate and the server is misconfigured, then it will be
fixed. This is not about the sanctity of either sides policy but simple
client server request/response semantics. I do not expect the server to
second guess what the problem is and return potentially misleading data.
If the request conflicts with the server locally configured policy,
return the error, if not process the request
Trevor

-----Original Message-----
From: Florian Oelmaier [mailto:[e-mail]] 
Sent: Tuesday, May 11, 2004 3:51 PM
To: Trevor Freeman; 'Stephen Kent'
Cc: 'Denis Pinkas'; [e-mail]
Subject: RE: SCVP & validation policies


> Hi Florian,
> The server either carries out the request or returns an 
> error. We cannot have the server picking and choosing items 
> out of the request since it becomes impossible for the client 
> to determining what happened. That is totally consistent with 
> the needs of the enterprise. Trevor

I see it the other way round: The client sends a request and the server
chooses HOW to answer the request. All responsibilities of the
validation process are determined by the policy of the SCVP server.

We cannot have the configuration of a client set by a user in the
enterprise interfering with centrally managed trust settings. If we
allow this, the idea of central managed trust and validation settings is
well and truly dead.

In my eyes it is the clients task to specify its Validation-Policy OID
and perhaps ist "wishlist" - and then to trust the servers response.
>From my perspective this was (is?) one of the most charming features of
SCVP.

Best regards,

Florian 

> 
> -----Original Message-----
> From: Florian Oelmaier [mailto:[e-mail]] 
> Sent: Tuesday, May 11, 2004 12:13 PM
> To: Trevor Freeman; 'Stephen Kent'
> Cc: 'Denis Pinkas'; [e-mail]
> Subject: RE: SCVP & validation policies
> 
> > Hi Steve,
> > I am not excluding that. A SCVP client may choose to
> > implement the more al a carte or a combination of al-a-carte 
> > plus predefined policy. In every validation policy it may 
> > agree m parameters. That leaves n parameters to be specified 
> > per request. Since we don't know which of the m parameters 
> > will be fixed in any given deployment  we must support any 
> > combination so we must support the full rage of parameter 
> > currently defined. In many situations the overhead of 
> > agreeing these pre-caned selection is an administrative 
> > burden such as a departmental server wanting to implement 
> > special needs. Equally in may corporate deployments there is 
> > no choice with many of the values so you can default every to 
> > whoever is good for the server, so again rendering app 
> > specific policy of no value. Trevor
> 
> Hello Trevor,
> 
> I feel that a solution allowing a client to specify values 
> that the server MUST use will not only harm the usability of 
> SCVP in enterprise environments but also make 
> interoperability between different software vendors on the 
> client side with different servers a lot more difficult.
> 
> If we specify a set of parameters that the server MAY use - I 
> am fine. But please dont allow the client to specify any 
> parameters a server MUST use.
> 
> Best regards,
> 
> Florian Oelmaier
> 
> 
> > 
> > 
> > 
> > -----Original Message-----
> > From: Stephen Kent [mailto:[e-mail]]
> > Sent: Tuesday, May 11, 2004 9:28 AM
> > To: Trevor Freeman
> > Cc: Denis Pinkas; [e-mail]
> > Subject: RE: SCVP & validation policies
> > 
> > At 9:16 AM -0700 5/11/04, Trevor Freeman wrote:
> > >Hi Dennis,
> > >The OID is optional for the client to use. Servers don't have to
> > support
> > >this. It become a matter of mutual agreement between the client and
> > >server what the OID represents. An SCVP server must either 
> > comply with
> > >any request or return an error so I don't see the validation
> > policy OID
> > >needs any special treatment beyond want SCVP already 
> defines. Trevor
> > 
> > Trevor,
> > 
> > I have to agree with Denis here. This is completely backwards from
> > what I recall we defined as the requirements in his RFC a 
> while ago. 
> > OIDs were sufficient to identify a policy, the parameters for which 
> > were managed via a separate protocol. It seems a lot easier to 
> > configure a client with an OID per app, than to configure a set of 
> > parameters for each app.
> > 
> > Steve
> > 
> > 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BN1WP3070386; Tue, 11 May 2004 16:01:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BN1WnF070385; Tue, 11 May 2004 16:01:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from figg.securenet.com.au (ns2.isecure.com.au [202.125.4.72]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BN1UZY070372 for <[e-mail]>; Tue, 11 May 2004 16:01:31 -0700 (PDT) (envelope-from [e-mail])
Received: from iron.securenet.com.au (iron.isecure.com.au [202.125.4.94] (may be forged)) by figg.securenet.com.au (8.12.3/8.12.3/Debian-6.6) with ESMTP id i4BN1Mi3004396 for <[e-mail]>; Wed, 12 May 2004 09:01:22 +1000
Received: (from uucp@localhost) by iron.securenet.com.au (8.12.6/8.12.6) id i4BN1Mkx028323 for <[e-mail]>; Wed, 12 May 2004 09:01:22 +1000 (EST)
Received: from nodnsquery(10.11.3.10) by iron.securenet.com.au via csmap (V6.0) id srcAAApMaiu3; Wed, 12 May 04 09:01:21 +1000
Received: from cbrms01.securenet.com.au (localhost [127.0.0.1]) by gibbons.securenet.com.au (8.12.3/8.12.3/Debian-7woody) with ESMTP id i4BN1Kev006569 for <[e-mail]>; Wed, 12 May 2004 09:01:21 +1000
Received: from AMALTHEA.securenet.com.au ([192.168.100.30]) by cbrms01.securenet.com.au with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 May 2004 08:56:50 +1000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Subject: RE: SCVP & validation policies
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Wed, 12 May 2004 09:01:03 +1000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
Thread-Index: AcQzsteWPNjAnYrQQkSngFTDmZEpQQD94Z8Q
From: "James Jing" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 11 May 2004 22:56:50.0796 (UTC) FILETIME=[3EEE5AC0:01C437AB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4BN1VZY070380
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think policy OIDs should remain abstract, or at least can be abstract.
That is that there is no requirement for the client software to
understand the parameters.

I am more thinking of using SCVP to validate a certificate in the
context of a transaction, where the policy OID in SCVP might be used to
identify such a context to the server. 

For example, a certificate validation request is carried out with regard
to the acceptability of the holder's creditworthiness in the context of
a credit-based transaction. In this case, the policy OID could be used
to indicate the class of assuarances that the CA's CSP provides for,
resulting in the server selecting a subset of acceptable trust anchors.

James



-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Friday, 7 May 2004 6:28 AM
To: Trevor Freeman
Cc: [e-mail]
Subject: RE: SCVP & validation policies


At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
>Hi Steve,
>If you want to have a shorthand notation for a validation policy, given

>we have a finite set of parameters, the I don't see the value of 
>indirection via an OID. Using a hash of the set of inputs provides a 
>way of expressing the same thing without introducing ambiguity of does 
>both parties have a common understating of that this means. At some 
>point someone has to define the policy in terms of the 3280 input
parameters.
>That definition is just as applicable and consumable by the client as a

>server therefore what did we gain from the shorthand notation? It would

>be pretty trivial to define some XML which would allow that set of 
>validation parameters to be imported by any SCVP entity.
>Trevor

Trevor,

It is not indirection via an OID, it is identification via an OID. 
Clients never have to be aware of the parameters if we use an OID, and
simplification of clients is one of the goals of SCVP. So I cannot agree
with your comment that clients have to be able to consume these
parameters.

Given that as a basis, it seems that we are debating whether to use OIDs
or to create some other form of identifier via hashing parameters. I
don't see the latter as attractive, since it requires additional
specification of the canonicalization and encoding of the parameters to
ensure consistency in hash computation between client and server.

Steve





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BMopQb069857; Tue, 11 May 2004 15:50:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BMopLc069856; Tue, 11 May 2004 15:50:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-in.m-online.net (mail-in.m-online.net [62.245.150.237]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BMonr1069850 for <[e-mail]>; Tue, 11 May 2004 15:50:50 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.m-online.net (svr14.m-online.net [192.168.3.144]) by svr8.m-online.net (Postfix) with ESMTP id F3EAC4C9B2; Wed, 12 May 2004 00:50:51 +0200 (CEST)
Received: from hagen (ppp-82-135-9-66.mnet-online.de [82.135.9.66]) by mail.m-online.net (Postfix) with ESMTP id B454FA7F48; Wed, 12 May 2004 00:50:51 +0200 (CEST)
From: "Florian Oelmaier" <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>
Cc: "'Denis Pinkas'" <[e-mail]>, <[e-mail]>
Subject: RE: SCVP & validation policies
Date: Wed, 12 May 2004 00:50:49 +0200
Organization: SyTrust
Message-ID: <012601c437aa$67cd43d0$4228a8c0@hagen>
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.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
In-reply-to: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi Florian,
> The server either carries out the request or returns an 
> error. We cannot have the server picking and choosing items 
> out of the request since it becomes impossible for the client 
> to determining what happened. That is totally consistent with 
> the needs of the enterprise. Trevor

I see it the other way round: The client sends a request and the server
chooses HOW to answer the request. All responsibilities of the
validation process are determined by the policy of the SCVP server.

We cannot have the configuration of a client set by a user in the
enterprise interfering with centrally managed trust settings. If we
allow this, the idea of central managed trust and validation settings is
well and truly dead.

In my eyes it is the clients task to specify its Validation-Policy OID
and perhaps ist "wishlist" - and then to trust the servers response.
>From my perspective this was (is?) one of the most charming features of
SCVP.

Best regards,

Florian 

> 
> -----Original Message-----
> From: Florian Oelmaier [mailto:[e-mail]] 
> Sent: Tuesday, May 11, 2004 12:13 PM
> To: Trevor Freeman; 'Stephen Kent'
> Cc: 'Denis Pinkas'; [e-mail]
> Subject: RE: SCVP & validation policies
> 
> > Hi Steve,
> > I am not excluding that. A SCVP client may choose to
> > implement the more al a carte or a combination of al-a-carte 
> > plus predefined policy. In every validation policy it may 
> > agree m parameters. That leaves n parameters to be specified 
> > per request. Since we don't know which of the m parameters 
> > will be fixed in any given deployment  we must support any 
> > combination so we must support the full rage of parameter 
> > currently defined. In many situations the overhead of 
> > agreeing these pre-caned selection is an administrative 
> > burden such as a departmental server wanting to implement 
> > special needs. Equally in may corporate deployments there is 
> > no choice with many of the values so you can default every to 
> > whoever is good for the server, so again rendering app 
> > specific policy of no value. Trevor
> 
> Hello Trevor,
> 
> I feel that a solution allowing a client to specify values 
> that the server MUST use will not only harm the usability of 
> SCVP in enterprise environments but also make 
> interoperability between different software vendors on the 
> client side with different servers a lot more difficult.
> 
> If we specify a set of parameters that the server MAY use - I 
> am fine. But please dont allow the client to specify any 
> parameters a server MUST use.
> 
> Best regards,
> 
> Florian Oelmaier
> 
> 
> > 
> > 
> > 
> > -----Original Message-----
> > From: Stephen Kent [mailto:[e-mail]]
> > Sent: Tuesday, May 11, 2004 9:28 AM
> > To: Trevor Freeman
> > Cc: Denis Pinkas; [e-mail]
> > Subject: RE: SCVP & validation policies
> > 
> > At 9:16 AM -0700 5/11/04, Trevor Freeman wrote:
> > >Hi Dennis,
> > >The OID is optional for the client to use. Servers don't have to
> > support
> > >this. It become a matter of mutual agreement between the client and
> > >server what the OID represents. An SCVP server must either 
> > comply with
> > >any request or return an error so I don't see the validation
> > policy OID
> > >needs any special treatment beyond want SCVP already 
> defines. Trevor
> > 
> > Trevor,
> > 
> > I have to agree with Denis here. This is completely backwards from
> > what I recall we defined as the requirements in his RFC a 
> while ago. 
> > OIDs were sufficient to identify a policy, the parameters for which 
> > were managed via a separate protocol. It seems a lot easier to 
> > configure a client with an OID per app, than to configure a set of 
> > parameters for each app.
> > 
> > Steve
> > 
> > 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BKO2HJ058878; Tue, 11 May 2004 13:24:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BKO2n0058877; Tue, 11 May 2004 13:24:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BKO1q0058871 for <[e-mail]>; Tue, 11 May 2004 13:24:01 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 11 May 2004 13:24:06 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 May 2004 13:24:06 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 May 2004 13:24:06 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP & validation policies
Date: Tue, 11 May 2004 13:24:04 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
thread-index: AcQ3i/FXdTOSaoY6The390PFDj/vBgACU28w
From: "Trevor Freeman" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 11 May 2004 20:24:06.0002 (UTC) FILETIME=[E849C520:01C43795]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4BKO2q0058872
Sender: [e-mail]
Precedence: 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 Florian,
The server either carries out the request or returns an error. We cannot
have the server picking and choosing items out of the request since it
becomes impossible for the client to determining what happened. That is
totally consistent with the needs of the enterprise.
Trevor

-----Original Message-----
From: Florian Oelmaier [mailto:[e-mail]] 
Sent: Tuesday, May 11, 2004 12:13 PM
To: Trevor Freeman; 'Stephen Kent'
Cc: 'Denis Pinkas'; [e-mail]
Subject: RE: SCVP & validation policies

> Hi Steve,
> I am not excluding that. A SCVP client may choose to 
> implement the more al a carte or a combination of al-a-carte 
> plus predefined policy. In every validation policy it may 
> agree m parameters. That leaves n parameters to be specified 
> per request. Since we don't know which of the m parameters 
> will be fixed in any given deployment  we must support any 
> combination so we must support the full rage of parameter 
> currently defined. In many situations the overhead of 
> agreeing these pre-caned selection is an administrative 
> burden such as a departmental server wanting to implement 
> special needs. Equally in may corporate deployments there is 
> no choice with many of the values so you can default every to 
> whoever is good for the server, so again rendering app 
> specific policy of no value. Trevor

Hello Trevor,

I feel that a solution allowing a client to specify values that the
server MUST use will not only harm the usability of SCVP in enterprise
environments but also make interoperability between different software
vendors on the client side with different servers a lot more difficult.

If we specify a set of parameters that the server MAY use - I am fine.
But please dont allow the client to specify any parameters a server MUST
use.

Best regards,

Florian Oelmaier


> 
> 
> 
> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]] 
> Sent: Tuesday, May 11, 2004 9:28 AM
> To: Trevor Freeman
> Cc: Denis Pinkas; [e-mail]
> Subject: RE: SCVP & validation policies
> 
> At 9:16 AM -0700 5/11/04, Trevor Freeman wrote:
> >Hi Dennis,
> >The OID is optional for the client to use. Servers don't have to
> support
> >this. It become a matter of mutual agreement between the client and 
> >server what the OID represents. An SCVP server must either 
> comply with 
> >any request or return an error so I don't see the validation 
> policy OID 
> >needs any special treatment beyond want SCVP already defines. Trevor
> 
> Trevor,
> 
> I have to agree with Denis here. This is completely backwards from 
> what I recall we defined as the requirements in his RFC a while ago. 
> OIDs were sufficient to identify a policy, the parameters for which 
> were managed via a separate protocol. It seems a lot easier to 
> configure a client with an OID per app, than to configure a set of 
> parameters for each app.
> 
> Steve
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BJCjYl051813; Tue, 11 May 2004 12:12:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BJCjMK051812; Tue, 11 May 2004 12:12:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-in.m-online.net (mail-in.m-online.net [62.245.150.237]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BJChPB051802 for <[e-mail]>; Tue, 11 May 2004 12:12:44 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.m-online.net (svr14.m-online.net [192.168.3.144]) by svr8.m-online.net (Postfix) with ESMTP id CA3154CE75; Tue, 11 May 2004 21:12:44 +0200 (CEST)
Received: from hagen (ppp-82-135-9-66.mnet-online.de [82.135.9.66]) by mail.m-online.net (Postfix) with ESMTP id 85685A7FA8; Tue, 11 May 2004 21:12:44 +0200 (CEST)
From: "Florian Oelmaier" <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>
Cc: "'Denis Pinkas'" <[e-mail]>, <[e-mail]>
Subject: RE: SCVP & validation policies
Date: Tue, 11 May 2004 21:12:41 +0200
Organization: SyTrust
Message-ID: <00e701c4378b$eea83780$4228a8c0@hagen>
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.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
In-reply-to: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi Steve,
> I am not excluding that. A SCVP client may choose to 
> implement the more al a carte or a combination of al-a-carte 
> plus predefined policy. In every validation policy it may 
> agree m parameters. That leaves n parameters to be specified 
> per request. Since we don't know which of the m parameters 
> will be fixed in any given deployment  we must support any 
> combination so we must support the full rage of parameter 
> currently defined. In many situations the overhead of 
> agreeing these pre-caned selection is an administrative 
> burden such as a departmental server wanting to implement 
> special needs. Equally in may corporate deployments there is 
> no choice with many of the values so you can default every to 
> whoever is good for the server, so again rendering app 
> specific policy of no value. Trevor

Hello Trevor,

I feel that a solution allowing a client to specify values that the
server MUST use will not only harm the usability of SCVP in enterprise
environments but also make interoperability between different software
vendors on the client side with different servers a lot more difficult.

If we specify a set of parameters that the server MAY use - I am fine.
But please dont allow the client to specify any parameters a server MUST
use.

Best regards,

Florian Oelmaier


> 
> 
> 
> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]] 
> Sent: Tuesday, May 11, 2004 9:28 AM
> To: Trevor Freeman
> Cc: Denis Pinkas; [e-mail]
> Subject: RE: SCVP & validation policies
> 
> At 9:16 AM -0700 5/11/04, Trevor Freeman wrote:
> >Hi Dennis,
> >The OID is optional for the client to use. Servers don't have to
> support
> >this. It become a matter of mutual agreement between the client and 
> >server what the OID represents. An SCVP server must either 
> comply with 
> >any request or return an error so I don't see the validation 
> policy OID 
> >needs any special treatment beyond want SCVP already defines. Trevor
> 
> Trevor,
> 
> I have to agree with Denis here. This is completely backwards from 
> what I recall we defined as the requirements in his RFC a while ago. 
> OIDs were sufficient to identify a policy, the parameters for which 
> were managed via a separate protocol. It seems a lot easier to 
> configure a client with an OID per app, than to configure a set of 
> parameters for each app.
> 
> Steve
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BHG8qI038267; Tue, 11 May 2004 10:16:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BHG8l0038266; Tue, 11 May 2004 10:16:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BHG67F038255 for <[e-mail]>; Tue, 11 May 2004 10:16:06 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 11 May 2004 10:16:09 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 May 2004 10:16:07 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 May 2004 10:16:09 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP & validation policies
Date: Tue, 11 May 2004 10:16:08 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
thread-index: AcQ3df6yT7wzvr3RR0GyuVCBAgYxbgABSRSQ
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 11 May 2004 17:16:09.0874 (UTC) FILETIME=[A7312F20:01C4377B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4BHG67F038256
Sender: [e-mail]
Precedence: 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,
I am not excluding he use of OIDs so your customers can do as they want
and pass whatever additional parameters they like per request. My
customer who find the additional layer of administration unnecessary,
can decide not to use them.
Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Tuesday, May 11, 2004 9:36 AM
To: Trevor Freeman
Cc: Stephen Kent; [e-mail]
Subject: Re: SCVP & validation policies

Trevor,

> Hi Dennis,
> The OID is optional for the client to use. Servers don't have to
support
> this. 

I disagree. The "RFC 3280 compliantbasic validation policy", i.e the one

which only includes basic path validation, with no extra and no
shortcuts, 
as defined by RFC 3280, will have an OID. Since this policy does not 
contains values such as root keys, this validation policy needs
additional 
parameters.

Intelligent clients may use this one and specify parameters.

Thin clients will simply refer to an OID which refers globally to a 
validation algorithm and its parameters.

I have talked to customers and their position is to have flexible
validation 
policies. As an example, some says: if we want to take purposely the
risk of 
not testing ARLs, it is our choice. The validation policy should not
mandate 
to test ARLs, but if for some validation policies it is adequate to do
so, 
it should be possible to do so.

> It become a matter of mutual agreement between the client and
> server what the OID represents. 

Not necessarilly. Since the OID is not in the arc of the server, it may
be 
defined by anyone. If that definition is separately accessible both to
the 
client and to the server then it can be supported by the server and the 
client may refer to it. In such a case there is no need for a mutual
agreement.

> An SCVP server must either comply with any request or return an error 

True.

 > so I don't see the validation policy OID
> needs any special treatment beyond want SCVP already defines.

I don't see the relationship between the true statement above and the 
conclusion.

As already stated on this list, SCVP stands for "Simple", otherwise we
will 
have to drop the "S", and then we would have "CVP". :-|

Denis

> Trevor
> 
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Tuesday, May 11, 2004 6:50 AM
> To: Trevor Freeman
> Cc: Stephen Kent; [e-mail]
> Subject: Re: SCVP & validation policies
> 
> Trevor,
> 
> 
>>Hi Steve,
>>It is management of the clients which is at question here. The client
>>has a series of input parameters all of which are opaque. The OID is a
>>management indirection to a set of parameters. The ambiguity arises
>>because the use of the OID assumes both the manager of the client and
>>the manager of the server have an accurate understanding of the OID.
>>
>>However give the volume of traffic on this point, I will add the
>>capacity to pass an optional OID in the request to the server to
>>identify a set of parameters in SCVP15.
> 
> 
> It is the other way around:
> 
> Given the volume of traffic on this point, the parameters should allow
> to 
> pass a *mandatory *OID in the request to identify a given validation
> policy, 
> while some specific validation policies may need an additional set of 
> parameters.
> 
> Denis
> 
> 
>>Trevor
>>
>>-----Original Message-----
>>From: Stephen Kent [mailto:[e-mail]] 
>>Sent: Thursday, May 06, 2004 1:28 PM
>>To: Trevor Freeman
>>Cc: [e-mail]
>>Subject: RE: SCVP & validation policies
>>
>>At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
>>
>>
>>>Hi Steve,
>>>If you want to have a shorthand notation for a validation policy,
>>
> given
> 
>>>we have a finite set of parameters, the I don't see the value of
>>>indirection via an OID. Using a hash of the set of inputs provides a
>>
>>way
>>
>>
>>>of expressing the same thing without introducing ambiguity of does
>>
> both
> 
>>>parties have a common understating of that this means. At some point
>>>someone has to define the policy in terms of the 3280 input
>>
> parameters.
> 
>>>That definition is just as applicable and consumable by the client as
>>
> a
> 
>>>server therefore what did we gain from the shorthand notation? It
>>
> would
> 
>>>be pretty trivial to define some XML which would allow that set of
>>>validation parameters to be imported by any SCVP entity.
>>>Trevor
>>
>>
>>Trevor,
>>
>>It is not indirection via an OID, it is identification via an OID. 
>>Clients never have to be aware of the parameters if we use an OID, 
>>and simplification of clients is one of the goals of SCVP. So I 
>>cannot agree with your comment that clients have to be able to 
>>consume these parameters.
>>
>>Given that as a basis, it seems that we are debating whether to use 
>>OIDs or to create some other form of identifier via hashing 
>>parameters. I don't see the latter as attractive, since it requires 
>>additional specification of the canonicalization and encoding of the 
>>parameters to ensure consistency in hash computation between client 
>>and server.
>>
>>Steve
>>
> 
> 
> 
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BH5TbU037032; Tue, 11 May 2004 10:05:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BH5Tv9037031; Tue, 11 May 2004 10:05:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BH5Ss1037024 for <[e-mail]>; Tue, 11 May 2004 10:05:28 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 11 May 2004 10:05:31 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 May 2004 10:05:29 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 May 2004 10:05:31 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP & validation policies
Date: Tue, 11 May 2004 10:05:29 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
thread-index: AcQ3dRq23zt6dFZjT1O/f2a7QmDGrgAATVJw
From: "Trevor Freeman" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 11 May 2004 17:05:31.0527 (UTC) FILETIME=[2AB52970:01C4377A]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4BH5Ss1037025
Sender: [e-mail]
Precedence: 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 am not excluding that. A SCVP client may choose to implement the more
al a carte or a combination of al-a-carte plus predefined policy. In
every validation policy it may agree m parameters. That leaves n
parameters to be specified per request. Since we don't know which of the
m parameters will be fixed in any given deployment  we must support any
combination so we must support the full rage of parameter currently
defined. In many situations the overhead of agreeing these pre-caned
selection is an administrative burden such as a departmental server
wanting to implement special needs. Equally in may corporate deployments
there is no choice with many of the values so you can default every to
whoever is good for the server, so again rendering app specific policy
of no value.
Trevor



-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Tuesday, May 11, 2004 9:28 AM
To: Trevor Freeman
Cc: Denis Pinkas; [e-mail]
Subject: RE: SCVP & validation policies

At 9:16 AM -0700 5/11/04, Trevor Freeman wrote:
>Hi Dennis,
>The OID is optional for the client to use. Servers don't have to
support
>this. It become a matter of mutual agreement between the client and
>server what the OID represents. An SCVP server must either comply with
>any request or return an error so I don't see the validation policy OID
>needs any special treatment beyond want SCVP already defines.
>Trevor

Trevor,

I have to agree with Denis here. This is completely backwards from 
what I recall we defined as the requirements in his RFC a while ago. 
OIDs were sufficient to identify a policy, the parameters for which 
were managed via a separate protocol. It seems a lot easier to 
configure a client with an OID per app, than to configure a set of 
parameters for each app.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BGZRwA033816; Tue, 11 May 2004 09:35:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BGZRJs033815; Tue, 11 May 2004 09:35:27 -0700 (PDT)
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.9) with ESMTP id i4BGZPKT033799 for <[e-mail]>; Tue, 11 May 2004 09:35:26 -0700 (PDT) (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 SAA33478; Tue, 11 May 2004 18:44:45 +0200
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 SAA08047; Tue, 11 May 2004 18:34:04 +0200
Message-ID: <[e-mail]>
Date: Tue, 11 May 2004 18:35:49 +0200
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: Trevor Freeman <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: SCVP & validation policies
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>

Trevor,

> Hi Dennis,
> The OID is optional for the client to use. Servers don't have to support
> this. 

I disagree. The "RFC 3280 compliantbasic validation policy", i.e the one 
which only includes basic path validation, with no extra and no shortcuts, 
as defined by RFC 3280, will have an OID. Since this policy does not 
contains values such as root keys, this validation policy needs additional 
parameters.

Intelligent clients may use this one and specify parameters.

Thin clients will simply refer to an OID which refers globally to a 
validation algorithm and its parameters.

I have talked to customers and their position is to have flexible validation 
policies. As an example, some says: if we want to take purposely the risk of 
not testing ARLs, it is our choice. The validation policy should not mandate 
to test ARLs, but if for some validation policies it is adequate to do so, 
it should be possible to do so.

> It become a matter of mutual agreement between the client and
> server what the OID represents. 

Not necessarilly. Since the OID is not in the arc of the server, it may be 
defined by anyone. If that definition is separately accessible both to the 
client and to the server then it can be supported by the server and the 
client may refer to it. In such a case there is no need for a mutual agreement.

> An SCVP server must either comply with any request or return an error 

True.

 > so I don't see the validation policy OID
> needs any special treatment beyond want SCVP already defines.

I don't see the relationship between the true statement above and the 
conclusion.

As already stated on this list, SCVP stands for "Simple", otherwise we will 
have to drop the "S", and then we would have "CVP". :-|

Denis

> Trevor
> 
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Tuesday, May 11, 2004 6:50 AM
> To: Trevor Freeman
> Cc: Stephen Kent; [e-mail]
> Subject: Re: SCVP & validation policies
> 
> Trevor,
> 
> 
>>Hi Steve,
>>It is management of the clients which is at question here. The client
>>has a series of input parameters all of which are opaque. The OID is a
>>management indirection to a set of parameters. The ambiguity arises
>>because the use of the OID assumes both the manager of the client and
>>the manager of the server have an accurate understanding of the OID.
>>
>>However give the volume of traffic on this point, I will add the
>>capacity to pass an optional OID in the request to the server to
>>identify a set of parameters in SCVP15.
> 
> 
> It is the other way around:
> 
> Given the volume of traffic on this point, the parameters should allow
> to 
> pass a *mandatory *OID in the request to identify a given validation
> policy, 
> while some specific validation policies may need an additional set of 
> parameters.
> 
> Denis
> 
> 
>>Trevor
>>
>>-----Original Message-----
>>From: Stephen Kent [mailto:[e-mail]] 
>>Sent: Thursday, May 06, 2004 1:28 PM
>>To: Trevor Freeman
>>Cc: [e-mail]
>>Subject: RE: SCVP & validation policies
>>
>>At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
>>
>>
>>>Hi Steve,
>>>If you want to have a shorthand notation for a validation policy,
>>
> given
> 
>>>we have a finite set of parameters, the I don't see the value of
>>>indirection via an OID. Using a hash of the set of inputs provides a
>>
>>way
>>
>>
>>>of expressing the same thing without introducing ambiguity of does
>>
> both
> 
>>>parties have a common understating of that this means. At some point
>>>someone has to define the policy in terms of the 3280 input
>>
> parameters.
> 
>>>That definition is just as applicable and consumable by the client as
>>
> a
> 
>>>server therefore what did we gain from the shorthand notation? It
>>
> would
> 
>>>be pretty trivial to define some XML which would allow that set of
>>>validation parameters to be imported by any SCVP entity.
>>>Trevor
>>
>>
>>Trevor,
>>
>>It is not indirection via an OID, it is identification via an OID. 
>>Clients never have to be aware of the parameters if we use an OID, 
>>and simplification of clients is one of the goals of SCVP. So I 
>>cannot agree with your comment that clients have to be able to 
>>consume these parameters.
>>
>>Given that as a basis, it seems that we are debating whether to use 
>>OIDs or to create some other form of identifier via hashing 
>>parameters. I don't see the latter as attractive, since it requires 
>>additional specification of the canonicalization and encoding of the 
>>parameters to ensure consistency in hash computation between client 
>>and server.
>>
>>Steve
>>
> 
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BGTJMo032790; Tue, 11 May 2004 09:29:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BGTJPG032789; Tue, 11 May 2004 09:29:19 -0700 (PDT)
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.9) with ESMTP id i4BGTIG0032768 for <[e-mail]>; Tue, 11 May 2004 09:29:18 -0700 (PDT) (envelope-from [e-mail])
Received: from [10.81.115.79] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i4BGSS7X015450; Tue, 11 May 2004 12:28:29 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p06100505bcc6af22facd@[10.81.115.79]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Tue, 11 May 2004 12:28:12 -0400
To: "Trevor Freeman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: SCVP & validation policies
Cc: "Denis Pinkas" <[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 9:16 AM -0700 5/11/04, Trevor Freeman wrote:
>Hi Dennis,
>The OID is optional for the client to use. Servers don't have to support
>this. It become a matter of mutual agreement between the client and
>server what the OID represents. An SCVP server must either comply with
>any request or return an error so I don't see the validation policy OID
>needs any special treatment beyond want SCVP already defines.
>Trevor

Trevor,

I have to agree with Denis here. This is completely backwards from 
what I recall we defined as the requirements in his RFC a while ago. 
OIDs were sufficient to identify a policy, the parameters for which 
were managed via a separate protocol. It seems a lot easier to 
configure a client with an OID per app, than to configure a set of 
parameters for each app.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BGGuB0031373; Tue, 11 May 2004 09:16:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BGGuxm031372; Tue, 11 May 2004 09:16:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BGGt6D031357 for <[e-mail]>; Tue, 11 May 2004 09:16:55 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 11 May 2004 09:16:55 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 May 2004 09:16:52 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 May 2004 09:16:55 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP & validation policies
Date: Tue, 11 May 2004 09:16:54 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
thread-index: AcQ3XuoPr6ll6ZjYTR2cbNeMZNPIVAAE5iKw
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 11 May 2004 16:16:55.0239 (UTC) FILETIME=[6076ED70:01C43773]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4BGGt6D031367
Sender: [e-mail]
Precedence: 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 Dennis,
The OID is optional for the client to use. Servers don't have to support
this. It become a matter of mutual agreement between the client and
server what the OID represents. An SCVP server must either comply with
any request or return an error so I don't see the validation policy OID
needs any special treatment beyond want SCVP already defines.
Trevor


-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Tuesday, May 11, 2004 6:50 AM
To: Trevor Freeman
Cc: Stephen Kent; [e-mail]
Subject: Re: SCVP & validation policies

Trevor,

> Hi Steve,
> It is management of the clients which is at question here. The client
> has a series of input parameters all of which are opaque. The OID is a
> management indirection to a set of parameters. The ambiguity arises
> because the use of the OID assumes both the manager of the client and
> the manager of the server have an accurate understanding of the OID.
> 
> However give the volume of traffic on this point, I will add the
> capacity to pass an optional OID in the request to the server to
> identify a set of parameters in SCVP15.

It is the other way around:

Given the volume of traffic on this point, the parameters should allow
to 
pass a *mandatory *OID in the request to identify a given validation
policy, 
while some specific validation policies may need an additional set of 
parameters.

Denis

> Trevor
> 
> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]] 
> Sent: Thursday, May 06, 2004 1:28 PM
> To: Trevor Freeman
> Cc: [e-mail]
> Subject: RE: SCVP & validation policies
> 
> At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
> 
>>Hi Steve,
>>If you want to have a shorthand notation for a validation policy,
given
>>we have a finite set of parameters, the I don't see the value of
>>indirection via an OID. Using a hash of the set of inputs provides a
> 
> way
> 
>>of expressing the same thing without introducing ambiguity of does
both
>>parties have a common understating of that this means. At some point
>>someone has to define the policy in terms of the 3280 input
parameters.
>>That definition is just as applicable and consumable by the client as
a
>>server therefore what did we gain from the shorthand notation? It
would
>>be pretty trivial to define some XML which would allow that set of
>>validation parameters to be imported by any SCVP entity.
>>Trevor
> 
> 
> Trevor,
> 
> It is not indirection via an OID, it is identification via an OID. 
> Clients never have to be aware of the parameters if we use an OID, 
> and simplification of clients is one of the goals of SCVP. So I 
> cannot agree with your comment that clients have to be able to 
> consume these parameters.
> 
> Given that as a basis, it seems that we are debating whether to use 
> OIDs or to create some other form of identifier via hashing 
> parameters. I don't see the latter as attractive, since it requires 
> additional specification of the canonicalization and encoding of the 
> parameters to ensure consistency in hash computation between client 
> and server.
> 
> Steve
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BDo8uU014300; Tue, 11 May 2004 06:50:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BDo8uE014299; Tue, 11 May 2004 06:50:08 -0700 (PDT)
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.9) with ESMTP id i4BDo5qn014272 for <[e-mail]>; Tue, 11 May 2004 06:50:06 -0700 (PDT) (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 PAA28446; Tue, 11 May 2004 15:59:19 +0200
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 PAA06932; Tue, 11 May 2004 15:48:35 +0200
Message-ID: <[e-mail]>
Date: Tue, 11 May 2004 15:50:20 +0200
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: Trevor Freeman <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: SCVP & validation policies
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>

Trevor,

> Hi Steve,
> It is management of the clients which is at question here. The client
> has a series of input parameters all of which are opaque. The OID is a
> management indirection to a set of parameters. The ambiguity arises
> because the use of the OID assumes both the manager of the client and
> the manager of the server have an accurate understanding of the OID.
> 
> However give the volume of traffic on this point, I will add the
> capacity to pass an optional OID in the request to the server to
> identify a set of parameters in SCVP15.

It is the other way around:

Given the volume of traffic on this point, the parameters should allow to 
pass a *mandatory *OID in the request to identify a given validation policy, 
while some specific validation policies may need an additional set of 
parameters.

Denis

> Trevor
> 
> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]] 
> Sent: Thursday, May 06, 2004 1:28 PM
> To: Trevor Freeman
> Cc: [e-mail]
> Subject: RE: SCVP & validation policies
> 
> At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
> 
>>Hi Steve,
>>If you want to have a shorthand notation for a validation policy, given
>>we have a finite set of parameters, the I don't see the value of
>>indirection via an OID. Using a hash of the set of inputs provides a
> 
> way
> 
>>of expressing the same thing without introducing ambiguity of does both
>>parties have a common understating of that this means. At some point
>>someone has to define the policy in terms of the 3280 input parameters.
>>That definition is just as applicable and consumable by the client as a
>>server therefore what did we gain from the shorthand notation? It would
>>be pretty trivial to define some XML which would allow that set of
>>validation parameters to be imported by any SCVP entity.
>>Trevor
> 
> 
> Trevor,
> 
> It is not indirection via an OID, it is identification via an OID. 
> Clients never have to be aware of the parameters if we use an OID, 
> and simplification of clients is one of the goals of SCVP. So I 
> cannot agree with your comment that clients have to be able to 
> consume these parameters.
> 
> Given that as a basis, it seems that we are debating whether to use 
> OIDs or to create some other form of identifier via hashing 
> parameters. I don't see the latter as attractive, since it requires 
> additional specification of the canonicalization and encoding of the 
> parameters to ensure consistency in hash computation between client 
> and server.
> 
> Steve
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BDXoUt012710; Tue, 11 May 2004 06:33:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4BDXoM3012709; Tue, 11 May 2004 06:33:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4BDXbfg012680 for <[e-mail]>; Tue, 11 May 2004 06:33:37 -0700 (PDT) (envelope-from [e-mail])
Received: from eur-imc-02.europe.corp.microsoft.com ([65.53.196.43]) by mail-eur.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 May 2004 14:33:33 +0100
Received: from 65.53.196.43 by eur-imc-02.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 11 May 2004 14:33:33 +0100
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); Tue, 11 May 2004 14:33:33 +0100
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Date: Tue, 11 May 2004 14:33:19 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Thread-Index: AcQz2y6jQO2LneC5S9ivoM8JpftDDQDe1sSw
From: "Stefan Santesson" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Santoni Adriano" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Steve Hanna" <[e-mail]>
X-OriginalArrivalTime: 11 May 2004 13:33:33.0488 (UTC) FILETIME=[8E2A6B00:01C4375C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4BDXbfg012683
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yes, you can do a lot of cool things in theory.

The cruel truth is that your name encoding roll-over certs (e.g.
CA1-CA1-p-u-cert) is not self issued according to RFC 3280.

RFC 3280 section 6.1:
   A certificate is self-issued if the DNs that appear in the subject
   and issuer fields are identical and are not empty. 

RFC 3280 section 4.1.2.4:
      (a)  attribute values encoded in different types (e.g.,
      PrintableString and BMPString) MAY be assumed to represent
      different strings;

So in current implementations of RFC 3280, many valid certificates will
fail after introduction of name rollover certs in the chain, because
path validation will not treat them as self-issued.

Further, the name constraint problem persists, adds to this but also
exist regardless of this problem.

RFC 3280 section 4.2.1.11
   When applying restrictions of the form directoryName, an
   implementation MUST compare DN attributes.  At a minimum,
   implementations MUST perform the DN comparison rules specified in
   Section 4.1.2.4.

Fixing next version of RFC 3280 to include better name matching rules is
a good thing but far from enough to take care of real problems with
current infrastructure.

We have to try to keep in mind what we make all this hassle for!!

This is NOT about whether we should use UTF-8 or not to accommodate
complex character sets!! This is about what we are prepared to do to
make sure NOTHING is encoded as PrintableString WHEN PrintableString is
sufficient.

This old transition rule was created in RFC 2459 before the modern path
validation algorithm was invented and before self-issued certificates
was a special case.

Let's just admit that we overlooked this issue when we created RFC 3280
and reshaped path validation. It was an understandable human error,
which lead to a defect.

So let's then also admit that REQUIRING UTF-8 when printableString is
sufficient, is not a very good idea when all practical matters are
measured, and that it never should have made it to more than a
RECOMMENDATION.

Whatever we say here, this is a requirement that many implementers will
have to ignore for a many years to come.


Stefan Santesson
Program Manager, Windows Security
> -----Original Message-----
> From: Wen-Cheng Wang [mailto:[e-mail]]
> Sent: den 7 maj 2004 04:29
> To: Stefan Santesson; Stephen Kent; Santoni Adriano
> Cc: [e-mail]; [e-mail]; Steve Hanna
> Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> I do'nt see why name rollover certificates can not solve the
> mixed encoding problem if the definition of a self-issued
> certificate and the path validation algorithm in RFC 3280
> is revised?
> 
> Let me use an example to explain this.
> 
> Suppose the original certificate chain is:
> 
>    Trust-Anchor ...... CA1-CA2-p-p-cert CA2-EE1-p-p-cert
> 
> where "p-p" means "issuer name in PrintableString" and
> "subject name in PrintableString".
> 
> Suppose CA2 take the name rollover, it will issue the
> following two self-issued certificates:
>          CA2-CA2-p-u-cert
>              (i.e., issuer name in PrintableString,
>                      subject name in UTF8String)
>          CA2-CA2-u-p-cert
>              (i.e., issuer name in UTF8String,
>                      subject name in PrintableString)
> 
> Suppose CA1 also take the name rollover, it will issue
> the following two self-issued certificates:
>          CA1-CA1-p-u-cert
>              (i.e., issuer name in PrintableString,
>                      subject name in UTF8String)
>          CA1-CA1-u-p-cert
>              (i.e., issuer name in UTF8String,
>                      subject name in PrintableString)
> 
> Suppose CA2 start to issue EE certificate with UTF8String
> encoding, and it issues the following EE certificate:
>          CA2-EE2-u-u-cert
> 
> Then,
> EE1 can still be reached by the original certificate chain:
> 
> Trust-Anchor ...... CA1-CA2-p-p-cert CA2-EE1-p-p-cert
> 
> EE1 can also be reached by the following new certificate chain:
> 
> Trust-Anchor ...... CA1-CA1-u-p-cert CA1-CA2-p-p-cert
>          CA2-EE1-p-p-cert
> (Assume there is another CA issues a cross-certificate to CA1
> in UTF8String encoding.)
> 
> EE2 can be reached by the following new certificate chain:
> 
> Trust-Anchor ...... CA1-CA2-p-p-cert CA2-CA2-p-u-cert
>          CA2-EE2-u-u-cert
> 
> One day, if CA1 renews the cross-certificate to CA2 and
> adopts UTF8String encoding in the new cross-certificate, it
> will issue the following cross-certificate:
>          CA1-CA2-u-u-cert
> 
> Then,
> EE1 can also be reached by the following new certificate chain:
> 
> Trust-Anchor ...... CA1-CA1-p-u-cert CA1-CA2-u-u-cert
>          CA2-CA2-u-p-cert CA2-EE1-p-p-cert
> 
> EE2 can also be reached by the following new certificate chain:
> 
> Trust-Anchor ...... CA1-CA2-u-u-cert CA2-EE2-u-u-cert
> 
> As you can see, in theory you can always find at least one certificate
> chain to EE1 (i.e., old cert with PrintableString) or EE2 (i.e., new
cert
> with UTF8String). However, as I said before, we should discuss how
> to amend RFC 3280 to support such certificate chaining.
> 
> Wen-Cheng Wang
> 
> ----- Original Message -----
> From: "Stefan Santesson" <[e-mail]>
> To: "Wen-Cheng Wang" <[e-mail]>; "Stephen Kent"
<[e-mail]>;
> "Santoni Adriano" <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> Sent: Thursday, May 06, 2004 9:32 PM
> Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> 
> >
> > Name rollover certificates only takes care of CA name changes.
> > It doesn't solve the problem if subject names have mixed encoding in
the
> > forest of user certificates, while the CAs names are intact.
> >
> > Neither does it solve when the constraint is placed above the CA
> > rollover.
> >
> > Finally, CA name rollover will most likely bust path validation
using
> > other constraining mechanisms because they may just not be
recognized as
> > self issued due to different name encoding.
> >
> > Stefan Santesson
> > Program Manager, Windows Security
> >




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4B2GeLl039855; Mon, 10 May 2004 19:16:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4B2GeD4039854; Mon, 10 May 2004 19:16:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from webshielde250.example (ip-90-191-97-218.anlai.com [218.97.191.90]) by above.proper.com (8.12.11/8.12.9) with SMTP id i4B2GaNd039842 for <[e-mail]>; Mon, 10 May 2004 19:16:38 -0700 (PDT) (envelope-from [e-mail])
Received: from nodnsquery(10.8.1.50) by webshielde250.example via csmap  id 9cb10e8a_a2f1_11d8_8edb_0002b3bc9708_1367; Tue, 11 May 2004 10:19:21 +0800 (CST)
Date: Tue, 11 May 2004 10:21:08 +0800
To: "Ietf-pkix" <[e-mail]>
From: "Tytso" <[e-mail]>
Subject: Re: Incoming Message
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="--------cdtlxuujwzhbcaufkwty"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----------cdtlxuujwzhbcaufkwty
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

<html><body>
 

<br>
</body></html>

----------cdtlxuujwzhbcaufkwty
Content-Type: application/octet-stream; name="Information.vbs"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Information.vbs"
X-NAI-WebShielde250-mimepp: Attachment repaired



----------cdtlxuujwzhbcaufkwty--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4AHkmHB001450; Mon, 10 May 2004 10:46:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4AHkmXt001440; Mon, 10 May 2004 10:46:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4AHkjkt001395 for <[e-mail]>; Mon, 10 May 2004 10:46:45 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 10 May 2004 10:46:49 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 May 2004 10:46:46 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 10 May 2004 10:46:48 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP & validation policies
Date: Mon, 10 May 2004 10:46:47 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
thread-index: AcQ2slDP0jjVqWntQw25aiEjWd65ZQAA0suA
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 10 May 2004 17:46:48.0689 (UTC) FILETIME=[C4CC5610:01C436B6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4AHkjkt001399
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
I think saying the client must validate the ku itself is a big jump, so
allowing the client to pass lets them choose how must certificate
processing they perform.

For the requestor, I don't see any other processing than as binary blob
is necessary. Therefore if you have an octet string, the server just
does a binary companies on the data.

Trevor
-----Original Message-----
From: Peter Sylvester [mailto:[e-mail]] 
Sent: Monday, May 10, 2004 10:15 AM
To: [e-mail]; [e-mail]; Trevor Freeman
Cc: [e-mail]
Subject: RE: SCVP & validation policies

> Hi Peter,
> The ambiguity is a management level ambiguity. Using an OID provides
no
> guarantee that both parties have the common understanding of what the
> OID represents.

A dumb client may not have any understanding. If you start requiring
anything, where is the boundary to stop, i.e., why don't you require
that
all details of the policy must be known by the server. So far, I do not
see
any natural limit somewhere in the middle.  

> I think we can use the Cert sign bit in key usage so the is CA bit can
> be removed from SCVP15
Ok.

Don't we need a number indicating that a CA needs at least a path length
N?
In case you are validating a CA that signs a subca that signs an end
entity?

> 
> Testing EKU and KU are totally orthogonal. Consider SSL server
> certificate validation. A SSL server can have an RSA, DSA or DH public
> key.
I think I can follow the idea, but are KUs orthogonal?

The EKU is in your example "ssl server",the server knows
what kind of key is in the certificate, thus it can validate whether
the key usage is conformant. One can require that the client has to
set the corresponding KU, since the client has to perform some
corresponding operation. I haven't checked whether the potential
KUs are really orthogonal and correspond to the different key types.

For email EKU, there may be an issue to distinguish between
digital signature and/or non-repudiation. A client may just set
digital signature, but if the cert only contains non-rep, it
wouldn't match.

What would be the work of the server, if you don't specify a KU,
but an EKU of sslserver? Would a cert with just CRL signing
be allowed? 

> Given there are plenty of ways a client can generate a "unique" as
well
> as other behaviors like it can encode a DN in the octet sting if it
> likes I don't see a problem. Its down to the client to do what it
thinks

The problem in your proposal is that you cannot identify at all any way
the data
have been encoded, it can only be done by some external rule that you
have to
configure among the partners and the implementation need to be prepared
to have all kinds of decoding rules that allow a matching with
authenticated
entities.  

I see no advantadge at all to take any new identifier syntax, in fact, 
no syntax at all, we need identifiers that can be matched against 
identities, identities that we have otherwise available as
"generalname". 
flexibility of existing and new forms of identifiers is ensured by the 
totally open form of general name, in particular the othername form. 

> fit. The value is simply replayed by the server so it is treated a
> binary blob.

The value is not only simply replayed, it is use for loop detecting
at least in the SCVP text.   




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4AHEocm098007; Mon, 10 May 2004 10:14:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4AHEo8m098006; Mon, 10 May 2004 10:14:50 -0700 (PDT)
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.11/8.12.9) with ESMTP id i4AHEn6F098000 for <[e-mail]>; Mon, 10 May 2004 10:14:49 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i4AHEpN09592; Mon, 10 May 2004 19:14:51 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 10 May 2004 19:14:51 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i4AHEpl24848; Mon, 10 May 2004 19:14:51 +0200 (MEST)
Date: Mon, 10 May 2004 19:14:51 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: SCVP & validation policies
Cc: [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>

> Hi Peter,
> The ambiguity is a management level ambiguity. Using an OID provides no
> guarantee that both parties have the common understanding of what the
> OID represents.

A dumb client may not have any understanding. If you start requiring
anything, where is the boundary to stop, i.e., why don't you require that
all details of the policy must be known by the server. So far, I do not see
any natural limit somewhere in the middle.  

> I think we can use the Cert sign bit in key usage so the is CA bit can
> be removed from SCVP15
Ok.

Don't we need a number indicating that a CA needs at least a path length N?
In case you are validating a CA that signs a subca that signs an end entity?

> 
> Testing EKU and KU are totally orthogonal. Consider SSL server
> certificate validation. A SSL server can have an RSA, DSA or DH public
> key.
I think I can follow the idea, but are KUs orthogonal?

The EKU is in your example "ssl server",the server knows
what kind of key is in the certificate, thus it can validate whether
the key usage is conformant. One can require that the client has to
set the corresponding KU, since the client has to perform some
corresponding operation. I haven't checked whether the potential
KUs are really orthogonal and correspond to the different key types.

For email EKU, there may be an issue to distinguish between
digital signature and/or non-repudiation. A client may just set
digital signature, but if the cert only contains non-rep, it
wouldn't match.

What would be the work of the server, if you don't specify a KU,
but an EKU of sslserver? Would a cert with just CRL signing
be allowed? 

> Given there are plenty of ways a client can generate a "unique" as well
> as other behaviors like it can encode a DN in the octet sting if it
> likes I don't see a problem. Its down to the client to do what it thinks

The problem in your proposal is that you cannot identify at all any way the data
have been encoded, it can only be done by some external rule that you have to
configure among the partners and the implementation need to be prepared
to have all kinds of decoding rules that allow a matching with authenticated
entities.  

I see no advantadge at all to take any new identifier syntax, in fact, 
no syntax at all, we need identifiers that can be matched against 
identities, identities that we have otherwise available as "generalname". 
flexibility of existing and new forms of identifiers is ensured by the 
totally open form of general name, in particular the othername form. 

> fit. The value is simply replayed by the server so it is treated a
> binary blob.

The value is not only simply replayed, it is use for loop detecting
at least in the SCVP text.   



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4AGbewU095454; Mon, 10 May 2004 09:37:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4AGbeWU095453; Mon, 10 May 2004 09:37:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4AGbess095447 for <[e-mail]>; Mon, 10 May 2004 09:37:40 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 10 May 2004 09:37:42 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 May 2004 09:37:43 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 10 May 2004 09:37:42 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP & validation policies
Date: Mon, 10 May 2004 09:37:41 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
thread-index: AcQ2gbizulKv217ZTiyI2GB6WyXuIQAKQ+AA
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 10 May 2004 16:37:42.0456 (UTC) FILETIME=[1D736380:01C436AD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4AGbess095448
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Peter,
The ambiguity is a management level ambiguity. Using an OID provides no
guarantee that both parties have the common understanding of what the
OID represents.

I think we can use the Cert sign bit in key usage so the is CA bit can
be removed from SCVP15

Testing EKU and KU are totally orthogonal. Consider SSL server
certificate validation. A SSL server can have an RSA, DSA or DH public
key.

Given there are plenty of ways a client can generate a "unique" as well
as other behaviors like it can encode a DN in the octet sting if it
likes I don't see a problem. Its down to the client to do what it thinks
fit. The value is simply replayed by the server so it is treated a
binary blob.

Trevor

-----Original Message-----
From: Peter Sylvester [mailto:[e-mail]] 
Sent: Monday, May 10, 2004 4:27 AM
To: [e-mail]; Trevor Freeman
Cc: [e-mail]
Subject: RE: SCVP & validation policies


> 
> Hi Steve,
> If you want to have a shorthand notation for a validation policy,
given
> we have a finite set of parameters, the I don't see the value of
> indirection via an OID.

One often uses the term I am conformant to protocol XYZ or profile ABC
instead of repeating the finite number of the characters in the relevant
text.   

>                          Using a hash of the set of inputs provides a
way
> of expressing the same thing without introducing ambiguity of does
both
> parties have a common understating of that this means. At some point

'understating', I guess you mean 'understanding'. As I said, a dumb
client
has no understanding, so there is no ambiguity problem. 


> someone has to define the policy in terms of the 3280 input
parameters.
At the server end, at the place where the trust is managed. Dumb
clients don't need to be updated when the details change.

> That definition is just as applicable and consumable by the client as
a
> server therefore what did we gain from the shorthand notation? It
would
That is not the question. As far as I remember, we want a possibility
to have a dumb client and centralised policy management.

> be pretty trivial to define some XML which would allow that set of
> validation parameters to be imported by any SCVP entity.
Beware of those who use the word "trivial". By endcoding these
parameters using XER of the ASN.1 syntax, you have a tr..... ooups ...

Anyway, 

I still would like to know whether the isCa is a shorthand notation
for the explicit value of "keyUsage contains certSign", or whether
it is something else.

Do you agree that testing for a particular extendedKeyusage includes
testing for a conformant keyUsage.

I have not heard how you think to have some uniqueness of requester
values
in octet strings, and whether there is can be any other way than pure
hexadecimal (or equivalent) presentation of these values, and what
local matter to match these values with the authenticated identities
could be imagined.  

 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4AGKNMR093529; Mon, 10 May 2004 09:20:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4AGKNLc093528; Mon, 10 May 2004 09:20:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4AGKMBH093520 for <[e-mail]>; Mon, 10 May 2004 09:20:22 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 10 May 2004 09:20:25 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 May 2004 09:20:25 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 10 May 2004 09:20:24 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP & validation policies
Date: Mon, 10 May 2004 09:20:23 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
thread-index: AcQzqKnXVNjf9RIEQ2+OBsDiEoRLngDARvyg
From: "Trevor Freeman" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 10 May 2004 16:20:24.0710 (UTC) FILETIME=[B2E7EA60:01C436AA]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i4AGKMBH093521
Sender: [e-mail]
Precedence: 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,
It is management of the clients which is at question here. The client
has a series of input parameters all of which are opaque. The OID is a
management indirection to a set of parameters. The ambiguity arises
because the use of the OID assumes both the manager of the client and
the manager of the server have an accurate understanding of the OID.

However give the volume of traffic on this point, I will add the
capacity to pass an optional OID in the request to the server to
identify a set of parameters in SCVP15.

Trevor

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Thursday, May 06, 2004 1:28 PM
To: Trevor Freeman
Cc: [e-mail]
Subject: RE: SCVP & validation policies

At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
>Hi Steve,
>If you want to have a shorthand notation for a validation policy, given
>we have a finite set of parameters, the I don't see the value of
>indirection via an OID. Using a hash of the set of inputs provides a
way
>of expressing the same thing without introducing ambiguity of does both
>parties have a common understating of that this means. At some point
>someone has to define the policy in terms of the 3280 input parameters.
>That definition is just as applicable and consumable by the client as a
>server therefore what did we gain from the shorthand notation? It would
>be pretty trivial to define some XML which would allow that set of
>validation parameters to be imported by any SCVP entity.
>Trevor

Trevor,

It is not indirection via an OID, it is identification via an OID. 
Clients never have to be aware of the parameters if we use an OID, 
and simplification of clients is one of the goals of SCVP. So I 
cannot agree with your comment that clients have to be able to 
consume these parameters.

Given that as a basis, it seems that we are debating whether to use 
OIDs or to create some other form of identifier via hashing 
parameters. I don't see the latter as attractive, since it requires 
additional specification of the canonicalization and encoding of the 
parameters to ensure consistency in hash computation between client 
and server.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i4ABR1kZ067191; Mon, 10 May 2004 04:27:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i4ABR1FQ067190; Mon, 10 May 2004 04:27:01 -0700 (PDT)
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.11/8.12.9) with ESMTP id i4ABQxWh067171 for <[e-mail]>; Mon, 10 May 2004 04:27:00 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i4ABQpN04477; Mon, 10 May 2004 13:26:51 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 10 May 2004 13:26:51 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i4ABQiw05728; Mon, 10 May 2004 13:26:44 +0200 (MEST)
Date: Mon, 10 May 2004 13:26:44 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: SCVP & validation policies
Cc: [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>

> 
> Hi Steve,
> If you want to have a shorthand notation for a validation policy, given
> we have a finite set of parameters, the I don't see the value of
> indirection via an OID.

One often uses the term I am conformant to protocol XYZ or profile ABC
instead of repeating the finite number of the characters in the relevant text.   

>                          Using a hash of the set of inputs provides a way
> of expressing the same thing without introducing ambiguity of does both
> parties have a common understating of that this means. At some point

'understating', I guess you mean 'understanding'. As I said, a dumb client
has no understanding, so there is no ambiguity problem. 


> someone has to define the policy in terms of the 3280 input parameters.
At the server end, at the place where the trust is managed. Dumb
clients don't need to be updated when the details change.

> That definition is just as applicable and consumable by the client as a
> server therefore what did we gain from the shorthand notation? It would
That is not the question. As far as I remember, we want a possibility
to have a dumb client and centralised policy management.

> be pretty trivial to define some XML which would allow that set of
> validation parameters to be imported by any SCVP entity.
Beware of those who use the word "trivial". By endcoding these
parameters using XER of the ASN.1 syntax, you have a tr..... ooups ...

Anyway, 

I still would like to know whether the isCa is a shorthand notation
for the explicit value of "keyUsage contains certSign", or whether
it is something else.

Do you agree that testing for a particular extendedKeyusage includes
testing for a conformant keyUsage.

I have not heard how you think to have some uniqueness of requester values
in octet strings, and whether there is can be any other way than pure
hexadecimal (or equivalent) presentation of these values, and what
local matter to match these values with the authenticated identities
could be imagined.  

 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i476mfGV057469; Thu, 6 May 2004 23:48:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i476mfnQ057468; Thu, 6 May 2004 23:48:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i476mdLB057427 for <[e-mail]>; Thu, 6 May 2004 23:48:39 -0700 (PDT) (envelope-from [e-mail])
Received: from ms8.chttl.com.tw (ms8 [10.144.2.118]) by fw.chttl.com.tw (8.12.10/8.12.10) with ESMTP id i476lVGG013557; Fri, 7 May 2004 14:47:32 +0800
Received: (from root@localhost) by ms8.chttl.com.tw (8.12.10/8.12.10) id i476lVsW014088; Fri, 7 May 2004 14:47:31 +0800
Received: from wcwang ([10.144.133.79]) by ms8.chttl.com.tw (8.12.10/8.12.10) with SMTP id i476lTZl013991; Fri, 7 May 2004 14:47:30 +0800
Message-ID: <029d01c433ff$29a73ec0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Peter Sylvester" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "Florian Oelmaier" <[e-mail]>
Cc: <[e-mail]>
References: <p06100505bcbffa312d26@[128.89.89.75]>
Subject: Re: SCVP & validation policies
Date: Fri, 7 May 2004 14:47:26 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think we should write down the possible scenarios of
the DPVclient-server interactions, or the debate will be
endless. The following  are four possible scenarios.
Part of them are concluded from the recent SCVP
discussion thread, while some of them are my own
opinions. Please make your comments and add you
own scenarios. I hope the discussion on the the
possible scenarios can help the WG to reach
consensus. I also hope that the SCVP draft can
add a section to reveal the the possible scenarios
after we reach consensus.

Scenario 1 (single central-managed vlidation policy)

  DPV server:
      only supports a single central-managed vlidation policy
      the validation policy implies all policy-dependent parameters

  DPV client:
      the validation request may optionally specify the vlidation policy OID
      the validation request needs not specify any policy-dependent
          parameters

Scenario 2 (multiple central-managed vlidation policies)

  DPV server:
      supports multiple central-managed vlidation policies
      each validation policy implies its policy-dependent parameters

  DPV client:
      the validation request need to specify the vlidation policy OID
      the validation request needs not to specify any policy-dependent
          parameters

Scenario 3 (multiple central-managed vlidation policies with a default
validation policy)

  DPV server:
      supports multiple central-managed vlidation policies with one of them
          is the default
      each validation policy implies its policy-dependent parameters

  DPV client:
      the validation request should specify the vlidation policy OID
      if the request did not specify the vlidation policy OID, then the
         server will use the default one
      the validation request needs not to specify any policy-dependent
         parameters

Scenario 4 (no central-managed vlidation policy)
  DPV server:
      with no predefined vlidation policy
      will let client side to decide how it want the server to run the path
          validation algorithm
      (Note: It is "validation algorithm" not "validation policy", since
       there is no predefined validation policy.)

  DPV client:
      the validation request should specify all initial parameters for the
         the path validation algorithm
      (Note again: It is "validation algorithm" not "validation policy",
since
        there is no predefined validation policy.)

Scenario 1, 2, and 3 are mostly occures when a DPV server is used
as an authority to centrally manage validation policies. (E.g., in an
enterprise). Scenario 4 will be the case where a DPV server is used
as a public server. (E.g., a commercial path validation service)
I believe that if a DPV server is to be used as a public server, then
there will be no any predefined validation policy between the client
and the server. Therefore, it make no sense to ask a client to specify
a validation policy OID in the request to a public DPV server. Instead,
the DPV protocol should design a mechainsm that allows the client
to specify all initial parameters for the the path validation algorithm.
In SCVP, such mechanism could be a "extension" that allows clients
to specify all initial parameters of RFC 3280 path validation algorithm.
The use of validation policy OID and validation algorithm parameters
extension is usually orthogonal. If validation policy OID is used, then
it usually means that validation algorithm parameters are implied by
the validation policy OID and therefore there is not need for the client
to specify validation algorithm parameters. On the other hand, if
validation algorithm parameters extension is used, it usually means
there is no predefined validation policy (i.e., the DPV server is a public
server) for the client to specify in its request.

Wen-Cheng Wang



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i472U7Sr001272; Thu, 6 May 2004 19:30:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i472U7Ch001271; Thu, 6 May 2004 19:30:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i472Tuth001231 for <[e-mail]>; Thu, 6 May 2004 19:30:01 -0700 (PDT) (envelope-from [e-mail])
Received: from ms21.chttl.com.tw (ms21 [10.144.2.121]) by fw.chttl.com.tw (8.12.10/8.12.10) with ESMTP id i472THGG025015; Fri, 7 May 2004 10:29:18 +0800
Received: (from root@localhost) by ms21.chttl.com.tw (8.12.10/8.12.10) id i472THrt008457; Fri, 7 May 2004 10:29:17 +0800
Received: from wcwang ([10.144.133.79]) by ms21.chttl.com.tw (8.12.10/8.12.10) with SMTP id i472TDL5008049; Fri, 7 May 2004 10:29:13 +0800
Message-ID: <00a901c433db$1668ae30$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Santoni Adriano" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, "Steve Hanna" <[e-mail]>
References: <[e-mail]>
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Date: Fri, 7 May 2004 10:29:09 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I do'nt see why name rollover certificates can not solve the
mixed encoding problem if the definition of a self-issued
certificate and the path validation algorithm in RFC 3280
is revised?

Let me use an example to explain this.

Suppose the original certificate chain is:

   Trust-Anchor ...... CA1-CA2-p-p-cert CA2-EE1-p-p-cert

where "p-p" means "issuer name in PrintableString" and
"subject name in PrintableString".

Suppose CA2 take the name rollover, it will issue the
following two self-issued certificates:
         CA2-CA2-p-u-cert
             (i.e., issuer name in PrintableString,
                     subject name in UTF8String)
         CA2-CA2-u-p-cert
             (i.e., issuer name in UTF8String,
                     subject name in PrintableString)

Suppose CA1 also take the name rollover, it will issue
the following two self-issued certificates:
         CA1-CA1-p-u-cert
             (i.e., issuer name in PrintableString,
                     subject name in UTF8String)
         CA1-CA1-u-p-cert
             (i.e., issuer name in UTF8String,
                     subject name in PrintableString)

Suppose CA2 start to issue EE certificate with UTF8String
encoding, and it issues the following EE certificate:
         CA2-EE2-u-u-cert

Then,
EE1 can still be reached by the original certificate chain:

Trust-Anchor ...... CA1-CA2-p-p-cert CA2-EE1-p-p-cert

EE1 can also be reached by the following new certificate chain:

Trust-Anchor ...... CA1-CA1-u-p-cert CA1-CA2-p-p-cert
         CA2-EE1-p-p-cert
(Assume there is another CA issues a cross-certificate to CA1
in UTF8String encoding.)

EE2 can be reached by the following new certificate chain:

Trust-Anchor ...... CA1-CA2-p-p-cert CA2-CA2-p-u-cert
         CA2-EE2-u-u-cert

One day, if CA1 renews the cross-certificate to CA2 and
adopts UTF8String encoding in the new cross-certificate, it
will issue the following cross-certificate:
         CA1-CA2-u-u-cert

Then,
EE1 can also be reached by the following new certificate chain:

Trust-Anchor ...... CA1-CA1-p-u-cert CA1-CA2-u-u-cert
         CA2-CA2-u-p-cert CA2-EE1-p-p-cert

EE2 can also be reached by the following new certificate chain:

Trust-Anchor ...... CA1-CA2-u-u-cert CA2-EE2-u-u-cert

As you can see, in theory you can always find at least one certificate
chain to EE1 (i.e., old cert with PrintableString) or EE2 (i.e., new cert
with UTF8String). However, as I said before, we should discuss how
to amend RFC 3280 to support such certificate chaining.

Wen-Cheng Wang

----- Original Message ----- 
From: "Stefan Santesson" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>; "Stephen Kent" <[e-mail]>;
"Santoni Adriano" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Thursday, May 06, 2004 9:32 PM
Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encoding
RDNs


>
> Name rollover certificates only takes care of CA name changes.
> It doesn't solve the problem if subject names have mixed encoding in the
> forest of user certificates, while the CAs names are intact.
>
> Neither does it solve when the constraint is placed above the CA
> rollover.
>
> Finally, CA name rollover will most likely bust path validation using
> other constraining mechanisms because they may just not be recognized as
> self issued due to different name encoding.
>
> Stefan Santesson
> Program Manager, Windows Security
>



To: [e-mail], [e-mail]
Subject: Re: FW: scvp
Cc: [e-mail]

I agree with Denis about a single value policy.

I think that we have already a structure elsewhere that
is close to what can be used.  

   PolicyInformation ::= SEQUENCE {
        policyIdentifier   CertPolicyId,
        policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                PolicyQualifierInfo OPTIONAL }

   CertPolicyId ::= OBJECT IDENTIFIER

   PolicyQualifierInfo ::= SEQUENCE {
        policyQualifierId  PolicyQualifierId,
        qualifier          ANY DEFINED BY policyQualifierId }


the PolicyQualifierId would be an indidation of a
particular algorithm that needs to be performed and its
parameters. one would be "3280 path processing input"
another would be 'end entry naming comparison', etc. 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46GGgrt080977; Thu, 6 May 2004 09:16:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46GGgq9080976; Thu, 6 May 2004 09:16:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46GGfxj080965 for <[e-mail]>; Thu, 6 May 2004 09:16:41 -0700 (PDT) (envelope-from [e-mail])
Received: from eur-imc-02.europe.corp.microsoft.com ([65.53.196.43]) by mail-eur.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 May 2004 17:16:35 +0100
Received: from 65.53.196.43 by eur-imc-02.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 May 2004 17:16:34 +0100
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); Thu, 6 May 2004 17:16:33 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: RFC 3280 bug in name constraints
Date: Thu, 6 May 2004 17:16:31 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC 3280 bug in name constraints
Thread-Index: AcQzgCTStZhqGPYOTPa0YQ0eJXddKwAAHg0w
From: "Stefan Santesson" <[e-mail]>
To: "Sharon Boeyen" <[e-mail]>, "Steve Hanna" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 06 May 2004 16:16:33.0922 (UTC) FILETIME=[7FB17620:01C43385]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i46GGfxj080971
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with Sharon here.

Even though it may sound logical to always also constrain e-mail
attributes, changing the standard in this aspect will just break many
current implementations and I don't think there is enough motivation for
it.

I too just see it necessary if no rfc822Name is present. 

/Stefan

> -----Original Message-----
> From: Sharon Boeyen [mailto:[e-mail]]
> Sent: den 6 maj 2004 08:38
> To: 'Steve Hanna'; Stefan Santesson
> Cc: [e-mail]
> Subject: RE: RFC 3280 bug in name constraints
> 
> I prefer to leave 3280 as is (with Stefan's proposed change which I do
> support). The special case for checking email address in subject field
is,
> from my understanding, for backward compatibility reasons only for
> situations where the email address didn't appear in the extension. The
> subject field is a DN and should only be required to be checked if
there
> are DN name constraints (except for this backward compatibility issue
> where the exception is made).
> 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Steve Hanna
> Sent: Thursday, May 06, 2004 10:35 AM
> To: Stefan Santesson
> Cc: [e-mail]
> Subject: Re: RFC 3280 bug in name constraints
> 
> 
> I agree. In fact, I don't see why you wouldn't
> apply name constraints to an EmailAddress attribute
> in a subject DN even if there *is* an rfc822Name
> in a subject alternative name. I suggest that
> the text be revised to say:
> 
>     An rfc822 name constraint MUST be applied to an
>     attribute of type EmailAddress in the subject
>     distinguished name.
> 
> However, I'm willing to back down on this if
> people feel it's too strict. My concern is that
> a certificate with an email address in the
> subject DN prohibited by name constraints will
> be allowed because it also contains a permissible
> email address in the subject alternative name.
> I suspect many applications will not understand
> this and will accept the email address in the
> subject DN. In fact, RFC 2632 and its successor
> don't contain any warning about this.
> 
> Thanks,
> 
> Steve
> 
> Stefan Santesson wrote:
> > If someone is keeping record of bugs for future update of RFC 3280 I
> > have a small one to file about name constraints.
> >
> >
> >
> > In section 4.2.1.11, starting at bottom of page 38:
> >
> >
> >
> >    When rfc822 names are constrained, but the
> >
> >    certificate does not include a subject alternative name, the
rfc822
> >
> >    name constraint MUST be applied to the attribute of type
> > EmailAddress
> >
> >    in the subject distinguished name.
> >
> >
> >
> > Suppose/suggest that the intended meaning is:
> >
> >
> >
> >    When rfc822 names are constrained, but the certificate does not
> >
> >    include an rfc822Name in a subject alternative name extension,
the
> > rfc822
> >
> >    name constraint MUST be applied to the attribute of type
> > EmailAddress
> >
> >    in the subject distinguished name.
> >
> >
> >
> >
> >
> > Rationale:
> >
> > Why would the constraint NOT apply to EmailAddress just because
there
> > is
> > a SubjAltName extension with e.g. just some unrelated other name
> > component present?
> >
> >
> >
> > /Stefan
> >
> >
> >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46GPBMN081925; Thu, 6 May 2004 09:25:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46GPB2w081924; Thu, 6 May 2004 09:25:11 -0700 (PDT)
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.11/8.12.9) with ESMTP id i46GPADD081914 for <[e-mail]>; Thu, 6 May 2004 09:25:10 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i46GP5N14062; Thu, 6 May 2004 18:25:05 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 6 May 2004 18:25:05 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i46GP4O26251; Thu, 6 May 2004 18:25:04 +0200 (MEST)
Date: Thu, 6 May 2004 18:25:04 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: FW: scvp
Cc: [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>

I agree with Denis about a single value policy.

I think that we have already a structure elsewhere that
is close to what can be used.  

   PolicyInformation ::= SEQUENCE {
        policyIdentifier   CertPolicyId,
        policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                PolicyQualifierInfo OPTIONAL }

   CertPolicyId ::= OBJECT IDENTIFIER

   PolicyQualifierInfo ::= SEQUENCE {
        policyQualifierId  PolicyQualifierId,
        qualifier          ANY DEFINED BY policyQualifierId }


the PolicyQualifierId would be an indidation of a
particular algorithm that needs to be performed and its
parameters. one would be "3280 path processing input"
another would be 'end entry naming comparison', etc. 



 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46GI5CY081060; Thu, 6 May 2004 09:18:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46GI52v081059; Thu, 6 May 2004 09:18:05 -0700 (PDT)
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.9) with ESMTP id i46GI4RT081046 for <[e-mail]>; Thu, 6 May 2004 09:18:04 -0700 (PDT) (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 i46GHv7X009901; Thu, 6 May 2004 12:17:58 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06100505bcbffa312d26@[128.89.89.75]>
Date: Thu, 6 May 2004 10:44:42 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: SCVP & validation policies
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>

Trevor,

I have to agree with Denis, in that it was my impression that the 
client would pass an OID to the server to express the validation 
policy to be used. The servers will, in many cases, be local to an 
enterprise, and thus it is very feasible to use a single OID to 
reference a policy that bundles all the parameters together.  In 
fact, I am not even sure that a public SCVP server is better off with 
an ala carte approach to policy specification, but I might be able to 
be convinced.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46NXP2C031477; Thu, 6 May 2004 16:33:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46NXPPO031476; Thu, 6 May 2004 16:33:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-in.m-online.net (mail-in.m-online.net [62.245.150.237]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46NXO0K031470 for <[e-mail]>; Thu, 6 May 2004 16:33:24 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.m-online.net (svr14.m-online.net [192.168.3.144]) by svr8.m-online.net (Postfix) with ESMTP id 050A04D207; Fri,  7 May 2004 01:33:25 +0200 (CEST)
Received: from hagen (ppp-82-135-3-68.mnet-online.de [82.135.3.68]) by mail.m-online.net (Postfix) with ESMTP id A893DA29D1; Fri,  7 May 2004 01:33:24 +0200 (CEST)
From: "Florian Oelmaier" <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>, <[e-mail]>
Subject: RE: FW: scvp
Date: Fri, 7 May 2004 01:33:25 +0200
Organization: SyTrust
Message-ID: <013101c433c2$86e9d580$4228a8c0@hagen>
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.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
In-reply-to: <[e-mail]>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> If a client really trusts the server like in the enterprise, 
> then the client can take the default for everything.

Thats only partly true - one of the nice things with the policy
reference is that I can choose different validation and trust settings
for different applications. Outlook, Eudora and ohter Mail programs use
the validation setting A, Mozilla, Internet Explorer and Opera the
setting B and my Web-signing application and the ERP software uses C. 

[...]

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46NOtZ8030859; Thu, 6 May 2004 16:24:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46NOtII030858; Thu, 6 May 2004 16:24:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-in.m-online.net (mail-in.m-online.net [62.245.150.237]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46NOstE030846 for <[e-mail]>; Thu, 6 May 2004 16:24:54 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.m-online.net (svr14.m-online.net [192.168.3.144]) by svr8.m-online.net (Postfix) with ESMTP id 020424D120; Fri,  7 May 2004 01:24:50 +0200 (CEST)
Received: from hagen (ppp-82-135-3-68.mnet-online.de [82.135.3.68]) by mail.m-online.net (Postfix) with ESMTP id 7EEFAA2931; Fri,  7 May 2004 01:24:49 +0200 (CEST)
From: "Florian Oelmaier" <[e-mail]>
To: <[e-mail]>, "'Denis Pinkas'" <[e-mail]>
Subject: FW: FW: scvp
Date: Fri, 7 May 2004 01:24:49 +0200
Organization: SyTrust
Message-ID: <013001c433c1$53d2dfd0$4228a8c0@hagen>
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.3416
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Oh.Oh. I am getting old. Pressed the wrong button and wondered why the
message does not show up on the list. It is old but it fits :)

-----Original Message-----
From: Florian Oelmaier [mailto:[e-mail]] 
Sent: Wednesday, May 05, 2004 12:11 AM
To: 'Trevor Freeman'
Subject: RE: FW: scvp


Hello Trevor, Denis,

I personally agree with Denis - it seems to be better to reference a
policy. All the validation parameter settings can be agreed upon out of
band. Delivering the parameters within SCVP will a) be a never ending
task as people will always want another parameter for their special
use-case, b) will make the protocol even more complex in wording and
implementation and c) will make it less interoperable, as client will
expect a certain behaviour of the server when delivering certain
parameters.

So may be I am not in line with the "many groups" but I think that the
idea of a validation-policy OID is better.

Just my 0.02cp,

Florian Oelmaier
SyTrust

> 
> Hi Denis,
> There is no mandate in 3379 that a validation policy must be
> expressed with a single value. It is not clear that is any 
> value is doing so since it only raised more ambiguity. This 
> is well trod turf by many groups who have debated the merits 
> of providing suits vs. "al a carte" combinations of inputs 
> and the broader consensus is for a "al a carte". Trevor
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Tuesday, May 04, 2004 3:15 AM
> To: Trevor Freeman
> Cc: [e-mail]
> Subject: Re: FW: scvp
> 
> Trevor,
> 
> > Hi Denis,
> > 
> > 3379 does not require that the validation policy be specified in a
> > single value.
> 
> You are playing with words. The text says:
> "most clients will simply reference a validation policy"
> 
> This means that validation policies can be referenced and
> thus parameters do 
> not need to be defined through this interface.
> 
> A simple and good reference is an OID.
> 
> > With SCVP14 a client can accept the default of the SCVP server or
> > specify a set of parameters which constitutes its 
> validation policy.
> > That is consistent with the requirements of 3379.
> 
> The specification of the set of parameters should be done through a
> different interface. This different interface can then return an OID 
> Whatever this additional interface can be, it will never be 
> rich enough to 
> pass all the details of the validation policy. Thus OIDs can 
> also be defined 
> not using this additional interface.
> 
> Denis
> 
> > Trevor
> > 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, April 29, 2004 3:54 AM
> > To: Trevor Freeman
> > Cc: [e-mail]
> > Subject: Re: FW: scvp
> > 
> > Trevor,
> > 
> > 
> >>Hi Denis,
> > 
> > 
> >>Can you please be more specific how you think SCVP 14 does
> not comply
> >>with 3379.
> >>
> >>I can find no section in 3379 where is there a requirement that a
> >>validation policy MUST be represented as an OID.
> > 
> > 
> > There cannot be a requirement with such a level of detail, but the
> text
> > states:
> > 
> >     The protocol MUST allow the client to include
> >     these policy dependant parameters in the DPV request;
> however, it
> is
> >     expected that most clients will simply reference a validation
> policy
> >     for a given application or accept the DPV server's default
> > validation
> >     policy.
> > 
> > A simple reference is an OID.
> > 
> > FYI, I do not expect to use the "default validation policy".
> > 
> > Denis
> > 
> > 
> > 
> >>Given hiding the detail of what a policy is within an OID
> simply opens
> >>the rat hole of what change to the policy constitutes a
> change to the
> >>OID, it is less ambiguous to refer to the primary data. Once you are
> > 
> > in
> > 
> >>the business of managing state on a client, then there is
> negligible
> >>cost increase incurred in managing several data points vs. a singe
> > 
> > data
> > 
> >>point.
> >>
> >>Trevor
> >>
> >>-----Original Message-----
> >>From: Denis Pinkas [mailto:[e-mail]]
> >>Sent: Tuesday, April 27, 2004 11:01 AM
> >>To: Trevor Freeman
> >>Cc: [e-mail]
> >>Subject: Re: FW: scvp
> >>
> >>Trevor,
> >>
> >>
> >>
> >>>HI Denis,
> >>>In SCVP13, the concept of validation policy was not completely in
> >>>alignment  with 3379 definition.
> >>
> >>
> >>Well, it is different and this is a major problem.
> >>
> >>
> >>
> >>>It also blurred the distinction between
> >>>validation policy and validation algorithm.
> >>
> >>
> >>This is also a majo problem.
> >>
> >>
> >>
> >>>Therefore I have defined
> >>>what each is in SCVP 14 and aligned the structures accordingly.
> >>>Section 1.3 has the following. "In SCVP, the validation policy 
> >>>comprises of an algorithm for certificate path processing and the 
> >>>input parameters to the
> >>
> >>algorithm."
> >>
> >>This does not comply with RFC 3379.
> >>
> >>
> >>
> >>>Therefore trust anchors are an input into the algorithm  and
> therefore
> >>>separate.
> >>
> >>
> >>Therefore I do not follow you.
> >>
> >> From an interface point of view the simplest validation policy is
> >>defined by an OID where all the parameters necessary to perform the 
> >>validation check
> >>are "behind" the OID. There is no need to provide any parameter
> > 
> > through
> > 
> >>the
> >>interface.
> >>
> >>When there are some parameters, then they are specific to the
> > 
> > validation
> > 
> >>policy. I have no problem to provide specific parameters
> for what is
> >>called the "default validation policy" which is only a particular
> >>validation policy
> >>among many others.
> >>
> >>Simple clients will be unable to pass any parameter but will know
> > 
> > which
> > 
> >>OIDs
> >>(for the validation policy) are appropriate for their applications.
> >>
> >>Denis
> >>
> >>
> >>
> >>>This is in alignment with 3379s definition of validation policy.
> >>>
> >>>Trevor
> >>>
> >>>-----Original Message-----
> >>>From: Denis Pinkas [mailto:[e-mail]]
> >>>Sent: Monday, April 26, 2004 1:09 AM
> >>>To: Peter Sylvester
> >>>Cc: [e-mail]; Trevor Freeman
> >>>Subject: Re: FW: scvp
> >>>
> >>>Peter and Trevor,
> >>>
> >>>I have major problems too.
> >>>
> >>>
> >>>
> >>>
> >>>>in version 13 the syntax for a Query has been changed from
> >>>>
> >>>> Query ::= SEQUENCE { 
> >>>>     queriedCerts          SEQUENCE SIZE (1..MAX) OF 
> CertReference,
> >>>>     checks                CertChecks, 
> >>>>     wantBack              WantBack, 
> >>>>     serverContextInfo [0] OCTET STRING OPTIONAL, 
> >>>>     valPolicy         [1] ValidationPolicy OPTIONAL, 
> >>>>     validityTime      [2] GeneralizedTime OPTIONAL, 
> >>>>     trustAnchors      [3] TrustAnchors OPTIONAL, 
> >>>>     intermediateCerts [4] CertBundle OPTIONAL, 
> >>>>     revInfos          [5] RevocationInfos OPTIONAL, 
> >>>>     queryExtensions   [6] Extensions OPTIONAL } 
> >>>
> >>>
> >>>In this structure trustAnchors was more or less an alternative to
> >>>valPolicy.
> >>>
> >>>In fact, IF the valPolicy is the default policy, THEN additional
> >>>parameters MUST be provided. So the structure below does 
> not fit as
> >>>well.
> >>>
> >>>This leads to have the two following elements:
> >>>
> >>>    valPolicy               ValidationPolicy,
> >>>    paramsDefValPolicy      ParamsDefValPolicy OPTIONAL,
> >>>
> >>>where the first one is mandatory and the second one optional.
> >>>
> >>>
> >>>
> >>>
> >>>>to
> >>>>
> >>>>  Query ::= SEQUENCE { 
> >>>>    queriedCerts            SEQUENCE SIZE (1..MAX) OF 
> CertReference,
> >>>
> >>>
> >>>>    checks                  CertChecks, 
> >>>>    wantBack                WantBack, 
> >>>>    requestRefHash          BOOLEAN DEFAULT TRUE, 
> >>>>    includePolResponce      BOOLEAN DEFAULT FALSE, 
> >>>>    inhibitPolMap           BOOLEAN DEFAULT FALSE, 
> >>>>    requireExplicitPol      BOOLEAN DEFAULT FALSE, 
> >>>>    ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
> >>>>    valAlgorithm            ValidationAlgorithm, 
> >>>>    serverContextInfo   [0] OCTET STRING OPTIONAL, 
> >>>>    validityTime        [1] GeneralizedTime OPTIONAL, 
> >>>>    trustAnchors        [2] TrustAnchors OPTIONAL, 
> >>>>    intermediateCerts   [3] CertBundle OPTIONAL, 
> >>>>    revInfos            [4] RevocationInfos OPTIONAL, 
> >>>>    queryExtensions     [5] Extensions OPTIONAL } 
> >>>
> >>>
> >>>I would thus propose to have something like:
> >>>
> >>>Query ::= SEQUENCE {
> >>>        queriedCerts            SEQUENCE SIZE (1..MAX) OF
> >>>CertReference,
> >>>        checks                  CertChecks,
> >>>        wantBack                WantBack,
> >>>        requestRefHash          BOOLEAN DEFAULT TRUE,
> >>>        serverContextInfo       OCTET STRING OPTIONAL,
> >>>        validityTime            GeneralizedTime OPTIONAL,
> >>>        includePolResponse      BOOLEAN DEFAULT FALSE,
> >>>        valPolicy               ValidationPolicy,
> >>>        paramsDefValPolicy  [0] ParamsDefValPolicy OPTIONAL,
> >>>        intermediateCerts   [1] CertBundle OPTIONAL,
> >>>        revInfos            [2] RevocationInfos OPTIONAL,
> >>>        queryExtensions     [3] Extensions OPTIONAL }
> >>>
> >>>and then something like:
> >>>
> >>>   ParamsDefValPolicy :: = SEQUENCE {
> >>>       trustAnchors                  TrustAnchors,
> >>>       endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER
> >>>OPTIONAL,
> >>>       inhibitPolMap                 BOOLEAN DEFAULT FALSE,
> >>>       caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER
> >>>OPTIONAL }
> >>>
> >>>Denis
> >>>
> >>>
> >>>
> >>>
> >>>>I am not sure whether I am the only person unable to construct a
> >>>
> >>>parser.
> >>>
> >>>
> >>>
> >>>>in version 14 an aditional flag has been added which is not
> available
> >>>
> >>>in the
> >>>
> >>>
> >>>
> >>>>Chapter 9. Is the isCA flag an orthogonal attribut to other
> >>>
> > validation
> > 
> >>>>algorithms, or just to some of them, e.g,. the default
> name matching
> >>>
> >>>one?
> >>>
> >>>
> >>>
> >>>>  Query ::= SEQUENCE { 
> >>>>    queriedCerts            SEQUENCE SIZE (1..MAX) OF 
> CertReference,
> >>>
> >>>
> >>>>    checks                  CertChecks, 
> >>>>    wantBack                WantBack, 
> >>>>    requestRefHash          BOOLEAN DEFAULT TRUE, 
> >>>>    includePolResponce      BOOLEAN DEFAULT FALSE, 
> >>>>    inhibitPolMap           BOOLEAN DEFAULT FALSE, 
> >>>>    requireExplicitPol      BOOLEAN DEFAULT FALSE, 
> >>>>    ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
> >>>>    isCA                    BOOLEAN DEFAULT FALSE, 
> >>>>    valAlgorithm            ValidationAlgorithm, 
> >>>>    serverContextInfo   [0] OCTET STRING OPTIONAL, 
> >>>>    validityTime        [1] GeneralizedTime OPTIONAL, 
> >>>>    trustAnchors        [2] TrustAnchors OPTIONAL, 
> >>>>    intermediateCerts   [3] CertBundle OPTIONAL, 
> >>>>    revInfos            [4] RevocationInfos OPTIONAL, 
> >>>>    keyUsage            [5] KeyUsage OPTIONAL, 
> >>>>    extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
> >>>>    queryExtensions     [7] Extensions OPTIONAL  
> >>>>    producedAt          [8] GeneralizedTime OPTIONAL} 
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> > 
> > 
> > 
> 
> 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46NAt0o029588; Thu, 6 May 2004 16:10:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46NAtrR029586; Thu, 6 May 2004 16:10:55 -0700 (PDT)
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.9) with ESMTP id i46NAsxc029564; Thu, 6 May 2004 16:10:54 -0700 (PDT) (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 i46NAi7X002262; Thu, 6 May 2004 19:10:44 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0610051abcc07503df04@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <p0610050bbcc0378b76f1@[128.89.89.75]> <[e-mail]>
Date: Thu, 6 May 2004 19:05:53 -0400
To: Steve Hanna <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: RFC 3280 bug in name constraints
Cc: Stefan Santesson <[e-mail]>, Sharon Boeyen <[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>

Steve,

Thanks for the thoughtful analysis.  I think you make a good argument 
for why it can be dangerous for one to apply an rfc822name constraint 
to a sub alt name but not an e-mail attribute in a subject name, and 
how the combination might arise.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46M1Lgd023367; Thu, 6 May 2004 15:01:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46M1L3X023365; Thu, 6 May 2004 15:01:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46M1J5g023347 for <[e-mail]>; Thu, 6 May 2004 15:01:20 -0700 (PDT) (envelope-from [e-mail])
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i46M00sX022625 for <[e-mail]>; Thu, 6 May 2004 16:00:00 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <[e-mail]> for [e-mail]; Thu, 06 May 2004 18:01:17 -0400 (EDT)
Received: from sun.com (dhcp-ubur02-75-154.East.Sun.COM [129.148.75.154]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]>; Thu, 06 May 2004 18:01:17 -0400 (EDT)
Date: Thu, 06 May 2004 17:57:16 -0400
From: Steve Hanna <[e-mail]>
Subject: Re: RFC 3280 bug in name constraints
In-reply-to: <p0610050bbcc0378b76f1@[128.89.89.75]>
To: Stephen Kent <[e-mail]>
Cc: Stefan Santesson <[e-mail]>, Sharon Boeyen <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=------------ms000301050500030008070709
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20031111
References: <p0610050bbcc0378b76f1@[128.89.89.75]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

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

Here's a practical example where this problem
might arise. Assume that two companies, A and B,
have cross-certified (maybe through a bridge CA,
maybe directly). The cross certificate from A to B
includes a name constraint of type rfc822Name
with permittedSubtrees of b.com. The CA for B
(or perhaps a rebellious or poorly managed
subsidiary CA) issues a certificate to an
individual with an EmailAddress attribute
with the value "[e-mail]" in the subject DN
and a subject alt name of type rfc822Name
with the value "[e-mail]".

Under the current text in RFC 3280 and under
Stefan's proposed revised text, a relying
party whose trust anchor is A will consider
this certificate perfectly valid. Unless their
email software is smart enough to know that
an EmailAddress attribute in the subject DN
is not checked for name constraints when
there's also a subject alt name and therefore
the EmailAddress attribute must be ignored,
the email software will be glad to verify
email claiming to be from [e-mail] if the
signature can be verified with this certificate.

Why is this a problem? Because the name constraints
extension in the cross certificate was supposed
to prevent relying parties in A from accepting
certificates from B when an email address outside
of b.com as the subject DN or subject alt name.

I have cc'd this email to the smime WG. Maybe they
will tell me not to worry. Email clients are smart
enough to know that if a valid certificate contains
a subject alt name, then the EmailAddress attribute
in the subject DN cannot be trusted. But I don't
think email clients do this check. I certainly can't
find any language in RFC 2632 and its successor warning
people to do this.

Either RFC 3280 should consider the cert described
above as invalid or RFC 2632 should warn email developers
to ignore an EmailAddress attribute in the subject DN
if the certificate contains a subject alt name. Otherwise,
I think we have a security hole. Given the choice between
these two options, I'd rather change RFC 3280. Why?
First, I don't think that cert should be valid. Second,
it's usually easier to change the path validation code
and get that deployed (via an OS patch or equivalent)
than to change the email client code.

Thanks,

Steve

Stephen Kent wrote:
> At 5:16 PM +0100 5/6/04, Stefan Santesson wrote:
> 
>> I agree with Sharon here.
>>
>> Even though it may sound logical to always also constrain e-mail
>> attributes, changing the standard in this aspect will just break many
>> current implementations and I don't think there is enough motivation for
>> it.
>>
>> I too just see it necessary if no rfc822Name is present.
>>
>> /Stefan
>>
> 
> This is a slightly murky area. The e-mail address attribute is one that 
> we deprecate in 3280.  It is a non-standard way of representing this 
> data; it was widely used in v1 certs, but ought to be scrapped for v3 
> certs. however, is it likely that a CA who goes to the trouble to 
> include the name constraints extension, and who explicitly includes an 
> rfc822name as an alt name, would also have the email address DN 
> attribute as well?  I just wonder if this potential collision is at all 
> likely?
> 
> 
> Steve

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJNzCC
AvYwggJfoAMCAQICAww3ZDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDI4MjEwMTE0WhcNMDUwNDI4MjEwMTE0
WjBoMQ4wDAYDVQQEEwVIYW5uYTEVMBMGA1UEKhMMU3RlcGhlbiBSb3NzMRswGQYDVQQDExJT
dGVwaGVuIFJvc3MgSGFubmExIjAgBgkqhkiG9w0BCQEWE3N0ZXZlLmhhbm5hQHN1bi5jb20w
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC11rLYp70KnKGmV6pNTFRhWBwq47mV
4hU6EaZxo6I3Vw96Rd3E4TH3SAthIl5N4/tpiMPtlTBiJOU6QHSlz1DgTCclmTK6taqtEyLq
amez8vYgSdOEnOFRYILptjbEwpE+yeUmFKOmZ7zSwBMqRQatMHMaLVUJJ3Ygw1V7fKSwvVU0
OJ8c+c3sJRtRyDLxq/vMzYQP+wyqRqlJPTHGFqVuMp0FZIV5X76z+O+W90m9jXjirz91Jz+W
N6rwqmPi8Qy0uxBKm6NKT1371p+WYaK9OfGk8vGbJ8ZsTP3DyQhuuemYPbkKPtoII6WnHIGT
/DOy2G7gff7GOIhUrs7PziddAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3N0ZXZlLmhhbm5hQHN1
bi5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB++aOP6sZVYlqBGc92hZ61
FHST+OqnKZHRGkqEO94RoxdeaSUFKVO2IaKLMBmqNzmh3N3pIsIKiLhJNvDgLhlRrMRVfR29
uixjTsprR26AacMx/gCiCstGIjkzTb83xAvZay5hnzUmlt/LSNX8e6jTNav6LP64WC+C7Tul
fM/PzDCCAvYwggJfoAMCAQICAww3ZDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDI4MjEwMTE0WhcNMDUwNDI4
MjEwMTE0WjBoMQ4wDAYDVQQEEwVIYW5uYTEVMBMGA1UEKhMMU3RlcGhlbiBSb3NzMRswGQYD
VQQDExJTdGVwaGVuIFJvc3MgSGFubmExIjAgBgkqhkiG9w0BCQEWE3N0ZXZlLmhhbm5hQHN1
bi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC11rLYp70KnKGmV6pNTFRh
WBwq47mV4hU6EaZxo6I3Vw96Rd3E4TH3SAthIl5N4/tpiMPtlTBiJOU6QHSlz1DgTCclmTK6
taqtEyLqamez8vYgSdOEnOFRYILptjbEwpE+yeUmFKOmZ7zSwBMqRQatMHMaLVUJJ3Ygw1V7
fKSwvVU0OJ8c+c3sJRtRyDLxq/vMzYQP+wyqRqlJPTHGFqVuMp0FZIV5X76z+O+W90m9jXji
rz91Jz+WN6rwqmPi8Qy0uxBKm6NKT1371p+WYaK9OfGk8vGbJ8ZsTP3DyQhuuemYPbkKPtoI
I6WnHIGT/DOy2G7gff7GOIhUrs7PziddAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3N0ZXZlLmhh
bm5hQHN1bi5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB++aOP6sZVYlqB
Gc92hZ61FHST+OqnKZHRGkqEO94RoxdeaSUFKVO2IaKLMBmqNzmh3N3pIsIKiLhJNvDgLhlR
rMRVfR29uixjTsprR26AacMx/gCiCstGIjkzTb83xAvZay5hnzUmlt/LSNX8e6jTNav6LP64
WC+C7TulfM/PzDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYT
AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE
ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqG
SIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBa
Fw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs
dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz
dWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRw
nd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn
8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg
t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0
dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1Ud
DwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJ
KoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A
9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH
1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJ
BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDDdkMAkGBSsOAwIa
BQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDUw
NjIxNTcxNlowIwYJKoZIhvcNAQkEMRYEFLEY3mT3MOXY0xulNnJoOl38MmtLMFIGCSqGSIb3
DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG
BSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMN2QwegYLKoZIhvcNAQkQAgsxa6Bp
MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu
MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDDdkMA0G
CSqGSIb3DQEBAQUABIIBAJwSXRZvvuOVpdMezj+27FY1npRm7LAGKCgtQfPo1lmoKMyn6plY
X8W88OH/jP+8i2Taw1xdLzx+Qch+7Sj/GCp6C9rBCsAzURRrd7jvqbTndYsMssr6qzbNvVkh
XLt7dj/h0FakFodszZYsW5kuvSRY/6cgPBNRLz1iVxprTndcpTgnWYdS5u7FBTjulI4yvX2D
kEXTN44oIM5rTLTM0Au8lpZWjApl8l5lDjV4amzufyR4DbmzR5ut9paYWN2cyx7fbL0NJ/13
+rW9re6Yam+yB71Tof3x2T6mop7Q8zRgCWvnQYiinelIkzMucjOsz5VuAhB2Nln4SmI2JAr2
jIIAAAAAAAA=
--------------ms000301050500030008070709--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46KSxZJ015572; Thu, 6 May 2004 13:28:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46KSxXR015571; Thu, 6 May 2004 13:28:59 -0700 (PDT)
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.9) with ESMTP id i46KSwDo015559 for <[e-mail]>; Thu, 6 May 2004 13:28:58 -0700 (PDT) (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 i46KSC7X025140; Thu, 6 May 2004 16:28:13 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0610050cbcc04e1ac079@[128.89.89.75]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Thu, 6 May 2004 16:23:24 -0400
To: "Trevor Freeman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: FW: scvp
Cc: "Peter Sylvester" <[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 11:33 AM -0700 5/6/04, Trevor Freeman wrote:
>If a client really trusts the server like in the enterprise, then the
>client can take the default for everything.

That seems unlikely to me, not because of trust issues, but because 
the validation policy may (should?) be application specific and thus 
the client may need to assert a per-application policy to ensure that 
the validation process is appropriate to the application.

>  What I am suggesting is that
>there could be a long or short had way of expressing the policy and a
>client can choose either. Given we have a well know list of parameters,
>we can pass them directly or indirectly via a hash. Explicit passing is
>more robust since it is unambiguous and requires no configuration on the
>part of the server. The client also has a fallback in the event he
>server does not recognize the shorthand. I do not buy the argument that
>using a shorthand is easer to manage. You MUST at some point define the
>policy in terms of the validation input parameters and that definition
>can just as easily be consumed by the client as the server. So all I see
>is the shorthand saves bandwidth - which is a minimal gain.

The definition of the parameters is done via a separate protocol, and 
is a management activity that the client may never have to employ. 
So, on that regard, I disagree that the client needs to "consume" 
these parameters.

I would rather see a set of parameters referenced via an OID, than 
via a hash of the parameters, to keep things simpler.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46KSM5U015533; Thu, 6 May 2004 13:28:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46KSM9g015532; Thu, 6 May 2004 13:28:22 -0700 (PDT)
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.9) with ESMTP id i46KSLaa015526 for <[e-mail]>; Thu, 6 May 2004 13:28:21 -0700 (PDT) (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 i46KSC7Z025140; Thu, 6 May 2004 16:28:14 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0610050dbcc04efaf4ce@[128.89.89.75]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Thu, 6 May 2004 16:27:58 -0400
To: "Trevor Freeman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: SCVP & validation policies
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:10 PM -0700 5/6/04, Trevor Freeman wrote:
>Hi Steve,
>If you want to have a shorthand notation for a validation policy, given
>we have a finite set of parameters, the I don't see the value of
>indirection via an OID. Using a hash of the set of inputs provides a way
>of expressing the same thing without introducing ambiguity of does both
>parties have a common understating of that this means. At some point
>someone has to define the policy in terms of the 3280 input parameters.
>That definition is just as applicable and consumable by the client as a
>server therefore what did we gain from the shorthand notation? It would
>be pretty trivial to define some XML which would allow that set of
>validation parameters to be imported by any SCVP entity.
>Trevor

Trevor,

It is not indirection via an OID, it is identification via an OID. 
Clients never have to be aware of the parameters if we use an OID, 
and simplification of clients is one of the goals of SCVP. So I 
cannot agree with your comment that clients have to be able to 
consume these parameters.

Given that as a basis, it seems that we are debating whether to use 
OIDs or to create some other form of identifier via hashing 
parameters. I don't see the latter as attractive, since it requires 
additional specification of the canonicalization and encoding of the 
parameters to ensure consistency in hash computation between client 
and server.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46KH23c015022; Thu, 6 May 2004 13:17:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46KH2YG015021; Thu, 6 May 2004 13:17:02 -0700 (PDT)
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.9) with ESMTP id i46KH1Xa014993 for <[e-mail]>; Thu, 6 May 2004 13:17:01 -0700 (PDT) (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 i46KGo7X024540; Thu, 6 May 2004 16:16:51 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0610050bbcc0378b76f1@[128.89.89.75]>
In-Reply-To:  <[e-mail].c om>
References:  <[e-mail].c om>
Date: Thu, 6 May 2004 16:16:35 -0400
To: "Stefan Santesson" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: RFC 3280 bug in name constraints
Cc: "Sharon Boeyen" <[e-mail]>, "Steve Hanna" <[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 5:16 PM +0100 5/6/04, Stefan Santesson wrote:
>I agree with Sharon here.
>
>Even though it may sound logical to always also constrain e-mail
>attributes, changing the standard in this aspect will just break many
>current implementations and I don't think there is enough motivation for
>it.
>
>I too just see it necessary if no rfc822Name is present.
>
>/Stefan
>

This is a slightly murky area. The e-mail address attribute is one 
that we deprecate in 3280.  It is a non-standard way of representing 
this data; it was widely used in v1 certs, but ought to be scrapped 
for v3 certs. however, is it likely that a CA who goes to the trouble 
to include the name constraints extension, and who explicitly 
includes an rfc822name as an alt name, would also have the email 
address DN attribute as well?  I just wonder if this potential 
collision is at all likely?


Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46JAwAr010489; Thu, 6 May 2004 12:10:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46JAwUS010488; Thu, 6 May 2004 12:10:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46JAvHU010480 for <[e-mail]>; Thu, 6 May 2004 12:10:57 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 6 May 2004 12:10:57 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 May 2004 12:10:55 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 May 2004 12:10:57 -0700
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP & validation policies
Date: Thu, 6 May 2004 12:10:59 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP & validation policies
thread-index: AcQzhbOY+EdcC6TTRY2dc8NHmQ0MfgAFmqFg
From: "Trevor Freeman" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 06 May 2004 19:10:57.0083 (UTC) FILETIME=[DC3920B0:01C4339D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i46JAvHU010481
Sender: [e-mail]
Precedence: 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,
If you want to have a shorthand notation for a validation policy, given
we have a finite set of parameters, the I don't see the value of
indirection via an OID. Using a hash of the set of inputs provides a way
of expressing the same thing without introducing ambiguity of does both
parties have a common understating of that this means. At some point
someone has to define the policy in terms of the 3280 input parameters.
That definition is just as applicable and consumable by the client as a
server therefore what did we gain from the shorthand notation? It would
be pretty trivial to define some XML which would allow that set of
validation parameters to be imported by any SCVP entity.
Trevor

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Thursday, May 06, 2004 7:45 AM
To: Trevor Freeman
Cc: [e-mail]
Subject: SCVP & validation policies

Trevor,

I have to agree with Denis, in that it was my impression that the 
client would pass an OID to the server to express the validation 
policy to be used. The servers will, in many cases, be local to an 
enterprise, and thus it is very feasible to use a single OID to 
reference a policy that bundles all the parameters together.  In 
fact, I am not even sure that a public SCVP server is better off with 
an ala carte approach to policy specification, but I might be able to 
be convinced.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46IgV2w007246; Thu, 6 May 2004 11:42:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46IgV8B007245; Thu, 6 May 2004 11:42:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm1.entrust.com (sottmxssm1.entrust.com [216.191.252.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46IgUDG007237 for <[e-mail]>; Thu, 6 May 2004 11:42:30 -0700 (PDT) (envelope-from [e-mail])
Received: from SOTTMXS01.entrust.com ([10.4.61.7]) by sottmxssm1.entrust.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i46Ipgwu027642; Thu, 6 May 2004 14:51:42 -0400
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2657.72) id <KM64Z9Q0>; Thu, 6 May 2004 14:42:24 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>, Stefan Santesson <[e-mail]>
Cc: [e-mail]
Subject: RE: RFC 3280 bug in name constraints
Date: Thu, 6 May 2004 14:42:25 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Apparently some could not read the message I sent earlier, so here is a
resend. 

I prefer to leave 3280 as is (with Stefan's proposed change which I do
support). The special case for checking email address in subject field is,
from my understanding, for backward compatibility reasons only for
situations where the email address didn't appear in the extension. The
subject field is a DN and should only be required to be checked if there are
DN name constraints (except for this backward compatibility issue where the
exception is made).

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Steve Hanna
Sent: Thursday, May 06, 2004 10:35 AM
To: Stefan Santesson
Cc: [e-mail]
Subject: Re: RFC 3280 bug in name constraints


I agree. In fact, I don't see why you wouldn't
apply name constraints to an EmailAddress attribute
in a subject DN even if there *is* an rfc822Name
in a subject alternative name. I suggest that
the text be revised to say:

    An rfc822 name constraint MUST be applied to an
    attribute of type EmailAddress in the subject
    distinguished name.

However, I'm willing to back down on this if
people feel it's too strict. My concern is that
a certificate with an email address in the
subject DN prohibited by name constraints will
be allowed because it also contains a permissible
email address in the subject alternative name.
I suspect many applications will not understand
this and will accept the email address in the
subject DN. In fact, RFC 2632 and its successor
don't contain any warning about this.

Thanks,

Steve

Stefan Santesson wrote:
> If someone is keeping record of bugs for future update of RFC 3280 I
> have a small one to file about name constraints.
> 
>  
> 
> In section 4.2.1.11, starting at bottom of page 38:
> 
>  
> 
>    When rfc822 names are constrained, but the
> 
>    certificate does not include a subject alternative name, the rfc822
> 
>    name constraint MUST be applied to the attribute of type 
> EmailAddress
> 
>    in the subject distinguished name.
> 
>  
> 
> Suppose/suggest that the intended meaning is:
> 
>  
> 
>    When rfc822 names are constrained, but the certificate does not
> 
>    include an rfc822Name in a subject alternative name extension, the 
> rfc822
> 
>    name constraint MUST be applied to the attribute of type 
> EmailAddress
> 
>    in the subject distinguished name.
> 
>  
> 
>  
> 
> Rationale:
> 
> Why would the constraint NOT apply to EmailAddress just because there 
> is
> a SubjAltName extension with e.g. just some unrelated other name 
> component present?
> 
>  
> 
> /Stefan
> 
>  
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46IXMZ2006109; Thu, 6 May 2004 11:33:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46IXMci006108; Thu, 6 May 2004 11:33:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46IXLGa006100 for <[e-mail]>; Thu, 6 May 2004 11:33:21 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 6 May 2004 11:33:18 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 May 2004 11:33:17 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 May 2004 11:33:19 -0700
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: FW: scvp
Date: Thu, 6 May 2004 11:33:18 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: FW: scvp
thread-index: AcQzlIkgUYZZST4zTy6tCK91qcQOXQAAbDZQ
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 06 May 2004 18:33:19.0868 (UTC) FILETIME=[9AD173C0:01C43398]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i46IXLGa006102
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If a client really trusts the server like in the enterprise, then the
client can take the default for everything. What I am suggesting is that
there could be a long or short had way of expressing the policy and a
client can choose either. Given we have a well know list of parameters,
we can pass them directly or indirectly via a hash. Explicit passing is
more robust since it is unambiguous and requires no configuration on the
part of the server. The client also has a fallback in the event he
server does not recognize the shorthand. I do not buy the argument that
using a shorthand is easer to manage. You MUST at some point define the
policy in terms of the validation input parameters and that definition
can just as easily be consumed by the client as the server. So all I see
is the shorthand saves bandwidth - which is a minimal gain.
Trevor

-----Original Message-----
From: Peter Sylvester [mailto:[e-mail]] 
Sent: Thursday, May 06, 2004 11:04 AM
To: [e-mail]; [e-mail]; Trevor Freeman
Cc: [e-mail]
Subject: RE: FW: scvp

> 
> If we want to go down the route of providing a shorthand notation for
a
> validation policy, using an OID just opens up ambiguity. We are
assuming
> both client and server have a common understating of both - which add
> additional management overhead.

A dumb client may have no understanding of a policy, it just wan't
some information concerning the usage of a cert in its particular
context. In an extreme case, just a yes/no answer is good,
and the protocol should allow to have such a minimal exchange.

You are describing a way that a client MUST always provide actual
parameters. This seems to me unnecessary overhead at the client. 

If the actual policy parameters are required to be known by the
client, the server can return then in the response, so that they
can be logged by the client if necessary, or transferred to another
relying party, etc. 

We assume that the application of the policy is under the responsibility
of the server, it seems rather natural to me that in case that
the response could be questioned in the future, the server indicated
what it had done. or, the informations gets transferred only once.


>                              It seems like yesterday we had the
> discussion on whether a certificate policy should also have a hash so
> the RP could tell if the policy had changed. If we truly want a
> shorthand notation to a policy then using a hash over the set of input
> parameters provides an unambiguous statement of what is required.

It is absolutely possible that the policy details at the server
will change without a need for a client to get informed, at least
in an enterprise internal  environment. It is at the server side
where all decisions are made for dumb clients.

If the client has a single application context, then a
request should be possible to contain just the reference to
the cert or the cert, and in an extreme, even the policy could be
derived at the server if the client can be identified and authenticated,
in this case the client configuration is minimal.

Peter 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46I49H5003206; Thu, 6 May 2004 11:04:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46I490A003205; Thu, 6 May 2004 11:04:09 -0700 (PDT)
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.11/8.12.9) with ESMTP id i46I47hx003197 for <[e-mail]>; Thu, 6 May 2004 11:04:08 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i46I3wN15897; Thu, 6 May 2004 20:03:58 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Thu, 6 May 2004 20:03:58 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i46I3r426566; Thu, 6 May 2004 20:03:53 +0200 (MEST)
Date: Thu, 6 May 2004 20:03:53 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: FW: scvp
Cc: [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>

> 
> If we want to go down the route of providing a shorthand notation for a
> validation policy, using an OID just opens up ambiguity. We are assuming
> both client and server have a common understating of both - which add
> additional management overhead.

A dumb client may have no understanding of a policy, it just wan't
some information concerning the usage of a cert in its particular
context. In an extreme case, just a yes/no answer is good,
and the protocol should allow to have such a minimal exchange.

You are describing a way that a client MUST always provide actual
parameters. This seems to me unnecessary overhead at the client. 

If the actual policy parameters are required to be known by the
client, the server can return then in the response, so that they
can be logged by the client if necessary, or transferred to another
relying party, etc. 

We assume that the application of the policy is under the responsibility
of the server, it seems rather natural to me that in case that
the response could be questioned in the future, the server indicated
what it had done. or, the informations gets transferred only once.


>                              It seems like yesterday we had the
> discussion on whether a certificate policy should also have a hash so
> the RP could tell if the policy had changed. If we truly want a
> shorthand notation to a policy then using a hash over the set of input
> parameters provides an unambiguous statement of what is required.

It is absolutely possible that the policy details at the server
will change without a need for a client to get informed, at least
in an enterprise internal  environment. It is at the server side
where all decisions are made for dumb clients.

If the client has a single application context, then a
request should be possible to contain just the reference to
the cert or the cert, and in an extreme, even the policy could be
derived at the server if the client can be identified and authenticated,
in this case the client configuration is minimal.

Peter 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46HMdWB086521; Thu, 6 May 2004 10:22:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46HMdjT086520; Thu, 6 May 2004 10:22:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46HMcNT086511 for <[e-mail]>; Thu, 6 May 2004 10:22:38 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 6 May 2004 10:22:39 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 May 2004 10:22:38 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 May 2004 10:22:38 -0700
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: FW: scvp
Date: Thu, 6 May 2004 10:22:37 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: FW: scvp
thread-index: AcQzhrht+5OGU+yKT9u+eO3Qp0M+9AABu+ww
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 06 May 2004 17:22:38.0732 (UTC) FILETIME=[BAE774C0:01C4338E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i46HMcNT086515
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If we want to go down the route of providing a shorthand notation for a
validation policy, using an OID just opens up ambiguity. We are assuming
both client and server have a common understating of both - which add
additional management overhead. It seems like yesterday we had the
discussion on whether a certificate policy should also have a hash so
the RP could tell if the policy had changed. If we truly want a
shorthand notation to a policy then using a hash over the set of input
parameters provides an unambiguous statement of what is required.
Trevor

-----Original Message-----
From: Peter Sylvester [mailto:[e-mail]] 
Sent: Thursday, May 06, 2004 9:25 AM
To: Trevor Freeman; [e-mail]
Cc: [e-mail]
Subject: Re: FW: scvp

I agree with Denis about a single value policy.

I think that we have already a structure elsewhere that
is close to what can be used.  

   PolicyInformation ::= SEQUENCE {
        policyIdentifier   CertPolicyId,
        policyQualifiers   SEQUENCE SIZE (1..MAX) OF
                                PolicyQualifierInfo OPTIONAL }

   CertPolicyId ::= OBJECT IDENTIFIER

   PolicyQualifierInfo ::= SEQUENCE {
        policyQualifierId  PolicyQualifierId,
        qualifier          ANY DEFINED BY policyQualifierId }


the PolicyQualifierId would be an indidation of a
particular algorithm that needs to be performed and its
parameters. one would be "3280 path processing input"
another would be 'end entry naming comparison', etc. 



 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46FkniR078911; Thu, 6 May 2004 08:46:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46Fkndd078910; Thu, 6 May 2004 08:46:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft3.fr.colt.net (smtp-ft3.fr.colt.net [213.41.78.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46Fkmtx078894 for <[e-mail]>; Thu, 6 May 2004 08:46:48 -0700 (PDT) (envelope-from [e-mail])
Received: from free.fr (host.106.92.68.195.rev.coltfrance.com [195.68.92.106]) by smtp-ft3.fr.colt.net with ESMTP id i46Fkk131204 for <[e-mail]>; Thu, 6 May 2004 17:46:46 +0200
Message-ID: <[e-mail]>
Date: Thu, 06 May 2004 17:47:45 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:) Gecko/20040226
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Steve Hanna wrote:

> A better solution is to require (or at least recommend)
> the ability to properly compare PrintableString and
> UTF8String encodings.

This still leave to the CA the task of enforcing the user certs only use 
PrintableString or UTF8String.
Either by refusing requests with other encodings or converting them.
Given the current text of RFC3280 this is probably the best choice.

But an application like openssl is currently shipped with the default of 
authorizing either of PrintableString and T61String and nothing else.
If some people do emit T61String (it does happen at least on a small 
scale), they'll need to be able to compare to UTF8String.
And this does require actual convertion whereas equality comparison of 
PrintableString and UTF8String could be done by just ignoring the asn1 
type tag.
The above reminds me how important it is that implementers correctly 
reject invalid UTF-8 sequences, and that it's not garanteed to happen.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46Fc1gB078003; Thu, 6 May 2004 08:38:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46Fc1rZ078002; Thu, 6 May 2004 08:38:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm1.entrust.com (sottmxssm1.entrust.com [216.191.252.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46Fc0iu077992 for <[e-mail]>; Thu, 6 May 2004 08:38:00 -0700 (PDT) (envelope-from [e-mail])
Received: from SOTTMXS01.entrust.com ([10.4.61.7]) by sottmxssm1.entrust.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i46FlE0K031076; Thu, 6 May 2004 11:47:14 -0400
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2657.72) id <KM64Z3JN>; Thu, 6 May 2004 11:37:57 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Steve Hanna'" <[e-mail]>, Stefan Santesson <[e-mail]>
Cc: [e-mail]
Subject: RE: RFC 3280 bug in name constraints
Date: Thu, 6 May 2004 11:37:57 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: application/x-pkcs7-mime; name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

MIIrqwYJKoZIhvcNAQcCoIIrnDCCK5gCAQExCzAJBgUrDgMCGgUAMIId+QYJKoZIhvcNAQcBoIId
6gSCHeZDb250ZW50LVR5cGU6IG11bHRpcGFydC9hbHRlcm5hdGl2ZTsNCglib3VuZGFyeT0iLS09
X05leHRQYXJ0X1NUSl8zODg0NTc3Ni4xMTM5MTk5ODUiDQoNCg0KLS0tLT1fTmV4dFBhcnRfU1RK
XzM4ODQ1Nzc2LjExMzkxOTk4NQ0KQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KCWNoYXJzZXQ9
IlVTLUFTQ0lJIg0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQ0K
DQpJIHByZWZlciB0byBsZWF2ZSAzMjgwIGFzIGlzICh3aXRoIFN0ZWZhbidzIHByb3Bvc2VkIGNo
YW5nZSB3aGljaCBJIGRvIHN1cHBvcnQpLiBUaGUgc3BlYz0NCmlhbCBjYXNlIGZvciBjaGVja2lu
ZyBlbWFpbCBhZGRyZXNzIGluIHN1YmplY3QgZmllbGQgaXMsIGZyb20gbXkgdW5kZXJzdGFuZGlu
ZywgZm9yIGJhYz0NCmt3YXJkIGNvbXBhdGliaWxpdHkgcmVhc29ucyBvbmx5IGZvciBzaXR1YXRp
b25zIHdoZXJlIHRoZSBlbWFpbCBhZGRyZXNzIGRpZG4ndCBhcHBlYT0NCnIgaW4gdGhlIGV4dGVu
c2lvbi4gVGhlIHN1YmplY3QgZmllbGQgaXMgYSBETiBhbmQgc2hvdWxkIG9ubHkgYmUgcmVxdWly
ZWQgdG8gYmUgY2hlY2tlZCBpZiB0PQ0KaGVyZSBhcmUgRE4gbmFtZSBjb25zdHJhaW50cyAoZXhj
ZXB0IGZvciB0aGlzIGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgaXNzdWUgd2hlcmUgdGhlIGU9DQp4
Y2VwdGlvbiBpcyBtYWRlKS49MjANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206
IG93bmVyLWlldGYtcGtpeD00MG1haWwuaW1jLm9yZyA9NUJtYWlsdG86b3duZXItaWV0Zi1wa2l4
PTQwbWFpbC5pbWMubz0NCnJnPTVEIE9uIEJlaGFsZiBPZiBTdGV2ZSBIYW5uYQ0KU2VudDogVGh1
cnNkYXksIE1heSAwNiwgMjAwNCAxMDozNSBBTQ0KVG86IFN0ZWZhbiBTYW50ZXNzb24NCkNjOiBp
ZXRmLXBraXg9NDBpbWMub3JnDQpTdWJqZWN0OiBSZTogUkZDIDMyODAgYnVnIGluIG5hbWUgY29u
c3RyYWludHMNCg0KDQpJIGFncmVlLiBJbiBmYWN0LCBJIGRvbid0IHNlZSB3aHkgeW91IHdvdWxk
bid0DQphcHBseSBuYW1lIGNvbnN0cmFpbnRzIHRvIGFuIEVtYWlsQWRkcmVzcyBhdHRyaWJ1dGUN
CmluIGEgc3ViamVjdCBETiBldmVuIGlmIHRoZXJlICppcyogYW4gcmZjODIyTmFtZQ0KaW4gYSBz
dWJqZWN0IGFsdGVybmF0aXZlIG5hbWUuIEkgc3VnZ2VzdCB0aGF0DQp0aGUgdGV4dCBiZSByZXZp
c2VkIHRvIHNheToNCg0KICAgIEFuIHJmYzgyMiBuYW1lIGNvbnN0cmFpbnQgTVVTVCBiZSBhcHBs
aWVkIHRvIGFuDQogICAgYXR0cmlidXRlIG9mIHR5cGUgRW1haWxBZGRyZXNzIGluIHRoZSBzdWJq
ZWN0DQogICAgZGlzdGluZ3Vpc2hlZCBuYW1lLg0KDQpIb3dldmVyLCBJJ20gd2lsbGluZyB0byBi
YWNrIGRvd24gb24gdGhpcyBpZg0KcGVvcGxlIGZlZWwgaXQncyB0b28gc3RyaWN0LiBNeSBjb25j
ZXJuIGlzIHRoYXQNCmEgY2VydGlmaWNhdGUgd2l0aCBhbiBlbWFpbCBhZGRyZXNzIGluIHRoZQ0K
c3ViamVjdCBETiBwcm9oaWJpdGVkIGJ5IG5hbWUgY29uc3RyYWludHMgd2lsbA0KYmUgYWxsb3dl
ZCBiZWNhdXNlIGl0IGFsc28gY29udGFpbnMgYSBwZXJtaXNzaWJsZQ0KZW1haWwgYWRkcmVzcyBp
biB0aGUgc3ViamVjdCBhbHRlcm5hdGl2ZSBuYW1lLg0KSSBzdXNwZWN0IG1hbnkgYXBwbGljYXRp
b25zIHdpbGwgbm90IHVuZGVyc3RhbmQNCnRoaXMgYW5kIHdpbGwgYWNjZXB0IHRoZSBlbWFpbCBh
ZGRyZXNzIGluIHRoZQ0Kc3ViamVjdCBETi4gSW4gZmFjdCwgUkZDIDI2MzIgYW5kIGl0cyBzdWNj
ZXNzb3INCmRvbid0IGNvbnRhaW4gYW55IHdhcm5pbmcgYWJvdXQgdGhpcy4NCg0KVGhhbmtzLA0K
DQpTdGV2ZQ0KDQpTdGVmYW4gU2FudGVzc29uIHdyb3RlOg0KPiBJZiBzb21lb25lIGlzIGtlZXBp
bmcgcmVjb3JkIG9mIGJ1Z3MgZm9yIGZ1dHVyZSB1cGRhdGUgb2YgUkZDIDMyODAgSQ0KPiBoYXZl
IGEgc21hbGwgb25lIHRvIGZpbGUgYWJvdXQgbmFtZSBjb25zdHJhaW50cy4NCj49MjANCj4gPTIw
DQo+PTIwDQo+IEluIHNlY3Rpb24gNC4yLjEuMTEsIHN0YXJ0aW5nIGF0IGJvdHRvbSBvZiBwYWdl
IDM4Og0KPj0yMA0KPiA9MjANCj49MjANCj4gICAgV2hlbiByZmM4MjIgbmFtZXMgYXJlIGNvbnN0
cmFpbmVkLCBidXQgdGhlDQo+PTIwDQo+ICAgIGNlcnRpZmljYXRlIGRvZXMgbm90IGluY2x1ZGUg
YSBzdWJqZWN0IGFsdGVybmF0aXZlIG5hbWUsIHRoZSByZmM4MjINCj49MjANCj4gICAgbmFtZSBj
b25zdHJhaW50IE1VU1QgYmUgYXBwbGllZCB0byB0aGUgYXR0cmlidXRlIG9mIHR5cGU9MjANCj4g
RW1haWxBZGRyZXNzDQo+PTIwDQo+ICAgIGluIHRoZSBzdWJqZWN0IGRpc3Rpbmd1aXNoZWQgbmFt
ZS4NCj49MjANCj4gPTIwDQo+PTIwDQo+IFN1cHBvc2Uvc3VnZ2VzdCB0aGF0IHRoZSBpbnRlbmRl
ZCBtZWFuaW5nIGlzOg0KPj0yMA0KPiA9MjANCj49MjANCj4gICAgV2hlbiByZmM4MjIgbmFtZXMg
YXJlIGNvbnN0cmFpbmVkLCBidXQgdGhlIGNlcnRpZmljYXRlIGRvZXMgbm90DQo+PTIwDQo+ICAg
IGluY2x1ZGUgYW4gcmZjODIyTmFtZSBpbiBhIHN1YmplY3QgYWx0ZXJuYXRpdmUgbmFtZSBleHRl
bnNpb24sIHRoZT0yMA0KPiByZmM4MjINCj49MjANCj4gICAgbmFtZSBjb25zdHJhaW50IE1VU1Qg
YmUgYXBwbGllZCB0byB0aGUgYXR0cmlidXRlIG9mIHR5cGU9MjANCj4gRW1haWxBZGRyZXNzDQo+
PTIwDQo+ICAgIGluIHRoZSBzdWJqZWN0IGRpc3Rpbmd1aXNoZWQgbmFtZS4NCj49MjANCj4gPTIw
DQo+PTIwDQo+ID0yMA0KPj0yMA0KPiBSYXRpb25hbGU6DQo+PTIwDQo+IFdoeSB3b3VsZCB0aGUg
Y29uc3RyYWludCBOT1QgYXBwbHkgdG8gRW1haWxBZGRyZXNzIGp1c3QgYmVjYXVzZSB0aGVyZT0y
MA0KPiBpcw0KPiBhIFN1YmpBbHROYW1lIGV4dGVuc2lvbiB3aXRoIGUuZy4ganVzdCBzb21lIHVu
cmVsYXRlZCBvdGhlciBuYW1lPTIwDQo+IGNvbXBvbmVudCBwcmVzZW50Pw0KPj0yMA0KPiA9MjAN
Cj49MjANCj4gL1N0ZWZhbg0KPj0yMA0KPiA9MjANCj49MjANCg0KLS0tLT1fTmV4dFBhcnRfU1RK
XzM4ODQ1Nzc2LjExMzkxOTk4NQ0KQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9ydGYNCkNvbnRl
bnQtVHJhbnNmZXItRW5jb2Rpbmc6IGJhc2U2NA0KDQplMXh5ZEdZeFhHRnVjMmxjWVc1emFXTnda
ekV5TlRKY1puSnZiWFJsZUhRZ1hHUmxabVl3ZTF4bWIyNTBkR0pzDQpEUXA3WEdZd1hHWnpkMmx6
Y3lCQmNtbGhiRHQ5RFFwN1hHWXhYR1p0YjJSbGNtNGdRMjkxY21sbGNpQk9aWGM3DQpmUTBLZTF4
bU1seG1ibWxzWEdaamFHRnljMlYwTWlCVGVXMWliMnc3ZlEwS2UxeG1NMXhtYlc5a1pYSnVYR1pq
DQphR0Z5YzJWME1DQkRiM1Z5YVdWeUlFNWxkenQ5ZlEwS2UxeGpiMnh2Y25SaWJGeHlaV1F3WEdk
eVpXVnVNRnhpDQpiSFZsTUR0Y2NtVmtNRnhuY21WbGJqQmNZbXgxWlRJMU5UdDlEUXBjZFdNeFhI
QmhjbVJjY0d4aGFXNWNaR1ZtDQpkR0ZpTXpZd0lGeG1NRnhtY3pJd0lFa2djSEpsWm1WeUlIUnZJ
R3hsWVhabElETXlPREFnWVhNZ2FYTWdLSGRwDQpkR2dnVTNSbFptRnVKM01nY0hKdmNHOXpaV1Fn
WTJoaGJtZGxJSGRvYVdOb0lFa2daRzhnYzNWd2NHOXlkQ2t1DQpJRlJvWlNCemNHVmphV0ZzSUdO
aGMyVWdabTl5SUdOb1pXTnJhVzVuSUdWdFlXbHNJR0ZrWkhKbGMzTWdhVzRnDQpjM1ZpYW1WamRD
Qm1hV1ZzWkNCcGN5d2dabkp2YlNCdGVTQjFibVJsY25OMFlXNWthVzVuTENCbWIzSWdZbUZqDQph
M2RoY21RZ1kyOXRjR0YwYVdKcGJHbDBlU0J5WldGemIyNXpJRzl1YkhrZ1ptOXlJSE5wZEhWaGRH
bHZibk1nDQpkMmhsY21VZ2RHaGxJR1Z0WVdsc0lHRmtaSEpsYzNNZ1pHbGtiaWQwSUdGd2NHVmhj
aUJwYmlCMGFHVWdaWGgwDQpaVzV6YVc5dUxpQlVhR1VnYzNWaWFtVmpkQ0JtYVdWc1pDQnBjeUJo
SUVST0lHRnVaQ0J6YUc5MWJHUWdiMjVzDQplU0JpWlNCeVpYRjFhWEpsWkNCMGJ5QmlaU0JqYUdW
amEyVmtJR2xtSUhSb1pYSmxJR0Z5WlNCRVRpQnVZVzFsDQpJR052Ym5OMGNtRnBiblJ6SUNobGVH
TmxjSFFnWm05eUlIUm9hWE1nWW1GamEzZGhjbVFnWTI5dGNHRjBhV0pwDQpiR2wwZVNCcGMzTjFa
U0IzYUdWeVpTQjBhR1VnWlhoalpYQjBhVzl1SUdseklHMWhaR1VwTGlCY2NHRnlEUXBjDQpjR0Z5
RFFvdExTMHRMVTl5YVdkcGJtRnNJRTFsYzNOaFoyVXRMUzB0TFZ4d1lYSU5Da1p5YjIwNklHOTNi
bVZ5DQpMV2xsZEdZdGNHdHBlRUJ0WVdsc0xtbHRZeTV2Y21jZ1cyMWhhV3gwYnpwdmQyNWxjaTFw
WlhSbUxYQnJhWGhBDQpiV0ZwYkM1cGJXTXViM0puWFNCUGJpQkNaV2hoYkdZZ1QyWWdVM1JsZG1V
Z1NHRnVibUZjY0dGeURRcFRaVzUwDQpPaUJVYUhWeWMyUmhlU3dnVFdGNUlEQTJMQ0F5TURBMElE
RXdPak0xSUVGTlhIQmhjZzBLVkc4NklGTjBaV1poDQpiaUJUWVc1MFpYTnpiMjVjY0dGeURRcERZ
em9nYVdWMFppMXdhMmw0UUdsdFl5NXZjbWRjY0dGeURRcFRkV0pxDQpaV04wT2lCU1pUb2dVa1pE
SURNeU9EQWdZblZuSUdsdUlHNWhiV1VnWTI5dWMzUnlZV2x1ZEhOY2NHRnlEUXBjDQpjR0Z5RFFw
Y2NHRnlEUXBKSUdGbmNtVmxMaUJKYmlCbVlXTjBMQ0JKSUdSdmJpZDBJSE5sWlNCM2FIa2dlVzkx
DQpJSGR2ZFd4a2JpZDBYSEJoY2cwS1lYQndiSGtnYm1GdFpTQmpiMjV6ZEhKaGFXNTBjeUIwYnlC
aGJpQkZiV0ZwDQpiRUZrWkhKbGMzTWdZWFIwY21saWRYUmxYSEJoY2cwS2FXNGdZU0J6ZFdKcVpX
TjBJRVJPSUdWMlpXNGdhV1lnDQpkR2hsY21VZ0ttbHpLaUJoYmlCeVptTTRNakpPWVcxbFhIQmhj
ZzBLYVc0Z1lTQnpkV0pxWldOMElHRnNkR1Z5DQpibUYwYVhabElHNWhiV1V1SUVrZ2MzVm5aMlZ6
ZENCMGFHRjBYSEJoY2cwS2RHaGxJSFJsZUhRZ1ltVWdjbVYyDQphWE5sWkNCMGJ5QnpZWGs2WEhC
aGNnMEtYSEJoY2cwS0lDQWdJRUZ1SUhKbVl6Z3lNaUJ1WVcxbElHTnZibk4wDQpjbUZwYm5RZ1RW
VlRWQ0JpWlNCaGNIQnNhV1ZrSUhSdklHRnVYSEJoY2cwS0lDQWdJR0YwZEhKcFluVjBaU0J2DQpa
aUIwZVhCbElFVnRZV2xzUVdSa2NtVnpjeUJwYmlCMGFHVWdjM1ZpYW1WamRGeHdZWElOQ2lBZ0lD
QmthWE4wDQphVzVuZFdsemFHVmtJRzVoYldVdVhIQmhjZzBLWEhCaGNnMEtTRzkzWlhabGNpd2dT
U2R0SUhkcGJHeHBibWNnDQpkRzhnWW1GamF5QmtiM2R1SUc5dUlIUm9hWE1nYVdaY2NHRnlEUXB3
Wlc5d2JHVWdabVZsYkNCcGRDZHpJSFJ2DQpieUJ6ZEhKcFkzUXVJRTE1SUdOdmJtTmxjbTRnYVhN
Z2RHaGhkRnh3WVhJTkNtRWdZMlZ5ZEdsbWFXTmhkR1VnDQpkMmwwYUNCaGJpQmxiV0ZwYkNCaFpH
UnlaWE56SUdsdUlIUm9aVnh3WVhJTkNuTjFZbXBsWTNRZ1JFNGdjSEp2DQphR2xpYVhSbFpDQmll
U0J1WVcxbElHTnZibk4wY21GcGJuUnpJSGRwYkd4Y2NHRnlEUXBpWlNCaGJHeHZkMlZrDQpJR0ps
WTJGMWMyVWdhWFFnWVd4emJ5QmpiMjUwWVdsdWN5QmhJSEJsY20xcGMzTnBZbXhsWEhCaGNnMEta
VzFoDQphV3dnWVdSa2NtVnpjeUJwYmlCMGFHVWdjM1ZpYW1WamRDQmhiSFJsY201aGRHbDJaU0J1
WVcxbExseHdZWElODQpDa2tnYzNWemNHVmpkQ0J0WVc1NUlHRndjR3hwWTJGMGFXOXVjeUIzYVd4
c0lHNXZkQ0IxYm1SbGNuTjBZVzVrDQpYSEJoY2cwS2RHaHBjeUJoYm1RZ2QybHNiQ0JoWTJObGNI
UWdkR2hsSUdWdFlXbHNJR0ZrWkhKbGMzTWdhVzRnDQpkR2hsWEhCaGNnMEtjM1ZpYW1WamRDQkVU
aTRnU1c0Z1ptRmpkQ3dnVWtaRElESTJNeklnWVc1a0lHbDBjeUJ6DQpkV05qWlhOemIzSmNjR0Z5
RFFwa2IyNG5kQ0JqYjI1MFlXbHVJR0Z1ZVNCM1lYSnVhVzVuSUdGaWIzVjBJSFJvDQphWE11WEhC
aGNnMEtYSEJoY2cwS1ZHaGhibXR6TEZ4d1lYSU5DbHh3WVhJTkNsTjBaWFpsWEhCaGNnMEtYSEJo
DQpjZzBLVTNSbFptRnVJRk5oYm5SbGMzTnZiaUIzY205MFpUcGNjR0Z5RFFvK0lFbG1JSE52YldW
dmJtVWdhWE1nDQphMlZsY0dsdVp5QnlaV052Y21RZ2IyWWdZblZuY3lCbWIzSWdablYwZFhKbElI
VndaR0YwWlNCdlppQlNSa01nDQpNekk0TUNCSlhIQmhjZzBLUGlCb1lYWmxJR0VnYzIxaGJHd2di
MjVsSUhSdklHWnBiR1VnWVdKdmRYUWdibUZ0DQpaU0JqYjI1emRISmhhVzUwY3k1Y2NHRnlEUW8r
SUZ4d1lYSU5DajRnSUZ4d1lYSU5DajRnWEhCaGNnMEtQaUJKDQpiaUJ6WldOMGFXOXVJRFF1TWk0
eExqRXhMQ0J6ZEdGeWRHbHVaeUJoZENCaWIzUjBiMjBnYjJZZ2NHRm5aU0F6DQpPRHBjY0dGeURR
bytJRnh3WVhJTkNqNGdJRnh3WVhJTkNqNGdYSEJoY2cwS1BpQWdJQ0JYYUdWdUlISm1Zemd5DQpN
aUJ1WVcxbGN5QmhjbVVnWTI5dWMzUnlZV2x1WldRc0lHSjFkQ0IwYUdWY2NHRnlEUW8rSUZ4d1lY
SU5DajRnDQpJQ0FnWTJWeWRHbG1hV05oZEdVZ1pHOWxjeUJ1YjNRZ2FXNWpiSFZrWlNCaElITjFZ
bXBsWTNRZ1lXeDBaWEp1DQpZWFJwZG1VZ2JtRnRaU3dnZEdobElISm1Zemd5TWx4d1lYSU5DajRn
WEhCaGNnMEtQaUFnSUNCdVlXMWxJR052DQpibk4wY21GcGJuUWdUVlZUVkNCaVpTQmhjSEJzYVdW
a0lIUnZJSFJvWlNCaGRIUnlhV0oxZEdVZ2IyWWdkSGx3DQpaU0JjY0dGeURRbytJRVZ0WVdsc1FX
UmtjbVZ6YzF4d1lYSU5DajRnWEhCaGNnMEtQaUFnSUNCcGJpQjBhR1VnDQpjM1ZpYW1WamRDQmth
WE4wYVc1bmRXbHphR1ZrSUc1aGJXVXVYSEJoY2cwS1BpQmNjR0Z5RFFvK0lDQmNjR0Z5DQpEUW8r
SUZ4d1lYSU5DajRnVTNWd2NHOXpaUzl6ZFdkblpYTjBJSFJvWVhRZ2RHaGxJR2x1ZEdWdVpHVmtJ
RzFsDQpZVzVwYm1jZ2FYTTZYSEJoY2cwS1BpQmNjR0Z5RFFvK0lDQmNjR0Z5RFFvK0lGeHdZWElO
Q2o0Z0lDQWdWMmhsDQpiaUJ5Wm1NNE1qSWdibUZ0WlhNZ1lYSmxJR052Ym5OMGNtRnBibVZrTENC
aWRYUWdkR2hsSUdObGNuUnBabWxqDQpZWFJsSUdSdlpYTWdibTkwWEhCaGNnMEtQaUJjY0dGeURR
bytJQ0FnSUdsdVkyeDFaR1VnWVc0Z2NtWmpPREl5DQpUbUZ0WlNCcGJpQmhJSE4xWW1wbFkzUWdZ
V3gwWlhKdVlYUnBkbVVnYm1GdFpTQmxlSFJsYm5OcGIyNHNJSFJvDQpaU0JjY0dGeURRbytJSEpt
WXpneU1seHdZWElOQ2o0Z1hIQmhjZzBLUGlBZ0lDQnVZVzFsSUdOdmJuTjBjbUZwDQpiblFnVFZW
VFZDQmlaU0JoY0hCc2FXVmtJSFJ2SUhSb1pTQmhkSFJ5YVdKMWRHVWdiMllnZEhsd1pTQmNjR0Z5
DQpEUW8rSUVWdFlXbHNRV1JrY21WemMxeHdZWElOQ2o0Z1hIQmhjZzBLUGlBZ0lDQnBiaUIwYUdV
Z2MzVmlhbVZqDQpkQ0JrYVhOMGFXNW5kV2x6YUdWa0lHNWhiV1V1WEhCaGNnMEtQaUJjY0dGeURR
bytJQ0JjY0dGeURRbytJRnh3DQpZWElOQ2o0Z0lGeHdZWElOQ2o0Z1hIQmhjZzBLUGlCU1lYUnBi
MjVoYkdVNlhIQmhjZzBLUGlCY2NHRnlEUW8rDQpJRmRvZVNCM2IzVnNaQ0IwYUdVZ1kyOXVjM1J5
WVdsdWRDQk9UMVFnWVhCd2JIa2dkRzhnUlcxaGFXeEJaR1J5DQpaWE56SUdwMWMzUWdZbVZqWVhW
elpTQjBhR1Z5WlNCY2NHRnlEUW8rSUdselhIQmhjZzBLUGlCaElGTjFZbXBCDQpiSFJPWVcxbElH
VjRkR1Z1YzJsdmJpQjNhWFJvSUdVdVp5NGdhblZ6ZENCemIyMWxJSFZ1Y21Wc1lYUmxaQ0J2DQpk
R2hsY2lCdVlXMWxJRnh3WVhJTkNqNGdZMjl0Y0c5dVpXNTBJSEJ5WlhObGJuUS9YSEJoY2cwS1Bp
QmNjR0Z5DQpEUW8rSUNCY2NHRnlEUW8rSUZ4d1lYSU5DajRnTDFOMFpXWmhibHh3WVhJTkNqNGdY
SEJoY2cwS1BpQWdYSEJoDQpjZzBLUGlCY2NHRnlEUXA5DQotLS0tPV9OZXh0UGFydF9TVEpfMzg4
NDU3NzYuMTEzOTE5OTg1LS0NCg0KoIILHjCCA6YwggKOoAMCAQICBD9jj6kwDQYJKoZIhvcNAQEF
BQAwMTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQwHhcN
MDQwMzE4MTM1OTIzWhcNMDQwOTE4MTQyOTIzWjBZMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50
cnVzdDEQMA4GA1UECxMHUiBhbmQgRDEmMA4GA1UEBRMHMTYxNjY3MTAUBgNVBAMTDVNoYXJvbiBC
b2V5ZW4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAK3LTAUNDH//zxzhL9JK8tJQEjbvYEo4
uKUQXAuZ0sTkMIgJsFYBqgq4nTY3T0ks335ZAlQKnBHJEiIZhFKdeac1dwP0wzzvFzMpmARgkmyA
Ne+7A45zBBoRPuUdfnGiDlcC9WZcBU1JE+VkQmGuvfJ5GKEVAdDcYHU5h4GWmytPAgMBAAGjggEg
MIIBHDALBgNVHQ8EBAMCB4AwKwYDVR0QBCQwIoAPMjAwNDAzMTgxMzU5MjNagQ8yMDA0MDcyNTA5
MjkyM1owJAYDVR0RBB0wG4EZc2hhcm9uLmJvZXllbkBlbnRydXN0LmNvbTBUBgNVHR8ETTBLMEmg
R6BFpEMwQTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQx
DjAMBgNVBAMTBUNSTDI4MB8GA1UdIwQYMBaAFPPwLCjmOac0GauakaimZkCSnOJxMB0GA1UdDgQW
BBRLwMRUvNu/y0W8q9Sv5AI7I56SNDAJBgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY3LjAD
AgSwMA0GCSqGSIb3DQEBBQUAA4IBAQA5AmaD0OMLcM5wpPSMY2jsOWN6Y7ruyM2ZX31yG9qtrnnU
qwPcVMssLU3LSw6xLKQJ8kgwXejAuo1gGyCzgMxTl8LyF5TXCY6ZXp7cNa0vquSwg1hiNbLhyqwE
uBho/CRgSfkrZ/9mfEJ4s4REyMa3q1CR44QlBbFNZSmfRWtDsZyWMsTxFBb9iqws1r3rtHVXmuOm
hVziw/qx9oujmzPJwe1q1TQahcKmabDggSjMU1M1ylkUCI3+PVJSzPQc7AwZnKjSE7LWW07t2JMF
CFUrAi5o4/Ua9pJr7jC5zXQ/Xyf/PAmPxkx7StmbXzKHRMkFxlMr1Q3OmjzzlnR3sNPbMIIDdzCC
Al+gAwIBAgIEP2OLWzANBgkqhkiG9w0BAQUFADAxMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50
cnVzdDEQMA4GA1UECxMHUiBhbmQgRDAeFw0wNDAyMTkxMjI2MTJaFw0wNDA4MTkxMjU2MTJaMFkx
CzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMSYwDgYDVQQF
EwcxNjE2NjcxMBQGA1UEAxMNU2hhcm9uIEJvZXllbjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
gYEArJeYhKIoggxfZueFCUpclFz9Me0aKbCfR/ZU1rpQXGM5gPJthGQyfb5OtMjVX3f9LHimUA+T
KTlCwjLtLleB2YxZhKEuoEj4ccTipUlLdzWRqESANT7MZXo7uRy+0spsJYuL68txOA8a4sLbmcDS
FssiQWpFn8bq0p+MoSL0cOcCAwEAAaOB8jCB7zALBgNVHQ8EBAMCBSAwJAYDVR0RBB0wG4EZc2hh
cm9uLmJvZXllbkBlbnRydXN0LmNvbTBUBgNVHR8ETTBLMEmgR6BFpEMwQTELMAkGA1UEBhMCQ0Ex
EDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQxDjAMBgNVBAMTBUNSTDI3MB8GA1Ud
IwQYMBaAFPPwLCjmOac0GauakaimZkCSnOJxMB0GA1UdDgQWBBR1jmOMGJBhHCpWex5f8NjcRAw3
ETAJBgNVHRMEAjAAMBkGCSqGSIb2fQdBAAQMMAobBFY3LjADAgSwMA0GCSqGSIb3DQEBBQUAA4IB
AQAsfe6ZE2k7XMGR+UKtf72THgEWw1OBG5M7a+YiE8V3pPEotm02/0N7nNaKT/j0q0BJgj2OAW8a
nV56WMXHGvdb24x/pXuEAMC+Rn57JiyIy9IkgH5ijoK3Iqlp9QIzEYprDIee67o78efGlfkSF4R2
zXEOZyxoESIdQTduaOL96gKftC198GNrOthzKxUTLnX8g9ltObBLptrSxy/UY7O0SP4yX++bZamU
E1FOMTlW50hZauok4i2R3qViLskxd4xLdmp5VL3c77Uf2xxyDuV9iR2rlcUwTtFeC56UadaDK+7v
gSte6upddEyhT9witYNBJ1Bat24uco+PC/OxkkJ/MIID9TCCAt2gAwIBAgIEMkiqIDANBgkqhkiG
9w0BAQUFADAxMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQg
RDAeFw0wMjA0MTcwMjIwMjZaFw0yMjA0MTcwMjUwMjZaMDExCzAJBgNVBAYTAkNBMRAwDgYDVQQK
EwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAvIeIjfoD5D86sD8CehB+kVhYJTL+VuaUZiVijGevUTlnUAwy1WpOYVpFCa8VK116TJ+o99ax
N1jMbsVBYfRzFk9SWl4iAH+PyJ1S6D5Yl593KjHPhBCfdD0v9KoPqXhCwRlkvupreNlFx3FFk2Uf
5jG/i9SCP925OXbz3wod2mdIu8ueNWgTmA2XAOBdHZg6HYKo50BWUIgtRwFvzbh1J57+gNdHxMYL
Zmvj5saS1mDTSibkPH/AY+D+xAozRmyOYa4SY2HVfZSM2SP7MkuVtKp17pzhwicoWAGKXrKeDRWD
YeZBTJjHoNP/SXKdpSzY7rV8GPrfWFoogc4350VbowIDAQABo4IBEzCCAQ8wEQYJYIZIAYb4QgEB
BAQDAgAHMFMGA1UdHwRMMEowSKBGoESkQjBAMQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVz
dDEQMA4GA1UECxMHUiBhbmQgRDENMAsGA1UEAxMEQ1JMMTArBgNVHRAEJDAigA8yMDAyMDQxNzAy
MjAyNlqBDzIwMjIwNDE3MDI1MDI2WjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgwFoAU8/AsKOY5pzQZ
q5qRqKZmQJKc4nEwHQYDVR0OBBYEFPPwLCjmOac0GauakaimZkCSnOJxMAwGA1UdEwQFMAMBAf8w
HQYJKoZIhvZ9B0EABBAwDhsIVjYuMDo0LjADAgSQMA0GCSqGSIb3DQEBBQUAA4IBAQCAPnm1Rpn5
ya5kBLFpckRtw+XuY/G5m6uQH9hVXgechp+i6/tXlYjQ8ccnJy1HcOmPS718LkG4drxBfrhjO9aT
udv+TNIMR9izay796hsBk7raBpYtxavOEjxb8jfp+EelztgcSZo737mYzcrr9pDjzJldsriCzPDU
/N052R+RJ4Rs/0IiuWzIVH7y99S9O+rG14PjEKNQhA39gTwg9iMBtQoksDfKu09UCaFsE7aYUC8e
E0wzki4G+Dl5RKE57MGaYAh+cccmyPR6Xw/gl8Yo3YGhOWz3qatAhbbplACm9LSmduMSLXQybke6
cq5JUb8c9VMzi9cIiv6Hbf1/xObPMYICZTCCAmECAQEwOTAxMQswCQYDVQQGEwJDQTEQMA4GA1UE
ChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRAIEP2OPqTAJBgUrDgMCGgUAoIIBgjAYBgkqhkiG
9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDA1MDYxNTM5MjBaMCMGCSqGSIb3
DQEJBDEWBBRNKF5VSEcbYDPUX4MukmkegrypwDCCASEGCSqGSIb3DQEJDzGCARIwggEOMAsGCWCG
SAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZIAWUDBAECMA8GCSqGSIb2fQdCCgICAIAwDgYIKoZI
hvcNAwICAgCAMAoGCCqGSIb3DQMHMA0GCysGAQQBgTwHAQECMA4GCSqGSIb2fQdCCgIBKDANBggq
hkiG9w0DAgIBKDAHBgUrDgMCBzAHBgUrDgMCGjAKBggqhkiG9w0CBTALBgkqhkiG9w0BAQEwCwYJ
KoZIhvcNAQEHMAkGByqGSM44BAEwCQYHKoZIzj0CATALBgkqhkiG9w0BAQUwCwYJKoZIhvcNAQEE
MAkGByqGSM44BAMwCQYHKoZIzj0EATAMBgoqhkiG9w0BCQ8BMA0GCSqGSIb3DQEBAQUABIGAZ/zd
adL4+m/1R8CArZD6nEd5eM7x40yFtakYs7Yn8glTJb4smp4FKaPH1e7LLaQ1GtVOz8f4Wc10K6uc
umtMuGJSlQDBLWg3Hpl+lwH2o0AbzHJDNP3juK3dY+5LQo4DCqykJvy23TYlGeTwQv8EScyqylQy
GP8sH0tdsM7ljN4=



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46FYMPU077271; Thu, 6 May 2004 08:34:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46FYMoQ077270; Thu, 6 May 2004 08:34:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxssm1.entrust.com (sottmxssm1.entrust.com [216.191.252.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46FYKwG077250 for <[e-mail]>; Thu, 6 May 2004 08:34:21 -0700 (PDT) (envelope-from [e-mail])
Received: from SOTTMXS01.entrust.com ([10.4.61.7]) by sottmxssm1.entrust.com (Switch-3.1.4/Switch-3.1.0) with ESMTP id i46FhWm9029268 for <[e-mail]>; Thu, 6 May 2004 11:43:32 -0400
Received: by sottmxs01.entrust.com with Internet Mail Service (5.5.2657.72) id <KM64ZNYG>; Thu, 6 May 2004 11:34:16 -0400
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: [e-mail]
Subject: RE: Cross certificate format
Date: Thu, 6 May 2004 11:34:16 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I'd also like to clarify that the constraints that input to the path
validation process (e.g. initial-policy-mapping-inhibit,
initial-explicit-policy etc) are not tied necessarily to the trust anchor
but are tied to an instance of path validation conducted by the relying
party. It may be the relying party and not CA who happens to be the trust
anchor that determines these constraints. They are just additional inputs to
the process, as is the trust anchor public key. The same validation engine
may have different constraints on instances of path validation that use the
same trust anchor public key. Also, the same set of constraints can apply to
instances of validation that use different trust anchors. Different users,
different apps and even different transactions can have different
constraints even though they may happen to use the same trust anchor. While
it is true that including some extensions in a self-signed might be one way
to convey constraints that could then be extracted and provided as the
relevant inputs to the validation process, this is certainly not the only
way to convey initialization constraint values for a RP. Also, I believe it
is a very limiting way because then the constraints are tied to all
validations that occur with that key by all RPs (assuming all RPs used that
scheme to initialize their path validation variables). The mechanisms that
determine those inputs to the path validation process (including which trust
anchor public key to use, process are outside the scope of X.509. X.509
provides the mechanism (path validation variable initialization) to set the
constraints once the RP has determined what they are to be. 

On the nameConstraints issue, there is work underway in X.509 that will add
one more input to the path validation process to enable nameConstraints to
be imposed at initialization time just as other constraints can already.
Similar to the other constraints, no single value of initialization
constraints is tied necessarily to all uses of a trust anchor public key.  

On the earlier discussion of processing extensions in self-signed certs. I
believe X.509 and 3280 are completely consistent here in pointing out that
the self-signed cert is not part of the path (but may be a convenient way
for a CA to convey its public key). See clause 8.1.5 of X.509 for the
relevant text "For purposes of path validation, self-issued certificates of
type a) are verified with the public key contained in them, and if they are
encountered in the path, they shall be ignored." As a result of Defect
Report 285, that same point is the basic certificate checks in the path
processing alogithm in X.509. In the first paragraph of 10.5.1, you'll find
the sentence "Self-signed certificates, if encountered in the path are
ignored."

As for the checking of whether a self-signed cert has basic constraints with
CA set to TRUE etc, that is part of the checking that could be done to place
trust in the fact that certified key should be used as an input to the path
validation process. However, because X.509 does not mandate any scheme for
conveying these keys to users, it obviously doesn't mandate any checks on
those schemes. Any checking along these lines is outside the scope of the
path validation process because it would be done before the process is
initialized with that key.

Sorry for the lengthy message
Sharon


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Steve Hanna
Sent: Wednesday, May 05, 2004 5:26 PM
To: Tom Gindin
Cc: Santosh Chokhani; [e-mail]
Subject: Re: Cross certificate format


See section 6.2 of RFC 3280, which says:

    ...  An implementation that supports multiple trust anchors
    MAY augment the algorithm presented in section 6.1 to further limit
    the set of valid certification paths which begin with a particular
    trust anchor.  For example, an implementation MAY modify the
    algorithm to apply name constraints to a specific trust anchor during
    the initialization phase, or the application MAY require the presence
    of a particular alternative name form in the end entity certificate,
    or the application MAY impose requirements on application-specific
    extensions.  Thus, the path validation algorithm presented in section
    6.1 defines the minimum conditions for a path to be considered valid.

There's no need to change RFC 3280 to allow
path validation implementations to apply
name constraints to trust anchors. That's
explicitly discussed in this section of the RFC.

Thanks,

Steve

Tom Gindin wrote:
>         Santosh:
> 
>         Of course, defining a trust anchor implies that the RP trusts 
> the
> anchor's public key as an issuer for at least some purposes.  RFC 3280, in

> the parts of section 6.1.2 I cited, appears to forbid those state 
> variables from being set from information defined by the RP or stored with

> the trust anchor.  This is consistent with its statements in 6.1.1 d which

> permit self-signed certificates but say nothing about other CA 
> certificates.  As is probably clear to everyone reading this thread, I 
> think that this is not an ideal set of suggestions.
>         The current standard does contain some constraints on the trust 
> anchor (notably inhibit-policy-mapping), but neither name constraints nor 
> basic constraints.  I consider this an anomaly.  If I had free rein in 
> rewording pieces of RFC 3280 section 6.1, I would change this wording to 
> allow CA certificates along with self-signed ones as anchors and create 
> extra optional (and optional to support) fields to be set from the trust 
> anchor.
>         I don't think that this is particularly inconsistent with general 
> security principles, or with any part of X.509 with which I am familiar. 
> It does represent an extension of RFC 3280 section 6, and it is only 
> backward compatible with it, so it may be out of scope.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[e-mail]>
> Sent by: [e-mail]
> 05/01/2004 06:46 PM
> 
>  
>         To:     <[e-mail]>
>         cc: 
>         Subject:        RE: Cross certificate format
> 
> 
> 
> 
> Tom:
> 
> The standard does not require you to check how you initialize the
> variables.
> You can get these from the cross certificate or from some configuration.
> 
> The basic point is that you trust the public key.  How you constrain 
> it is not address by the standard, where as if the same certificate 
> appeared in a path, you have to apply the constraints or be not 
> compliant with the standard.
> 
> You obviously do not believe in re-incarnation.  Just kidding......
> 
> -----Original Message-----
> From: Tom Gindin [mailto:[e-mail]]
> Sent: Saturday, May 01, 2004 6:31 PM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: RE: Cross certificate format
> 
> 
>         Santosh:
> 
>         It is well known that trust in a trust anchor can be defined 
> in a
> variety of ways.  However, there is every reason to think that an RP may 
> constrain that trust and that the constraints he may apply include those 
> which an issuer CA may apply to a subordinate one. The wording of RFC 3280

> 
> section 6.2's first paragraph is an example of this.
>         My comments about the meaning of a trust anchor are not purely
> theoretical.  If a cross certificate is used to represent a trust anchor, 
> the variables permitted_subtrees (RFC 3280 6.1.2 b) and excluded_subtrees 
> (RFC 3280 6.1.2 c) could easily be set from the contents of a 
> NameConstraints extension, and the variable max_path_length (RFC 3280 
> 6.1.2 k) from the contents of a BasicConstraints extension.  In RFC 3280 
> today, these variables are set to constants (although that interpretation 
> is not absolutely clear for permitted_subtrees).  In fact, they are three 
> of the four variables which are set to constants during initialization.
>         If permitted subtrees were set to a list of attributes, the 
> validation process would fail if the anchor CA or a CA it certified went 
> beyond the restrictions of those attributes.  Likewise, if the excluded 
> subtrees were set to a list of attributes, the validation process would 
> fail if the anchor CA or a CA it certified went used values matching any 
> of those attributes.  I do not believe that I am arguing against Galileo.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[e-mail]>
> Sent by: [e-mail]
> 04/29/2004 11:12 PM
> 
>  
>         To:     <[e-mail]>
>         cc: 
>         Subject:        RE: Cross certificate format
> 
> 
> 
> 
> Tom:
> 
> The basic point (at the risk of repeating myself) is that a CA 
> certificate or a self-signed certificate can be used as a means to 
> provide trust anchor information.  In that case, there is no need to 
> check signature or anything.
> 
> But, when the CA certificate is a certificate in the certificate path,
> X.509
> logic kicks in.
> 
> This is consistent with X.509, 3280 and general security principles 
> since the trust in a trust anchor can be derived through any number of 
> means.
> 
> If you do not agree, feel free to argue against the definitions and
> Galileo
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]
> On
> Behalf Of Tom Gindin
> Sent: Thursday, April 29, 2004 8:43 PM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: RE: Cross certificate format
> 
> 
> 
>         Santosh:
> 
>         I don't think that a CA certificate and a trust anchor are as 
> much
> 
> 
> different things as different uses for the same thing.  They are both
> identifiers of issuers which bind a public key to an issuer name, and it 
> is perfectly appropriate for any CA certificate to represent a trust 
> anchor.  I also do not see why such things as name constraints on a trust 
> anchor are inappropriate.  It is perfectly true that verifying a trust 
> anchor's certificate, when issued by another CA (who may not be trusted) 
> is a pointless operation.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[e-mail]>
> Sent by: [e-mail]
> 04/27/2004 09:14 AM
> 
>  
>         To:     <[e-mail]>
>         cc: 
>         Subject:        RE: Cross certificate format
> 
> 
> 
> 
> Tom:
> 
> My point is that even if the trust anchor is a self-signed 
> certificate,
> all
> you need to do is extract the required information.  There is no need to
> examine anything.
> 
> Cross certificate and trust anchor are very different things.  An 
> element
> of
> the cross certificate pair is nothing but an intermediate CA certificate 
> in
> a certification path.
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]
> On
> Behalf Of Tom Gindin
> Sent: Tuesday, April 27, 2004 7:33 AM
> To: Santosh Chokhani
> Cc: [e-mail]; [e-mail]
> Subject: RE: Cross certificate format
> 
> 
> 
>         Santosh:
> 
>         Of course, you are right that RFC 3280 6.1.1 d permits trust
> anchor information to be provided outside a certificate.  If it is so, no 
> checks of the sort I indicated can be performed.  It also says that it can

> 
> 
> 
> be provided as "a self-signed certificate", with no further 
> qualification.
> 
> 
> 
>  I do think it is somewhat odd that a self-signed certificate with
> KeyUsage set to typical EE values would be considered a valid issuer as a 
> trust anchor while a cross certificate would not.  You can always extract 
> the needed anchor information from a cross-certificate, of course.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[e-mail]>
> Sent by: [e-mail]
> 04/26/2004 08:51 AM
> 
>  
>         To:     <[e-mail]>
>         cc: 
>         Subject:        RE: Cross certificate format
> 
> 
> 
> 
> Tom:
> 
> My reading of 3280 and X.509 is that a trust anchor need not even be a 
> certificate.  Thus, no checks need to be performed on a trust anchor 
> at all. You get the DN, public key, algorithm OID, and parameters (if 
> applicable) from a trust anchor.  Any checks are gratuitous and not 
> required by either standard.
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]
> On
> Behalf Of Tom Gindin
> Sent: Sunday, April 25, 2004 7:06 PM
> To: Jean-Marc Desperrier
> Cc: [e-mail]
> Subject: Re: Cross certificate format
> 
> 
> 
>         Jean-Marc:
> 
>         RFC 3280 doesn't say that anywhere.  It does say that you 
> don't
> need to validate the trust anchor as part of the path, but it isn't clear 
> from the text that a v1 certificate is acceptable as a trust anchor - and 
> it certainly isn't clear that a v1 certificate is acceptable as an issuer 
> if it is a trust anchor while a v3 certificate with KeyUsage= { 
> DigitalSignature, keyEncipherment } is not acceptable as an issuer even if

> 
> 
> 
> 
> it is a trust anchor.
>         I believe that the correct rules for versions are something 
> like
> the following: a certificate issued by a trust anchor which is represented

> 
> 
> 
> 
> by a certificate is verifiable if the anchor certificate is either a 
> v1
> certificate or a v3 certificate with the CA flag present in the 
> basicConstraints extension.  If the anchor certificate is a v3 certificate

> 
> 
> 
> 
> with the KeyUsage extension present, it is only a valid issuer 
> certificate
> 
> 
> 
> 
> if keyCertSign is set.
> 
>         Tom Gindin
> 
> 
> 
> 
> 
> Jean-Marc Desperrier <[e-mail]>
> Sent by: [e-mail]
> 04/21/2004 03:42 PM
> 
>  
>         To:     [e-mail]
>         cc: 
>         Subject:        Re: Cross certificate format
> 
> 
> 
> 
> Tom Gindin wrote:
> 
> 
>>       RFC 3280 does not support the use of v1 self-signed 
>>certificates,
> 
> 
>>which contain no extensions at all (see the text of RFC 3280's
>>basicConstraints section).  However, a number of public CA's still have 
>>them.
>>
>>
> 
> Applications implementing the path validation algorithm of RFC3280 
> MUST
> accept them when they are used as trust anchors.
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46El2Ww073491; Thu, 6 May 2004 07:47:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46El28O073490; Thu, 6 May 2004 07:47:02 -0700 (PDT)
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.9) with ESMTP id i46El0NA073464 for <[e-mail]>; Thu, 6 May 2004 07:47:01 -0700 (PDT) (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 QAA19798; Thu, 6 May 2004 16:56:12 +0200
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 QAA13602; Thu, 6 May 2004 16:42:58 +0200
Message-ID: <[e-mail]>
Date: Thu, 06 May 2004 16:47:10 +0200
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: Trevor Freeman <[e-mail]>
CC: [e-mail]
Subject: Re: FW: scvp
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>

Trevor,

> Hi Denis,

> There is no mandate in 3379 that a validation policy must be expressed
> with a single value. 

"The protocol MUST allow the client to include these policy dependant 
parameters in the DPV request; however, it is expected that most clients 
will simply reference a validation policy."

The "however" mandates that a validation policy must also be expressed
with a single value.

I do not understand your resistance against a single value.
The following strcture could accomodate both approaches:

    ValPolicy  ::=  SEQUENCE  {
         valPolId      OBJECT IDENTIFIER,
         valPolValue   OCTET STRING  OPTIONAL }

The valPolValue would be dependent upon the OID of the valPolId and the 
structure of the valPolValue in the case of the "default policy" would be 
defined in the current document.

Other structures could be defined in other documents.

Denis

 > for a given application or accept the DPV server's default
 > validation policy.


> It is not clear that is any value is doing so since
> it only raised more ambiguity. This is well trod turf by many groups who
> have debated the merits of providing suits vs. "al a carte" combinations
> of inputs and the broader consensus is for a "al a carte".
> Trevor
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Tuesday, May 04, 2004 3:15 AM
> To: Trevor Freeman
> Cc: [e-mail]
> Subject: Re: FW: scvp
> 
> Trevor,
> 
> 
>>Hi Denis,
>>
>>3379 does not require that the validation policy be specified in a
>>single value. 
> 
> 
> You are playing with words. The text says:
> "most clients will simply reference a validation policy"
> 
> This means that validation policies can be referenced and thus
> parameters do 
> not need to be defined through this interface.
> 
> A simple and good reference is an OID.
> 
> 
>>With SCVP14 a client can accept the default of the SCVP
>>server or specify a set of parameters which constitutes its validation
>>policy. That is consistent with the requirements of 3379.
> 
> 
> The specification of the set of parameters should be done through a 
> different interface. This different interface can then return an OID 
> Whatever this additional interface can be, it will never be rich enough
> to 
> pass all the details of the validation policy. Thus OIDs can also be
> defined 
> not using this additional interface.
> 
> Denis
> 
> 
>>Trevor
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]] 
>>Sent: Thursday, April 29, 2004 3:54 AM
>>To: Trevor Freeman
>>Cc: [e-mail]
>>Subject: Re: FW: scvp
>>
>>Trevor,
>>
>>
>>
>>>Hi Denis,
>>
>>
>>>Can you please be more specific how you think SCVP 14 does not comply
>>>with 3379.
>>>
>>>I can find no section in 3379 where is there a requirement that a
>>>validation policy MUST be represented as an OID. 
>>
>>
>>There cannot be a requirement with such a level of detail, but the
> 
> text
> 
>>states:
>>
>>    The protocol MUST allow the client to include
>>    these policy dependant parameters in the DPV request; however, it
> 
> is
> 
>>    expected that most clients will simply reference a validation
> 
> policy
> 
>>    for a given application or accept the DPV server's default
>>validation
>>    policy.
>>
>>A simple reference is an OID.
>>
>>FYI, I do not expect to use the "default validation policy".
>>
>>Denis
>>
>>
>>
>>
>>>Given hiding the detail of what a policy is within an OID simply opens
>>>the rat hole of what change to the policy constitutes a change to the
>>>OID, it is less ambiguous to refer to the primary data. Once you are
>>
>>in
>>
>>
>>>the business of managing state on a client, then there is negligible
>>>cost increase incurred in managing several data points vs. a singe
>>
>>data
>>
>>
>>>point.
>>>
>>>Trevor
>>>
>>>-----Original Message-----
>>>From: Denis Pinkas [mailto:[e-mail]] 
>>>Sent: Tuesday, April 27, 2004 11:01 AM
>>>To: Trevor Freeman
>>>Cc: [e-mail]
>>>Subject: Re: FW: scvp
>>>
>>>Trevor,
>>>
>>>
>>>
>>>
>>>>HI Denis,
>>>>In SCVP13, the concept of validation policy was not completely in
>>>>alignment  with 3379 definition. 
>>>
>>>
>>>Well, it is different and this is a major problem.
>>>
>>>
>>>
>>>
>>>>It also blurred the distinction between
>>>>validation policy and validation algorithm. 
>>>
>>>
>>>This is also a majo problem.
>>>
>>>
>>>
>>>
>>>>Therefore I have defined
>>>>what each is in SCVP 14 and aligned the structures accordingly.
>>>>Section 1.3 has the following.
>>>>"In SCVP, the validation policy comprises of an algorithm for
>>>>certificate path processing and the input parameters to the
>>>
>>>algorithm."
>>>
>>>This does not comply with RFC 3379.
>>>
>>>
>>>
>>>
>>>>Therefore trust anchors are an input into the algorithm  and
>>>
> therefore
> 
>>>>separate.
>>>
>>>
>>>Therefore I do not follow you.
>>>
>>>From an interface point of view the simplest validation policy is
>>>defined 
>>>by an OID where all the parameters necessary to perform the validation
>>>check 
>>>are "behind" the OID. There is no need to provide any parameter
>>
>>through
>>
>>
>>>the 
>>>interface.
>>>
>>>When there are some parameters, then they are specific to the
>>
>>validation
>>
>>
>>>policy. I have no problem to provide specific parameters for what is
>>>called 
>>>the "default validation policy" which is only a particular validation
>>>policy 
>>>among many others.
>>>
>>>Simple clients will be unable to pass any parameter but will know
>>
>>which
>>
>>
>>>OIDs 
>>>(for the validation policy) are appropriate for their applications.
>>>
>>>Denis
>>>
>>>
>>>
>>>
>>>>This is in alignment with 3379s definition of validation policy.
>>>>
>>>>Trevor
>>>>
>>>>-----Original Message-----
>>>>From: Denis Pinkas [mailto:[e-mail]] 
>>>>Sent: Monday, April 26, 2004 1:09 AM
>>>>To: Peter Sylvester
>>>>Cc: [e-mail]; Trevor Freeman
>>>>Subject: Re: FW: scvp
>>>>
>>>>Peter and Trevor,
>>>>
>>>>I have major problems too.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>in version 13 the syntax for a Query has been changed from
>>>>>
>>>>>Query ::= SEQUENCE { 
>>>>>    queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference, 
>>>>>    checks                CertChecks, 
>>>>>    wantBack              WantBack, 
>>>>>    serverContextInfo [0] OCTET STRING OPTIONAL, 
>>>>>    valPolicy         [1] ValidationPolicy OPTIONAL, 
>>>>>    validityTime      [2] GeneralizedTime OPTIONAL, 
>>>>>    trustAnchors      [3] TrustAnchors OPTIONAL, 
>>>>>    intermediateCerts [4] CertBundle OPTIONAL, 
>>>>>    revInfos          [5] RevocationInfos OPTIONAL, 
>>>>>    queryExtensions   [6] Extensions OPTIONAL } 
>>>>
>>>>
>>>>In this structure trustAnchors was more or less an alternative to
>>>>valPolicy.
>>>>
>>>>In fact, IF the valPolicy is the default policy, THEN additional
>>>>parameters 
>>>>MUST be provided. So the structure below does not fit as well.
>>>>
>>>>This leads to have the two following elements:
>>>>
>>>>   valPolicy               ValidationPolicy,
>>>>   paramsDefValPolicy      ParamsDefValPolicy OPTIONAL,
>>>>
>>>>where the first one is mandatory and the second one optional.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>to  
>>>>>
>>>>> Query ::= SEQUENCE { 
>>>>>   queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>>>
>>>>
>>>>>   checks                  CertChecks, 
>>>>>   wantBack                WantBack, 
>>>>>   requestRefHash          BOOLEAN DEFAULT TRUE, 
>>>>>   includePolResponce      BOOLEAN DEFAULT FALSE, 
>>>>>   inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>>>>   requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>>>>   ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>>>>   valAlgorithm            ValidationAlgorithm, 
>>>>>   serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>>>>   validityTime        [1] GeneralizedTime OPTIONAL, 
>>>>>   trustAnchors        [2] TrustAnchors OPTIONAL, 
>>>>>   intermediateCerts   [3] CertBundle OPTIONAL, 
>>>>>   revInfos            [4] RevocationInfos OPTIONAL, 
>>>>>   queryExtensions     [5] Extensions OPTIONAL } 
>>>>
>>>>
>>>>I would thus propose to have something like:
>>>>
>>>>Query ::= SEQUENCE {
>>>>       queriedCerts            SEQUENCE SIZE (1..MAX) OF
>>>>CertReference,
>>>>       checks                  CertChecks,
>>>>       wantBack                WantBack,
>>>>       requestRefHash          BOOLEAN DEFAULT TRUE,
>>>>       serverContextInfo       OCTET STRING OPTIONAL,
>>>>       validityTime            GeneralizedTime OPTIONAL,
>>>>       includePolResponse      BOOLEAN DEFAULT FALSE,
>>>>       valPolicy               ValidationPolicy,
>>>>       paramsDefValPolicy  [0] ParamsDefValPolicy OPTIONAL,
>>>>       intermediateCerts   [1] CertBundle OPTIONAL,
>>>>       revInfos            [2] RevocationInfos OPTIONAL,
>>>>       queryExtensions     [3] Extensions OPTIONAL }
>>>>
>>>>and then something like:
>>>>
>>>>  ParamsDefValPolicy :: = SEQUENCE {
>>>>      trustAnchors                  TrustAnchors,
>>>>      endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER
>>>>OPTIONAL,
>>>>      inhibitPolMap                 BOOLEAN DEFAULT FALSE,
>>>>      caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER
>>>>OPTIONAL }
>>>>
>>>>Denis
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>I am not sure whether I am the only person unable to construct a
>>>>
>>>>parser.
>>>>
>>>>
>>>>
>>>>
>>>>>in version 14 an aditional flag has been added which is not
>>>>
> available
> 
>>>>in the
>>>>
>>>>
>>>>
>>>>
>>>>>Chapter 9. Is the isCA flag an orthogonal attribut to other
>>>>
>>validation
>>
>>
>>>>>algorithms, or just to some of them, e.g,. the default name matching
>>>>
>>>>one? 
>>>>
>>>>
>>>>
>>>>
>>>>> Query ::= SEQUENCE { 
>>>>>   queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>>>
>>>>
>>>>>   checks                  CertChecks, 
>>>>>   wantBack                WantBack, 
>>>>>   requestRefHash          BOOLEAN DEFAULT TRUE, 
>>>>>   includePolResponce      BOOLEAN DEFAULT FALSE, 
>>>>>   inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>>>>   requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>>>>   ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>>>>   isCA                    BOOLEAN DEFAULT FALSE, 
>>>>>   valAlgorithm            ValidationAlgorithm, 
>>>>>   serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>>>>   validityTime        [1] GeneralizedTime OPTIONAL, 
>>>>>   trustAnchors        [2] TrustAnchors OPTIONAL, 
>>>>>   intermediateCerts   [3] CertBundle OPTIONAL, 
>>>>>   revInfos            [4] RevocationInfos OPTIONAL, 
>>>>>   keyUsage            [5] KeyUsage OPTIONAL, 
>>>>>   extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
>>>>>   queryExtensions     [7] Extensions OPTIONAL  
>>>>>   producedAt          [8] GeneralizedTime OPTIONAL} 
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46Ed695072830; Thu, 6 May 2004 07:39:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46Ed6gs072829; Thu, 6 May 2004 07:39:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46Ed5kc072823 for <[e-mail]>; Thu, 6 May 2004 07:39:05 -0700 (PDT) (envelope-from [e-mail])
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i46EbosT003674 for <[e-mail]>; Thu, 6 May 2004 08:37:50 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <[e-mail]> for [e-mail]; Thu, 06 May 2004 10:39:07 -0400 (EDT)
Received: from sun.com (dhcp-ubur02-75-154.East.Sun.COM [129.148.75.154]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]>; Thu, 06 May 2004 10:39:07 -0400 (EDT)
Date: Thu, 06 May 2004 10:35:08 -0400
From: Steve Hanna <[e-mail]>
Subject: Re: RFC 3280 bug in name constraints
In-reply-to:  <[e-mail]>
To: Stefan Santesson <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=------------ms090804020804070103010908
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20031111
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>

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

I agree. In fact, I don't see why you wouldn't
apply name constraints to an EmailAddress attribute
in a subject DN even if there *is* an rfc822Name
in a subject alternative name. I suggest that
the text be revised to say:

    An rfc822 name constraint MUST be applied to an
    attribute of type EmailAddress in the subject
    distinguished name.

However, I'm willing to back down on this if
people feel it's too strict. My concern is that
a certificate with an email address in the
subject DN prohibited by name constraints will
be allowed because it also contains a permissible
email address in the subject alternative name.
I suspect many applications will not understand
this and will accept the email address in the
subject DN. In fact, RFC 2632 and its successor
don't contain any warning about this.

Thanks,

Steve

Stefan Santesson wrote:
> If someone is keeping record of bugs for future update of RFC 3280 I 
> have a small one to file about name constraints.
> 
>  
> 
> In section 4.2.1.11, starting at bottom of page 38:
> 
>  
> 
>    When rfc822 names are constrained, but the
> 
>    certificate does not include a subject alternative name, the rfc822
> 
>    name constraint MUST be applied to the attribute of type EmailAddress
> 
>    in the subject distinguished name.
> 
>  
> 
> Suppose/suggest that the intended meaning is:
> 
>  
> 
>    When rfc822 names are constrained, but the certificate does not
> 
>    include an rfc822Name in a subject alternative name extension, the rfc822
> 
>    name constraint MUST be applied to the attribute of type EmailAddress
> 
>    in the subject distinguished name.
> 
>  
> 
>  
> 
> Rationale:
> 
> Why would the constraint NOT apply to EmailAddress just because there is 
> a SubjAltName extension with e.g. just some unrelated other name 
> component present?
> 
>  
> 
> /Stefan
> 
>  
> 

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJNzCC
AvYwggJfoAMCAQICAww3ZDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDI4MjEwMTE0WhcNMDUwNDI4MjEwMTE0
WjBoMQ4wDAYDVQQEEwVIYW5uYTEVMBMGA1UEKhMMU3RlcGhlbiBSb3NzMRswGQYDVQQDExJT
dGVwaGVuIFJvc3MgSGFubmExIjAgBgkqhkiG9w0BCQEWE3N0ZXZlLmhhbm5hQHN1bi5jb20w
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC11rLYp70KnKGmV6pNTFRhWBwq47mV
4hU6EaZxo6I3Vw96Rd3E4TH3SAthIl5N4/tpiMPtlTBiJOU6QHSlz1DgTCclmTK6taqtEyLq
amez8vYgSdOEnOFRYILptjbEwpE+yeUmFKOmZ7zSwBMqRQatMHMaLVUJJ3Ygw1V7fKSwvVU0
OJ8c+c3sJRtRyDLxq/vMzYQP+wyqRqlJPTHGFqVuMp0FZIV5X76z+O+W90m9jXjirz91Jz+W
N6rwqmPi8Qy0uxBKm6NKT1371p+WYaK9OfGk8vGbJ8ZsTP3DyQhuuemYPbkKPtoII6WnHIGT
/DOy2G7gff7GOIhUrs7PziddAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3N0ZXZlLmhhbm5hQHN1
bi5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB++aOP6sZVYlqBGc92hZ61
FHST+OqnKZHRGkqEO94RoxdeaSUFKVO2IaKLMBmqNzmh3N3pIsIKiLhJNvDgLhlRrMRVfR29
uixjTsprR26AacMx/gCiCstGIjkzTb83xAvZay5hnzUmlt/LSNX8e6jTNav6LP64WC+C7Tul
fM/PzDCCAvYwggJfoAMCAQICAww3ZDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDI4MjEwMTE0WhcNMDUwNDI4
MjEwMTE0WjBoMQ4wDAYDVQQEEwVIYW5uYTEVMBMGA1UEKhMMU3RlcGhlbiBSb3NzMRswGQYD
VQQDExJTdGVwaGVuIFJvc3MgSGFubmExIjAgBgkqhkiG9w0BCQEWE3N0ZXZlLmhhbm5hQHN1
bi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC11rLYp70KnKGmV6pNTFRh
WBwq47mV4hU6EaZxo6I3Vw96Rd3E4TH3SAthIl5N4/tpiMPtlTBiJOU6QHSlz1DgTCclmTK6
taqtEyLqamez8vYgSdOEnOFRYILptjbEwpE+yeUmFKOmZ7zSwBMqRQatMHMaLVUJJ3Ygw1V7
fKSwvVU0OJ8c+c3sJRtRyDLxq/vMzYQP+wyqRqlJPTHGFqVuMp0FZIV5X76z+O+W90m9jXji
rz91Jz+WN6rwqmPi8Qy0uxBKm6NKT1371p+WYaK9OfGk8vGbJ8ZsTP3DyQhuuemYPbkKPtoI
I6WnHIGT/DOy2G7gff7GOIhUrs7PziddAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3N0ZXZlLmhh
bm5hQHN1bi5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB++aOP6sZVYlqB
Gc92hZ61FHST+OqnKZHRGkqEO94RoxdeaSUFKVO2IaKLMBmqNzmh3N3pIsIKiLhJNvDgLhlR
rMRVfR29uixjTsprR26AacMx/gCiCstGIjkzTb83xAvZay5hnzUmlt/LSNX8e6jTNav6LP64
WC+C7TulfM/PzDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYT
AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE
ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqG
SIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBa
Fw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs
dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz
dWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRw
nd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn
8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg
t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0
dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1Ud
DwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJ
KoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A
9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH
1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJ
BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDDdkMAkGBSsOAwIa
BQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDUw
NjE0MzUwOFowIwYJKoZIhvcNAQkEMRYEFMXbLgLcoPULUY0MDEWbxDKp9z02MFIGCSqGSIb3
DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG
BSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMN2QwegYLKoZIhvcNAQkQAgsxa6Bp
MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu
MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDDdkMA0G
CSqGSIb3DQEBAQUABIIBAGPnexS7TZ+dns25SGf2I/WPXo7Zl58BF+nRK0c5jxw53cUrpO1x
eN9rkhM57QkUs2hw7wpdlB6fSp+wm/VFy7pVYoXQ+UwOD1tqlK9wRUtdddYykFpICxUsI9fP
ZTbTi/etcpE6Wy0DAgkyZGwPr6DJfsmOnS/KqLQSt7C9DPFdiJPdUAc6CJwgvRhgdFm9vsgD
t2uzSeUN6/qIDz8/TMSE2BBeFJAGULMS6N9wOlAHv6AVFuZNCmufWtpTxlqCMbJKVIBlwKa+
Ea4Y0AWh3giA0Qbfy3LvNWdTEm4+VL6U3fKEPHYGpN7KIEG3sNbSNn09IiuoHZPX4HI/Vct5
DOEAAAAAAAA=
--------------ms090804020804070103010908--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46ETEeG072099; Thu, 6 May 2004 07:29:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46ETEEm072098; Thu, 6 May 2004 07:29:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46ETEUQ072090 for <[e-mail]>; Thu, 6 May 2004 07:29:14 -0700 (PDT) (envelope-from [e-mail])
Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id i46ERusb029078 for <[e-mail]>; Thu, 6 May 2004 08:27:58 -0600 (MDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <[e-mail]> for [e-mail]; Thu, 06 May 2004 10:29:14 -0400 (EDT)
Received: from sun.com (dhcp-ubur02-75-154.East.Sun.COM [129.148.75.154]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]>; Thu, 06 May 2004 10:29:14 -0400 (EDT)
Date: Thu, 06 May 2004 10:25:15 -0400
From: Steve Hanna <[e-mail]>
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
In-reply-to:  <[e-mail]>
To: Stefan Santesson <[e-mail]>
Cc: Wen-Cheng Wang <[e-mail]>, Stephen Kent <[e-mail]>, Santoni Adriano <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=------------ms020005020303050707030801
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20031111
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>

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

A better solution is to require (or at least recommend)
the ability to properly compare PrintableString and
UTF8String encodings. Paul Hoffman and I are working
on an Internet Draft describing how to do this (based
on the IDN and LDAP documents on the same topic).
This handles name constraints earlier in the path, etc.

Thanks,

Steve

Stefan Santesson wrote:
> Name rollover certificates only takes care of CA name changes.
> It doesn't solve the problem if subject names have mixed encoding in the
> forest of user certificates, while the CAs names are intact.
> 
> Neither does it solve when the constraint is placed above the CA
> rollover.
> 
> Finally, CA name rollover will most likely bust path validation using
> other constraining mechanisms because they may just not be recognized as
> self issued due to different name encoding. 
> 
> Stefan Santesson
> Program Manager, Windows Security
> 
> 
>>-----Original Message-----
>>From: [e-mail]
> 
> [mailto:[e-mail]]
> 
>>On Behalf Of Wen-Cheng Wang
>>Sent: den 5 maj 2004 23:40
>>To: Stefan Santesson; Stephen Kent; Santoni Adriano
>>Cc: [e-mail]; [e-mail]
>>Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
> 
> encoding
> 
>>RDNs
>>
>>
>>RFC 3280 does not ask CAs to replace all certificates at once for
>>migrating to UTF8String encoding. Instead, it suggest that
>>   "CAs MAY issue "name rollover" certificates to support an
>>     orderly migration to UTF8String encoding."
>>
>>I believe that if relying parties use 3280-compliant certification
> 
> path
> 
>>validation modules, then they will not have problem for processing
>>"name rollover" certificates, and thus the migration to UTF8String
>>encoding will not be a problem.
>>
>>One thing should be noted: a "name rollover" certificate is
> 
> essentially
> 
>>a "self-issued certificate" but its issuer name and subject name is in
>>different encoding. Therefore, the definition of "self-issued
> 
> certificate"
> 
>>should be changed a little. Also, since a "name rollover" certificate
> 
> may
> 
>>contains a NameConstraints extension in which the permittedSubtrees
>>and excludedSubtrees will be in a new encoding (e.g., UTF8String),
>>the path validation in RFC 3280 also need to be revised. I hope all of
>>these should be addressed in sonOfRfc3280.
>>
>>I don't think that RFC 3280 mandates the support for UTF8String
>>encoding is "at odds with reality". There are many countries/regions
>>in the world where it is impossible to encode names in Printable
> 
> String.
> 
>>In Taiwan, we have already millions of certificates with issuer names
>>and subject names encoded in UTF8String.
>>
>>Three years ago, I tested some VPN devices and found most of them
>>can not accept certificates with UTF8String (One of them even crashed
>>if received a certificate with UTF8String). Recently, I test many VPN
>>devices
>>again and amazingly found the all of them can normally handle
> 
> certificates
> 
>>with
>>UTF8String. All of them can chain and validate certificte paths that
>>contains
>>certificates with UTF8String. (Although, most of them still can not
>>display
>>the
>>UTF8String in Chinese correctly. It is a pity.)
>>
>>The truth is that there are more and more applications that can
> 
> handling
> 
>>UTF8String encoding. I think the credit should give to RFC 3280 for
> 
> its
> 
>>mandating  for UTF8String encoding.
>>
>>Wen-Cheng Wang
>>
>>
>>----- Original Message -----
>>From: "Stefan Santesson" <[e-mail]>
>>To: "Stephen Kent" <[e-mail]>; "Santoni Adriano"
>><[e-mail]>
>>Cc: <[e-mail]>; <[e-mail]>
>>Sent: Thursday, May 06, 2004 8:18 AM
>>Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in
> 
> encoding
> 
>>RDNs
>>
>>
>>
>>>
>>>Steve,
>>>
>>>There is one unfortunate side effect that makes this requirement
> 
> worse
> 
>>>than other evolutions of standards.
>>>
>>>It is almost never feasible to replace all certificates in a
> 
> hierarchy
> 
>>>at once. This means that you over time will have a mixed environment
>>>where e.g. the same organization name will exist in different
> 
> encoding
> 
>>>in many places of your hierarchy.
>>>
>>>It will then be virtually impossible to apply name constraining in
> 
> such
> 
>>>environment because RFC 3280 does not mandate the full X.500 name
>>>matching rules and a client may subsequently decide that names with
>>>different encoding is a no-match.
>>>
>>>This seams to be an unsolvable problem that, looking in the mirror,
> 
> is
> 
>>>inadequately addressed and shouldn't have passed in its current
> 
> form. In
> 
>>>fact it is probably a defect that needs to be addressed in
> 
> sonOfRfc3280
> 
>>>in one way or the other.
>>>
>>>/Stefan
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: [e-mail]
>>>
>>>[mailto:[e-mail]]
>>>
>>>>On Behalf Of Stephen Kent
>>>>Sent: den 5 maj 2004 13:36
>>>>To: Santoni Adriano
>>>>Cc: '[e-mail]'; [e-mail]
>>>>Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
>>>
>>>encoding
>>>
>>>>RDNs
>>>>
>>>>
>>>>At 9:54 AM +0200 4/23/04, Santoni Adriano wrote:
>>>>
>>>>>A rule that is "at odds with reality" should not be expressed in
>>>
>>>terms of
>>>
>>>>>MUST, but rather in terms of SHOULD. I wonder how it came that
> 
> RFC
> 
>>>3280
>>>
>>>>>reached the status of an official IETF standard, if it contains
> 
> one
> 
>>>or
>>>
>>>>more
>>>>
>>>>>areas that are "at odds with reality".
>>>>>
>>>>>I suppose the answer is one of these:
>>>>>- RFC 3280 does not really contain areas that are "at odds with
>>>
>>>reality"
>>>
>>>>-
>>>>
>>>>>it's just that we do not understand them;
>>>>
>>>>RFC 3280 established a requirement for a change in how DNs are
>>>>encoded, for a future point in time. Thus, at the time the RFC was
>>>>published as a standard of course it did not match "reality."
> 
> since
> 
>>>>it was calling for a change.  By the way, this change was not the
>>>>idea of the PKIX WG but rather is consistent with the overall IETF
>>>>mandate to better accommodate character sets for a wide range of
>>>>languages.
>>>>
>>>>
>>>>>- containing areas that are "at odds with reality" is not an
> 
> obstacle
> 
>>>to
>>>
>>>>>becoming a standard;
>>>>
>>>>Think of the implication of your comment. if we were never able to
>>>>call for a change in how things are done when we update a
> 
> standard,
> 
>>>>then we could never make any changes.  obviously this would be
> 
> unduly
> 
>>>>limiting.
>>>>
>>>>
>>>>>- expressions like "MUST" in IETF standard are really to be taken
> 
> as
> 
>>>mere
>>>
>>>>>suggestions;
>>>>
>>>>IETF standards are voluntary. failure to comply is not punishable
> 
> :-)
> 
>>>>>- nobody really cares.
>>>>
>>>>one might say that in environments where a few vendors or service
>>>>providers control a significant market share, their deviation from
>>>>standards, or failure to accommodate changes in standards, can
> 
> have
> 
>>>>profound impacts.
>>>>
>>>>Steve
>>>
>>>
> 
> 

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJNzCC
AvYwggJfoAMCAQICAww3ZDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDI4MjEwMTE0WhcNMDUwNDI4MjEwMTE0
WjBoMQ4wDAYDVQQEEwVIYW5uYTEVMBMGA1UEKhMMU3RlcGhlbiBSb3NzMRswGQYDVQQDExJT
dGVwaGVuIFJvc3MgSGFubmExIjAgBgkqhkiG9w0BCQEWE3N0ZXZlLmhhbm5hQHN1bi5jb20w
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC11rLYp70KnKGmV6pNTFRhWBwq47mV
4hU6EaZxo6I3Vw96Rd3E4TH3SAthIl5N4/tpiMPtlTBiJOU6QHSlz1DgTCclmTK6taqtEyLq
amez8vYgSdOEnOFRYILptjbEwpE+yeUmFKOmZ7zSwBMqRQatMHMaLVUJJ3Ygw1V7fKSwvVU0
OJ8c+c3sJRtRyDLxq/vMzYQP+wyqRqlJPTHGFqVuMp0FZIV5X76z+O+W90m9jXjirz91Jz+W
N6rwqmPi8Qy0uxBKm6NKT1371p+WYaK9OfGk8vGbJ8ZsTP3DyQhuuemYPbkKPtoII6WnHIGT
/DOy2G7gff7GOIhUrs7PziddAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3N0ZXZlLmhhbm5hQHN1
bi5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB++aOP6sZVYlqBGc92hZ61
FHST+OqnKZHRGkqEO94RoxdeaSUFKVO2IaKLMBmqNzmh3N3pIsIKiLhJNvDgLhlRrMRVfR29
uixjTsprR26AacMx/gCiCstGIjkzTb83xAvZay5hnzUmlt/LSNX8e6jTNav6LP64WC+C7Tul
fM/PzDCCAvYwggJfoAMCAQICAww3ZDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDI4MjEwMTE0WhcNMDUwNDI4
MjEwMTE0WjBoMQ4wDAYDVQQEEwVIYW5uYTEVMBMGA1UEKhMMU3RlcGhlbiBSb3NzMRswGQYD
VQQDExJTdGVwaGVuIFJvc3MgSGFubmExIjAgBgkqhkiG9w0BCQEWE3N0ZXZlLmhhbm5hQHN1
bi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC11rLYp70KnKGmV6pNTFRh
WBwq47mV4hU6EaZxo6I3Vw96Rd3E4TH3SAthIl5N4/tpiMPtlTBiJOU6QHSlz1DgTCclmTK6
taqtEyLqamez8vYgSdOEnOFRYILptjbEwpE+yeUmFKOmZ7zSwBMqRQatMHMaLVUJJ3Ygw1V7
fKSwvVU0OJ8c+c3sJRtRyDLxq/vMzYQP+wyqRqlJPTHGFqVuMp0FZIV5X76z+O+W90m9jXji
rz91Jz+WN6rwqmPi8Qy0uxBKm6NKT1371p+WYaK9OfGk8vGbJ8ZsTP3DyQhuuemYPbkKPtoI
I6WnHIGT/DOy2G7gff7GOIhUrs7PziddAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3N0ZXZlLmhh
bm5hQHN1bi5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB++aOP6sZVYlqB
Gc92hZ61FHST+OqnKZHRGkqEO94RoxdeaSUFKVO2IaKLMBmqNzmh3N3pIsIKiLhJNvDgLhlR
rMRVfR29uixjTsprR26AacMx/gCiCstGIjkzTb83xAvZay5hnzUmlt/LSNX8e6jTNav6LP64
WC+C7TulfM/PzDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYT
AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE
ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqG
SIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBa
Fw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs
dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz
dWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRw
nd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn
8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg
t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0
dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1Ud
DwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJ
KoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A
9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH
1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJ
BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDDdkMAkGBSsOAwIa
BQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDUw
NjE0MjUxNVowIwYJKoZIhvcNAQkEMRYEFCv0SAj248yHUuVfubR3/yua1DueMFIGCSqGSIb3
DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG
BSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMN2QwegYLKoZIhvcNAQkQAgsxa6Bp
MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu
MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDDdkMA0G
CSqGSIb3DQEBAQUABIIBAGMx4RAv3/TaCX2+yZuN1WpreVhqPkLUmzdU3cL3d1Tf75prfL46
jJzEfSO8wlPkJ/DnBDn+V2ZzZ4Zd2pCKUvhU4d/y8kL/TNajp8c2TseF05ZeoEWSQhx2mS9t
Sh1vQ3Ha1C12E2Gvzdt5iLFfFgVO73DvC775gFIXuhX3QqvB/r9vjZmglx89iNFscgzsarUv
ASvXrNowpzlfAJ/JDiZCfageZmtqGgwYuSRW3/zSEO/YCBNY281vksm76bJKWBOcMOtFBc1Y
yMAe2qwltQEOv03UhlkH568aJyviAeCrUEbKhiHSw6dVFMhb4h8Qew6HgrEONNJRWpiAAwkZ
CVoAAAAAAAA=
--------------ms020005020303050707030801--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46DX1X1067689; Thu, 6 May 2004 06:33:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46DX15E067687; Thu, 6 May 2004 06:33:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46DWpCW067641 for <[e-mail]>; Thu, 6 May 2004 06:32:51 -0700 (PDT) (envelope-from [e-mail])
Received: from eur-imc-02.europe.corp.microsoft.com ([65.53.196.43]) by mail-eur.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 May 2004 14:32:43 +0100
Received: from 65.53.196.43 by eur-imc-02.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 May 2004 14:32:43 +0100
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); Thu, 6 May 2004 14:32:43 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Date: Thu, 6 May 2004 14:32:41 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Thread-Index: AcQzPxL5hMiEJesQTHKpNAdD7VavPAALqcBA
From: "Stefan Santesson" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Santoni Adriano" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 06 May 2004 13:32:43.0259 (UTC) FILETIME=[9C2954B0:01C4336E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i46DWpCW067669
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Name rollover certificates only takes care of CA name changes.
It doesn't solve the problem if subject names have mixed encoding in the
forest of user certificates, while the CAs names are intact.

Neither does it solve when the constraint is placed above the CA
rollover.

Finally, CA name rollover will most likely bust path validation using
other constraining mechanisms because they may just not be recognized as
self issued due to different name encoding. 

Stefan Santesson
Program Manager, Windows Security

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Wen-Cheng Wang
> Sent: den 5 maj 2004 23:40
> To: Stefan Santesson; Stephen Kent; Santoni Adriano
> Cc: [e-mail]; [e-mail]
> Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> 
> RFC 3280 does not ask CAs to replace all certificates at once for
> migrating to UTF8String encoding. Instead, it suggest that
>    "CAs MAY issue "name rollover" certificates to support an
>      orderly migration to UTF8String encoding."
> 
> I believe that if relying parties use 3280-compliant certification
path
> validation modules, then they will not have problem for processing
> "name rollover" certificates, and thus the migration to UTF8String
> encoding will not be a problem.
> 
> One thing should be noted: a "name rollover" certificate is
essentially
> a "self-issued certificate" but its issuer name and subject name is in
> different encoding. Therefore, the definition of "self-issued
certificate"
> should be changed a little. Also, since a "name rollover" certificate
may
> contains a NameConstraints extension in which the permittedSubtrees
> and excludedSubtrees will be in a new encoding (e.g., UTF8String),
> the path validation in RFC 3280 also need to be revised. I hope all of
> these should be addressed in sonOfRfc3280.
> 
> I don't think that RFC 3280 mandates the support for UTF8String
> encoding is "at odds with reality". There are many countries/regions
> in the world where it is impossible to encode names in Printable
String.
> In Taiwan, we have already millions of certificates with issuer names
> and subject names encoded in UTF8String.
> 
> Three years ago, I tested some VPN devices and found most of them
> can not accept certificates with UTF8String (One of them even crashed
> if received a certificate with UTF8String). Recently, I test many VPN
> devices
> again and amazingly found the all of them can normally handle
certificates
> with
> UTF8String. All of them can chain and validate certificte paths that
> contains
> certificates with UTF8String. (Although, most of them still can not
> display
> the
> UTF8String in Chinese correctly. It is a pity.)
> 
> The truth is that there are more and more applications that can
handling
> UTF8String encoding. I think the credit should give to RFC 3280 for
its
> mandating  for UTF8String encoding.
> 
> Wen-Cheng Wang
> 
> 
> ----- Original Message -----
> From: "Stefan Santesson" <[e-mail]>
> To: "Stephen Kent" <[e-mail]>; "Santoni Adriano"
> <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> Sent: Thursday, May 06, 2004 8:18 AM
> Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> 
> >
> >
> > Steve,
> >
> > There is one unfortunate side effect that makes this requirement
worse
> > than other evolutions of standards.
> >
> > It is almost never feasible to replace all certificates in a
hierarchy
> > at once. This means that you over time will have a mixed environment
> > where e.g. the same organization name will exist in different
encoding
> > in many places of your hierarchy.
> >
> > It will then be virtually impossible to apply name constraining in
such
> > environment because RFC 3280 does not mandate the full X.500 name
> > matching rules and a client may subsequently decide that names with
> > different encoding is a no-match.
> >
> > This seams to be an unsolvable problem that, looking in the mirror,
is
> > inadequately addressed and shouldn't have passed in its current
form. In
> > fact it is probably a defect that needs to be addressed in
sonOfRfc3280
> > in one way or the other.
> >
> > /Stefan
> >
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > [mailto:[e-mail]]
> > > On Behalf Of Stephen Kent
> > > Sent: den 5 maj 2004 13:36
> > > To: Santoni Adriano
> > > Cc: '[e-mail]'; [e-mail]
> > > Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
> > encoding
> > > RDNs
> > >
> > >
> > > At 9:54 AM +0200 4/23/04, Santoni Adriano wrote:
> > > >A rule that is "at odds with reality" should not be expressed in
> > terms of
> > > >MUST, but rather in terms of SHOULD. I wonder how it came that
RFC
> > 3280
> > > >reached the status of an official IETF standard, if it contains
one
> > or
> > > more
> > > >areas that are "at odds with reality".
> > > >
> > > >I suppose the answer is one of these:
> > > >- RFC 3280 does not really contain areas that are "at odds with
> > reality"
> > > -
> > > >it's just that we do not understand them;
> > >
> > > RFC 3280 established a requirement for a change in how DNs are
> > > encoded, for a future point in time. Thus, at the time the RFC was
> > > published as a standard of course it did not match "reality."
since
> > > it was calling for a change.  By the way, this change was not the
> > > idea of the PKIX WG but rather is consistent with the overall IETF
> > > mandate to better accommodate character sets for a wide range of
> > > languages.
> > >
> > > >- containing areas that are "at odds with reality" is not an
obstacle
> > to
> > > >becoming a standard;
> > >
> > > Think of the implication of your comment. if we were never able to
> > > call for a change in how things are done when we update a
standard,
> > > then we could never make any changes.  obviously this would be
unduly
> > > limiting.
> > >
> > > >- expressions like "MUST" in IETF standard are really to be taken
as
> > mere
> > > >suggestions;
> > >
> > > IETF standards are voluntary. failure to comply is not punishable
:-)
> > >
> > > >- nobody really cares.
> > >
> > > one might say that in environments where a few vendors or service
> > > providers control a significant market share, their deviation from
> > > standards, or failure to accommodate changes in standards, can
have
> > > profound impacts.
> > >
> > > Steve
> >
> >




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46Aarir056597; Thu, 6 May 2004 03:36:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i46AarbV056596; Thu, 6 May 2004 03:36:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i46Aakxc056586 for <[e-mail]>; Thu, 6 May 2004 03:36:52 -0700 (PDT) (envelope-from [e-mail])
Received: from ms21.chttl.com.tw (ms21 [10.144.2.121]) by fw.chttl.com.tw (8.12.10/8.12.10) with ESMTP id i46AZwGG022514; Thu, 6 May 2004 18:35:58 +0800
Received: (from root@localhost) by ms21.chttl.com.tw (8.12.10/8.12.10) id i46AZxxf001862; Thu, 6 May 2004 18:35:59 +0800
Received: from wcwang ([10.144.133.79]) by ms21.chttl.com.tw (8.12.10/8.12.10) with SMTP id i46AZvL5001688; Thu, 6 May 2004 18:35:57 +0800
Message-ID: <020a01c43355$e95e13b0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: FW: scvp
Date: Thu, 6 May 2004 18:35:54 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I don't agree that the broader consensus is for a "al a carte".
(Maybe we should have a straw poll to decide what is the 
broader consensus?)

When designing a DPV protocol, please do not forget that the
two main benefits to establish a DPV server are:

1. it reduces the burden for application implementators to implement
    certification path processing modules by themself;
2. it allows validation against management-defined validation policies
    in a consistent fashion across an application domain (e.g., an
    enterprise).

I believe that application implementors do not want "al a carte"
combinations, they will prefer suits instead. If a DPV server requires
application implementors to use a DPV client API that needs
the implementors to specify a validation policy OID with many initial
mystery parameters, then what is the benefit to use the DPV server?
Why not simply use a certification path processing API such as CML
instead a DPV client API if the burden is the same? At least, you can
save the budget for establishing a DPV server if you choose to use
CML.

Besides, in an application domain where the authority wish
to force all applications to validate certification path against
management-defined validation policies in a consistent fashion,
the applications will not even be allowed to specify any initial
parameters (except the certificate to be validated). If the client
side is allows to specfy its own initial parameters, how can the
validation be guaranteed to proceed in the consistent fashion?
In an application domain with a centralized validation policy, the
server side will decide almost all the initial parameters according
to the validation policy. In such case, the client side need not
(and might not be allowed) to specify any initial parameters
(except the certificate to be validated, of course).

I believe that in most use cases of DPV, the client side will need
not to specify any initial parameters. Therefore, why not simplify the
syntax of the SCVP so that the client side do not to specify any initial
parameters in a basic request. In my opinion, the SCVP is not a
"simple" protocol anymore. Let's simplify it so that it deserve the
name of a "simple" protocol.

That is not to say that the SCVP can not provide a mechanism
for the client side to specify its own validation policy and initial
parameters if the server side allows its clients to do that, but this
can be achieved by using the "Extension" mechanism. In the most
case, there is no need  for the client side to specify its own validation
policy and initial parameters, so please do not let the basic syntax
so complicated.

Personally, I think the draft 12 syntax is better than draft 13/14.
Maybe we should go back to the draft 12 syntax and try to define
some extensions based on that syntax.

Wen-Cheng Wang

----- Original Message ----- 
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, May 05, 2004 1:22 AM
Subject: RE: FW: scvp


> 
> Hi Denis,
> There is no mandate in 3379 that a validation policy must be expressed
> with a single value. It is not clear that is any value is doing so since
> it only raised more ambiguity. This is well trod turf by many groups who
> have debated the merits of providing suits vs. "al a carte" combinations
> of inputs and the broader consensus is for a "al a carte".
> Trevor
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Tuesday, May 04, 2004 3:15 AM
> To: Trevor Freeman
> Cc: [e-mail]
> Subject: Re: FW: scvp
> 
> Trevor,
> 
> > Hi Denis,
> > 
> > 3379 does not require that the validation policy be specified in a
> > single value. 
> 
> You are playing with words. The text says:
> "most clients will simply reference a validation policy"
> 
> This means that validation policies can be referenced and thus
> parameters do 
> not need to be defined through this interface.
> 
> A simple and good reference is an OID.
> 
> > With SCVP14 a client can accept the default of the SCVP
> > server or specify a set of parameters which constitutes its validation
> > policy. That is consistent with the requirements of 3379.
> 
> The specification of the set of parameters should be done through a 
> different interface. This different interface can then return an OID 
> Whatever this additional interface can be, it will never be rich enough
> to 
> pass all the details of the validation policy. Thus OIDs can also be
> defined 
> not using this additional interface.
> 
> Denis
> 
> > Trevor
> > 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]] 
> > Sent: Thursday, April 29, 2004 3:54 AM
> > To: Trevor Freeman
> > Cc: [e-mail]
> > Subject: Re: FW: scvp
> > 
> > Trevor,
> > 
> > 
> >>Hi Denis,
> > 
> > 
> >>Can you please be more specific how you think SCVP 14 does not comply
> >>with 3379.
> >>
> >>I can find no section in 3379 where is there a requirement that a
> >>validation policy MUST be represented as an OID. 
> > 
> > 
> > There cannot be a requirement with such a level of detail, but the
> text
> > states:
> > 
> >     The protocol MUST allow the client to include
> >     these policy dependant parameters in the DPV request; however, it
> is
> >     expected that most clients will simply reference a validation
> policy
> >     for a given application or accept the DPV server's default
> > validation
> >     policy.
> > 
> > A simple reference is an OID.
> > 
> > FYI, I do not expect to use the "default validation policy".
> > 
> > Denis
> > 
> > 
> > 
> >>Given hiding the detail of what a policy is within an OID simply opens
> >>the rat hole of what change to the policy constitutes a change to the
> >>OID, it is less ambiguous to refer to the primary data. Once you are
> > 
> > in
> > 
> >>the business of managing state on a client, then there is negligible
> >>cost increase incurred in managing several data points vs. a singe
> > 
> > data
> > 
> >>point.
> >>
> >>Trevor
> >>
> >>-----Original Message-----
> >>From: Denis Pinkas [mailto:[e-mail]] 
> >>Sent: Tuesday, April 27, 2004 11:01 AM
> >>To: Trevor Freeman
> >>Cc: [e-mail]
> >>Subject: Re: FW: scvp
> >>
> >>Trevor,
> >>
> >>
> >>
> >>>HI Denis,
> >>>In SCVP13, the concept of validation policy was not completely in
> >>>alignment  with 3379 definition. 
> >>
> >>
> >>Well, it is different and this is a major problem.
> >>
> >>
> >>
> >>>It also blurred the distinction between
> >>>validation policy and validation algorithm. 
> >>
> >>
> >>This is also a majo problem.
> >>
> >>
> >>
> >>>Therefore I have defined
> >>>what each is in SCVP 14 and aligned the structures accordingly.
> >>>Section 1.3 has the following.
> >>>"In SCVP, the validation policy comprises of an algorithm for
> >>>certificate path processing and the input parameters to the
> >>
> >>algorithm."
> >>
> >>This does not comply with RFC 3379.
> >>
> >>
> >>
> >>>Therefore trust anchors are an input into the algorithm  and
> therefore
> >>>separate.
> >>
> >>
> >>Therefore I do not follow you.
> >>
> >> From an interface point of view the simplest validation policy is
> >>defined 
> >>by an OID where all the parameters necessary to perform the validation
> >>check 
> >>are "behind" the OID. There is no need to provide any parameter
> > 
> > through
> > 
> >>the 
> >>interface.
> >>
> >>When there are some parameters, then they are specific to the
> > 
> > validation
> > 
> >>policy. I have no problem to provide specific parameters for what is
> >>called 
> >>the "default validation policy" which is only a particular validation
> >>policy 
> >>among many others.
> >>
> >>Simple clients will be unable to pass any parameter but will know
> > 
> > which
> > 
> >>OIDs 
> >>(for the validation policy) are appropriate for their applications.
> >>
> >>Denis
> >>
> >>
> >>
> >>>This is in alignment with 3379s definition of validation policy.
> >>>
> >>>Trevor
> >>>
> >>>-----Original Message-----
> >>>From: Denis Pinkas [mailto:[e-mail]] 
> >>>Sent: Monday, April 26, 2004 1:09 AM
> >>>To: Peter Sylvester
> >>>Cc: [e-mail]; Trevor Freeman
> >>>Subject: Re: FW: scvp
> >>>
> >>>Peter and Trevor,
> >>>
> >>>I have major problems too.
> >>>
> >>>
> >>>
> >>>
> >>>>in version 13 the syntax for a Query has been changed from
> >>>>
> >>>> Query ::= SEQUENCE { 
> >>>>     queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference, 
> >>>>     checks                CertChecks, 
> >>>>     wantBack              WantBack, 
> >>>>     serverContextInfo [0] OCTET STRING OPTIONAL, 
> >>>>     valPolicy         [1] ValidationPolicy OPTIONAL, 
> >>>>     validityTime      [2] GeneralizedTime OPTIONAL, 
> >>>>     trustAnchors      [3] TrustAnchors OPTIONAL, 
> >>>>     intermediateCerts [4] CertBundle OPTIONAL, 
> >>>>     revInfos          [5] RevocationInfos OPTIONAL, 
> >>>>     queryExtensions   [6] Extensions OPTIONAL } 
> >>>
> >>>
> >>>In this structure trustAnchors was more or less an alternative to
> >>>valPolicy.
> >>>
> >>>In fact, IF the valPolicy is the default policy, THEN additional
> >>>parameters 
> >>>MUST be provided. So the structure below does not fit as well.
> >>>
> >>>This leads to have the two following elements:
> >>>
> >>>    valPolicy               ValidationPolicy,
> >>>    paramsDefValPolicy      ParamsDefValPolicy OPTIONAL,
> >>>
> >>>where the first one is mandatory and the second one optional.
> >>>
> >>>
> >>>
> >>>
> >>>>to  
> >>>>
> >>>>  Query ::= SEQUENCE { 
> >>>>    queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
> >>>
> >>>
> >>>>    checks                  CertChecks, 
> >>>>    wantBack                WantBack, 
> >>>>    requestRefHash          BOOLEAN DEFAULT TRUE, 
> >>>>    includePolResponce      BOOLEAN DEFAULT FALSE, 
> >>>>    inhibitPolMap           BOOLEAN DEFAULT FALSE, 
> >>>>    requireExplicitPol      BOOLEAN DEFAULT FALSE, 
> >>>>    ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
> >>>>    valAlgorithm            ValidationAlgorithm, 
> >>>>    serverContextInfo   [0] OCTET STRING OPTIONAL, 
> >>>>    validityTime        [1] GeneralizedTime OPTIONAL, 
> >>>>    trustAnchors        [2] TrustAnchors OPTIONAL, 
> >>>>    intermediateCerts   [3] CertBundle OPTIONAL, 
> >>>>    revInfos            [4] RevocationInfos OPTIONAL, 
> >>>>    queryExtensions     [5] Extensions OPTIONAL } 
> >>>
> >>>
> >>>I would thus propose to have something like:
> >>>
> >>>Query ::= SEQUENCE {
> >>>        queriedCerts            SEQUENCE SIZE (1..MAX) OF
> >>>CertReference,
> >>>        checks                  CertChecks,
> >>>        wantBack                WantBack,
> >>>        requestRefHash          BOOLEAN DEFAULT TRUE,
> >>>        serverContextInfo       OCTET STRING OPTIONAL,
> >>>        validityTime            GeneralizedTime OPTIONAL,
> >>>        includePolResponse      BOOLEAN DEFAULT FALSE,
> >>>        valPolicy               ValidationPolicy,
> >>>        paramsDefValPolicy  [0] ParamsDefValPolicy OPTIONAL,
> >>>        intermediateCerts   [1] CertBundle OPTIONAL,
> >>>        revInfos            [2] RevocationInfos OPTIONAL,
> >>>        queryExtensions     [3] Extensions OPTIONAL }
> >>>
> >>>and then something like:
> >>>
> >>>   ParamsDefValPolicy :: = SEQUENCE {
> >>>       trustAnchors                  TrustAnchors,
> >>>       endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER
> >>>OPTIONAL,
> >>>       inhibitPolMap                 BOOLEAN DEFAULT FALSE,
> >>>       caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER
> >>>OPTIONAL }
> >>>
> >>>Denis
> >>>
> >>>
> >>>
> >>>
> >>>>I am not sure whether I am the only person unable to construct a
> >>>
> >>>parser.
> >>>
> >>>
> >>>
> >>>>in version 14 an aditional flag has been added which is not
> available
> >>>
> >>>in the
> >>>
> >>>
> >>>
> >>>>Chapter 9. Is the isCA flag an orthogonal attribut to other
> >>>
> > validation
> > 
> >>>>algorithms, or just to some of them, e.g,. the default name matching
> >>>
> >>>one? 
> >>>
> >>>
> >>>
> >>>>  Query ::= SEQUENCE { 
> >>>>    queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
> >>>
> >>>
> >>>>    checks                  CertChecks, 
> >>>>    wantBack                WantBack, 
> >>>>    requestRefHash          BOOLEAN DEFAULT TRUE, 
> >>>>    includePolResponce      BOOLEAN DEFAULT FALSE, 
> >>>>    inhibitPolMap           BOOLEAN DEFAULT FALSE, 
> >>>>    requireExplicitPol      BOOLEAN DEFAULT FALSE, 
> >>>>    ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
> >>>>    isCA                    BOOLEAN DEFAULT FALSE, 
> >>>>    valAlgorithm            ValidationAlgorithm, 
> >>>>    serverContextInfo   [0] OCTET STRING OPTIONAL, 
> >>>>    validityTime        [1] GeneralizedTime OPTIONAL, 
> >>>>    trustAnchors        [2] TrustAnchors OPTIONAL, 
> >>>>    intermediateCerts   [3] CertBundle OPTIONAL, 
> >>>>    revInfos            [4] RevocationInfos OPTIONAL, 
> >>>>    keyUsage            [5] KeyUsage OPTIONAL, 
> >>>>    extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
> >>>>    queryExtensions     [7] Extensions OPTIONAL  
> >>>>    producedAt          [8] GeneralizedTime OPTIONAL} 
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> > 
> > 
> > 
> 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i466giC9074411; Wed, 5 May 2004 23:42:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i466gia7074409; Wed, 5 May 2004 23:42:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ntexch03.office.corp.sia.it (clients.sia.it [193.203.230.22] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id i466ghXM074362 for <[e-mail]>; Wed, 5 May 2004 23:42:44 -0700 (PDT) (envelope-from [e-mail])
Received: by ntexch03.office.corp.sia.it with Internet Mail Service (5.5.2657.72) id <JZ9SNMKA>; Thu, 6 May 2004 08:42:39 +0200
Message-ID: <[e-mail]>
From: Santoni Adriano <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, Stephen Kent <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: R: R: I: R: RFC3280: doubt on the use of UTF8String in encoding R DNs
Date: Thu, 6 May 2004 08:42:31 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i466giXM074404
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks to both Kent and Santesson for their comments.

Of course, it was not my intention to argument against the adoption of
UTF8String. On the contrary, I am personally convinced that is (would be?
will be?) a good and sensible initiative.

And of course, my previous message was provocative, as I am perfectly aware
that "if we were never able to call for a change in how things are done when
we update a standard, then we could never make any changes", and that "IETF
standards are voluntary. failure to comply is not punishable"; I dare to say
that is quite obvious to almost anyone in the industry.

Actually, it is not just the compliance to IETF standards which is
voluntary. It is also the degree of compliance and the very meaning of
compliance, to be voluntary. It is just too easy to claim compliance to any
standard. What if RFCs had an incipit saying something like <<Failure to
comply to any of the mandatory features herein described shall be equivalent
to not being compliant at all with this standard. It is prohibited to claim
compliance with this standard unless each and all of the mandatory features
herein described are fully obeyed to>>. Well, I know I am being too candid
with this idea...

However, it would be nice to see a meaningful number of CAs discuss this
topic and try to decide on the way to go. Should we try to switch to
UTF8String during the current year? Or in the next year? Or just leave any
CA do what it likes, regardless of any "MUST" or deadlines that happen to
show up in RFCs? This mailing list should be the right place to discuss
that, but it seems the topic is not very interesting...

Adriano


-----Messaggio originale-----
Da: Stefan Santesson [mailto:[e-mail]] 
Inviato: giovedì 6 maggio 2004 2.18
A: Stephen Kent; Santoni Adriano
Cc: [e-mail]; [e-mail]
Oggetto: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encoding
RDNs



Steve,

There is one unfortunate side effect that makes this requirement worse than
other evolutions of standards.

It is almost never feasible to replace all certificates in a hierarchy at
once. This means that you over time will have a mixed environment where e.g.
the same organization name will exist in different encoding in many places
of your hierarchy.

It will then be virtually impossible to apply name constraining in such
environment because RFC 3280 does not mandate the full X.500 name matching
rules and a client may subsequently decide that names with different
encoding is a no-match.

This seams to be an unsolvable problem that, looking in the mirror, is
inadequately addressed and shouldn't have passed in its current form. In
fact it is probably a defect that needs to be addressed in sonOfRfc3280 in
one way or the other.

/Stefan


> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Stephen Kent
> Sent: den 5 maj 2004 13:36
> To: Santoni Adriano
> Cc: '[e-mail]'; [e-mail]
> Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> 
> At 9:54 AM +0200 4/23/04, Santoni Adriano wrote:
> >A rule that is "at odds with reality" should not be expressed in
terms of
> >MUST, but rather in terms of SHOULD. I wonder how it came that RFC
3280
> >reached the status of an official IETF standard, if it contains one
or
> more
> >areas that are "at odds with reality".
> >
> >I suppose the answer is one of these:
> >- RFC 3280 does not really contain areas that are "at odds with
reality"
> -
> >it's just that we do not understand them;
> 
> RFC 3280 established a requirement for a change in how DNs are 
> encoded, for a future point in time. Thus, at the time the RFC was 
> published as a standard of course it did not match "reality." since it 
> was calling for a change.  By the way, this change was not the idea of 
> the PKIX WG but rather is consistent with the overall IETF mandate to 
> better accommodate character sets for a wide range of languages.
> 
> >- containing areas that are "at odds with reality" is not an obstacle
to
> >becoming a standard;
> 
> Think of the implication of your comment. if we were never able to 
> call for a change in how things are done when we update a standard, 
> then we could never make any changes.  obviously this would be unduly 
> limiting.
> 
> >- expressions like "MUST" in IETF standard are really to be taken as
mere
> >suggestions;
> 
> IETF standards are voluntary. failure to comply is not punishable :-)
> 
> >- nobody really cares.
> 
> one might say that in environments where a few vendors or service 
> providers control a significant market share, their deviation from 
> standards, or failure to accommodate changes in standards, can have 
> profound impacts.
> 
> Steve


*******************Internet Email Confidentiality Footer******************* 
Qualsiasi utilizzo non autorizzato del presente messaggio nonche' dei suoi
allegati e' vietato e potrebbe costituire reato. Se lei ha ricevuto
erroneamente il presente messaggio, Le saremmo grati se, via e-mail, ce ne
comunicasse la ricezione e provvedesse alla distruzione del messaggio stesso
e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente
messaggio nonche' nei suoi eventuali allegati devono essere attribuite
esclusivamente al mittente e non possono essere considerate come trasmesse o
autorizzate da SIA S.p.A.; le medesime dichiarazioni non impegnano SIA
S.p.A. nei confronti del destinatario o di terzi. 
SIA S.p.A. non si assume alcuna responsabilita' per eventuali
intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited
and could constitute an offence. If you are not the intended addressee
please advise immediately the sender by using the reply facility in your
e-mail software and destroy the message and its attachments. The statements
and opinions expressed in this e-mail message are those of the author of the
message and do not necessarily represent those of SIA. Besides, The contents
of this message shall be understood as neither given nor endorsed by SIA
S.p.A.. 
SIA S.p.A. does not accept liability for corruption, interception or
amendment, if any, or the consequences thereof. 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i466f6el073369; Wed, 5 May 2004 23:41:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i466f61Q073368; Wed, 5 May 2004 23:41:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i466exGo073253 for <[e-mail]>; Wed, 5 May 2004 23:41:00 -0700 (PDT) (envelope-from [e-mail])
Received: from ms21.chttl.com.tw (ms21 [10.144.2.121]) by fw.chttl.com.tw (8.12.10/8.12.10) with ESMTP id i466dtGG003859; Thu, 6 May 2004 14:39:55 +0800
Received: (from root@localhost) by ms21.chttl.com.tw (8.12.10/8.12.10) id i466dtnM027982; Thu, 6 May 2004 14:39:55 +0800
Received: from wcwang ([10.144.133.79]) by ms21.chttl.com.tw (8.12.10/8.12.10) with SMTP id i466dsL5027783; Thu, 6 May 2004 14:39:54 +0800
Message-ID: <010c01c43334$efc77a00$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Santoni Adriano" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Date: Thu, 6 May 2004 14:39:51 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

RFC 3280 does not ask CAs to replace all certificates at once for
migrating to UTF8String encoding. Instead, it suggest that
   "CAs MAY issue "name rollover" certificates to support an
     orderly migration to UTF8String encoding."

I believe that if relying parties use 3280-compliant certification path
validation modules, then they will not have problem for processing
"name rollover" certificates, and thus the migration to UTF8String
encoding will not be a problem.

One thing should be noted: a "name rollover" certificate is essentially
a "self-issued certificate" but its issuer name and subject name is in
different encoding. Therefore, the definition of "self-issued certificate"
should be changed a little. Also, since a "name rollover" certificate may
contains a NameConstraints extension in which the permittedSubtrees
and excludedSubtrees will be in a new encoding (e.g., UTF8String),
the path validation in RFC 3280 also need to be revised. I hope all of
these should be addressed in sonOfRfc3280.

I don't think that RFC 3280 mandates the support for UTF8String
encoding is "at odds with reality". There are many countries/regions
in the world where it is impossible to encode names in Printable String.
In Taiwan, we have already millions of certificates with issuer names
and subject names encoded in UTF8String.

Three years ago, I tested some VPN devices and found most of them
can not accept certificates with UTF8String (One of them even crashed
if received a certificate with UTF8String). Recently, I test many VPN
devices
again and amazingly found the all of them can normally handle certificates
with
UTF8String. All of them can chain and validate certificte paths that
contains
certificates with UTF8String. (Although, most of them still can not display
the
UTF8String in Chinese correctly. It is a pity.)

The truth is that there are more and more applications that can handling
UTF8String encoding. I think the credit should give to RFC 3280 for its
mandating  for UTF8String encoding.

Wen-Cheng Wang


----- Original Message ----- 
From: "Stefan Santesson" <[e-mail]>
To: "Stephen Kent" <[e-mail]>; "Santoni Adriano"
<[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Thursday, May 06, 2004 8:18 AM
Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encoding
RDNs


>
>
> Steve,
>
> There is one unfortunate side effect that makes this requirement worse
> than other evolutions of standards.
>
> It is almost never feasible to replace all certificates in a hierarchy
> at once. This means that you over time will have a mixed environment
> where e.g. the same organization name will exist in different encoding
> in many places of your hierarchy.
>
> It will then be virtually impossible to apply name constraining in such
> environment because RFC 3280 does not mandate the full X.500 name
> matching rules and a client may subsequently decide that names with
> different encoding is a no-match.
>
> This seams to be an unsolvable problem that, looking in the mirror, is
> inadequately addressed and shouldn't have passed in its current form. In
> fact it is probably a defect that needs to be addressed in sonOfRfc3280
> in one way or the other.
>
> /Stefan
>
>
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]]
> > On Behalf Of Stephen Kent
> > Sent: den 5 maj 2004 13:36
> > To: Santoni Adriano
> > Cc: '[e-mail]'; [e-mail]
> > Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
> encoding
> > RDNs
> >
> >
> > At 9:54 AM +0200 4/23/04, Santoni Adriano wrote:
> > >A rule that is "at odds with reality" should not be expressed in
> terms of
> > >MUST, but rather in terms of SHOULD. I wonder how it came that RFC
> 3280
> > >reached the status of an official IETF standard, if it contains one
> or
> > more
> > >areas that are "at odds with reality".
> > >
> > >I suppose the answer is one of these:
> > >- RFC 3280 does not really contain areas that are "at odds with
> reality"
> > -
> > >it's just that we do not understand them;
> >
> > RFC 3280 established a requirement for a change in how DNs are
> > encoded, for a future point in time. Thus, at the time the RFC was
> > published as a standard of course it did not match "reality." since
> > it was calling for a change.  By the way, this change was not the
> > idea of the PKIX WG but rather is consistent with the overall IETF
> > mandate to better accommodate character sets for a wide range of
> > languages.
> >
> > >- containing areas that are "at odds with reality" is not an obstacle
> to
> > >becoming a standard;
> >
> > Think of the implication of your comment. if we were never able to
> > call for a change in how things are done when we update a standard,
> > then we could never make any changes.  obviously this would be unduly
> > limiting.
> >
> > >- expressions like "MUST" in IETF standard are really to be taken as
> mere
> > >suggestions;
> >
> > IETF standards are voluntary. failure to comply is not punishable :-)
> >
> > >- nobody really cares.
> >
> > one might say that in environments where a few vendors or service
> > providers control a significant market share, their deviation from
> > standards, or failure to accommodate changes in standards, can have
> > profound impacts.
> >
> > Steve
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i460ITdt094135; Wed, 5 May 2004 17:18:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i460ITdg094134; Wed, 5 May 2004 17:18:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i460INdx094114 for <[e-mail]>; Wed, 5 May 2004 17:18:23 -0700 (PDT) (envelope-from [e-mail])
Received: from eur-imc-02.europe.corp.microsoft.com ([65.53.196.43]) by mail-eur.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 6 May 2004 01:18:19 +0100
Received: from 65.53.196.43 by eur-imc-02.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 06 May 2004 01:18:19 +0100
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); Thu, 6 May 2004 01:18:19 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Date: Thu, 6 May 2004 01:18:25 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Thread-Index: AcQy9mNaeqGq2v7ISTCu0K60y6EBLwAB9oWg
From: "Stefan Santesson" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Santoni Adriano" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 06 May 2004 00:18:19.0077 (UTC) FILETIME=[A2185750:01C432FF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i460INdx094124
Sender: [e-mail]
Precedence: 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,

There is one unfortunate side effect that makes this requirement worse
than other evolutions of standards.

It is almost never feasible to replace all certificates in a hierarchy
at once. This means that you over time will have a mixed environment
where e.g. the same organization name will exist in different encoding
in many places of your hierarchy.

It will then be virtually impossible to apply name constraining in such
environment because RFC 3280 does not mandate the full X.500 name
matching rules and a client may subsequently decide that names with
different encoding is a no-match.

This seams to be an unsolvable problem that, looking in the mirror, is
inadequately addressed and shouldn't have passed in its current form. In
fact it is probably a defect that needs to be addressed in sonOfRfc3280
in one way or the other.

/Stefan


> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Stephen Kent
> Sent: den 5 maj 2004 13:36
> To: Santoni Adriano
> Cc: '[e-mail]'; [e-mail]
> Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in
encoding
> RDNs
> 
> 
> At 9:54 AM +0200 4/23/04, Santoni Adriano wrote:
> >A rule that is "at odds with reality" should not be expressed in
terms of
> >MUST, but rather in terms of SHOULD. I wonder how it came that RFC
3280
> >reached the status of an official IETF standard, if it contains one
or
> more
> >areas that are "at odds with reality".
> >
> >I suppose the answer is one of these:
> >- RFC 3280 does not really contain areas that are "at odds with
reality"
> -
> >it's just that we do not understand them;
> 
> RFC 3280 established a requirement for a change in how DNs are
> encoded, for a future point in time. Thus, at the time the RFC was
> published as a standard of course it did not match "reality." since
> it was calling for a change.  By the way, this change was not the
> idea of the PKIX WG but rather is consistent with the overall IETF
> mandate to better accommodate character sets for a wide range of
> languages.
> 
> >- containing areas that are "at odds with reality" is not an obstacle
to
> >becoming a standard;
> 
> Think of the implication of your comment. if we were never able to
> call for a change in how things are done when we update a standard,
> then we could never make any changes.  obviously this would be unduly
> limiting.
> 
> >- expressions like "MUST" in IETF standard are really to be taken as
mere
> >suggestions;
> 
> IETF standards are voluntary. failure to comply is not punishable :-)
> 
> >- nobody really cares.
> 
> one might say that in environments where a few vendors or service
> providers control a significant market share, their deviation from
> standards, or failure to accommodate changes in standards, can have
> profound impacts.
> 
> Steve




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45LgfZ4075701; Wed, 5 May 2004 14:42:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i45Lgeu3075684; Wed, 5 May 2004 14:42:40 -0700 (PDT)
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.9) with ESMTP id i45LgclD075503 for <[e-mail]>; Wed, 5 May 2004 14:42:38 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.33.244.157] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i45Lg77l000994; Wed, 5 May 2004 17:42:25 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0610050bbcbeff0ab6f6@[128.33.244.157]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Wed, 5 May 2004 16:36:24 -0400
To: Santoni Adriano <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: R: I: R: RFC3280: doubt on the use of UTF8String in encoding RDNs
Cc: "'[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 9:54 AM +0200 4/23/04, Santoni Adriano wrote:
>A rule that is "at odds with reality" should not be expressed in terms of
>MUST, but rather in terms of SHOULD. I wonder how it came that RFC 3280
>reached the status of an official IETF standard, if it contains one or more
>areas that are "at odds with reality".
>
>I suppose the answer is one of these:
>- RFC 3280 does not really contain areas that are "at odds with reality" -
>it's just that we do not understand them;

RFC 3280 established a requirement for a change in how DNs are 
encoded, for a future point in time. Thus, at the time the RFC was 
published as a standard of course it did not match "reality." since 
it was calling for a change.  By the way, this change was not the 
idea of the PKIX WG but rather is consistent with the overall IETF 
mandate to better accommodate character sets for a wide range of 
languages.

>- containing areas that are "at odds with reality" is not an obstacle to
>becoming a standard;

Think of the implication of your comment. if we were never able to 
call for a change in how things are done when we update a standard, 
then we could never make any changes.  obviously this would be unduly 
limiting.

>- expressions like "MUST" in IETF standard are really to be taken as mere
>suggestions;

IETF standards are voluntary. failure to comply is not punishable :-)

>- nobody really cares.

one might say that in environments where a few vendors or service 
providers control a significant market share, their deviation from 
standards, or failure to accommodate changes in standards, can have 
profound impacts.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45LTvPn073809; Wed, 5 May 2004 14:29:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i45LTv5l073808; Wed, 5 May 2004 14:29:57 -0700 (PDT)
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.9) with ESMTP id i45LTufq073784 for <[e-mail]>; Wed, 5 May 2004 14:29:56 -0700 (PDT) (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 i45LTu6b004927 for <[e-mail]>; Wed, 5 May 2004 14:29:56 -0700 (PDT)
Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) id <[e-mail]> for [e-mail]; Wed, 05 May 2004 17:29:55 -0400 (EDT)
Received: from sun.com (dhcp-ubur02-75-154.East.Sun.COM [129.148.75.154]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <[e-mail]>; Wed, 05 May 2004 17:29:55 -0400 (EDT)
Date: Wed, 05 May 2004 17:26:00 -0400
From: Steve Hanna <[e-mail]>
Subject: Re: Cross certificate format
In-reply-to:  <[e-mail]>
To: Tom Gindin <[e-mail]>
Cc: Santosh Chokhani <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
Content-type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary=------------ms060201000805020401020705
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20031111
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>

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

See section 6.2 of RFC 3280, which says:

    ...  An implementation that supports multiple trust anchors
    MAY augment the algorithm presented in section 6.1 to further limit
    the set of valid certification paths which begin with a particular
    trust anchor.  For example, an implementation MAY modify the
    algorithm to apply name constraints to a specific trust anchor during
    the initialization phase, or the application MAY require the presence
    of a particular alternative name form in the end entity certificate,
    or the application MAY impose requirements on application-specific
    extensions.  Thus, the path validation algorithm presented in section
    6.1 defines the minimum conditions for a path to be considered valid.

There's no need to change RFC 3280 to allow
path validation implementations to apply
name constraints to trust anchors. That's
explicitly discussed in this section of the RFC.

Thanks,

Steve

Tom Gindin wrote:
>         Santosh:
> 
>         Of course, defining a trust anchor implies that the RP trusts the 
> anchor's public key as an issuer for at least some purposes.  RFC 3280, in 
> the parts of section 6.1.2 I cited, appears to forbid those state 
> variables from being set from information defined by the RP or stored with 
> the trust anchor.  This is consistent with its statements in 6.1.1 d which 
> permit self-signed certificates but say nothing about other CA 
> certificates.  As is probably clear to everyone reading this thread, I 
> think that this is not an ideal set of suggestions.
>         The current standard does contain some constraints on the trust 
> anchor (notably inhibit-policy-mapping), but neither name constraints nor 
> basic constraints.  I consider this an anomaly.  If I had free rein in 
> rewording pieces of RFC 3280 section 6.1, I would change this wording to 
> allow CA certificates along with self-signed ones as anchors and create 
> extra optional (and optional to support) fields to be set from the trust 
> anchor.
>         I don't think that this is particularly inconsistent with general 
> security principles, or with any part of X.509 with which I am familiar. 
> It does represent an extension of RFC 3280 section 6, and it is only 
> backward compatible with it, so it may be out of scope.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[e-mail]>
> Sent by: [e-mail]
> 05/01/2004 06:46 PM
> 
>  
>         To:     <[e-mail]>
>         cc: 
>         Subject:        RE: Cross certificate format
> 
> 
> 
> 
> Tom:
> 
> The standard does not require you to check how you initialize the 
> variables.
> You can get these from the cross certificate or from some configuration.
> 
> The basic point is that you trust the public key.  How you constrain it is
> not address by the standard, where as if the same certificate appeared in 
> a
> path, you have to apply the constraints or be not compliant with the
> standard.
> 
> You obviously do not believe in re-incarnation.  Just kidding......
> 
> -----Original Message-----
> From: Tom Gindin [mailto:[e-mail]] 
> Sent: Saturday, May 01, 2004 6:31 PM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: RE: Cross certificate format
> 
> 
>         Santosh:
> 
>         It is well known that trust in a trust anchor can be defined in a 
> variety of ways.  However, there is every reason to think that an RP may 
> constrain that trust and that the constraints he may apply include those 
> which an issuer CA may apply to a subordinate one. The wording of RFC 3280 
> 
> section 6.2's first paragraph is an example of this.
>         My comments about the meaning of a trust anchor are not purely 
> theoretical.  If a cross certificate is used to represent a trust anchor, 
> the variables permitted_subtrees (RFC 3280 6.1.2 b) and excluded_subtrees 
> (RFC 3280 6.1.2 c) could easily be set from the contents of a 
> NameConstraints extension, and the variable max_path_length (RFC 3280 
> 6.1.2 k) from the contents of a BasicConstraints extension.  In RFC 3280 
> today, these variables are set to constants (although that interpretation 
> is not absolutely clear for permitted_subtrees).  In fact, they are three 
> of the four variables which are set to constants during initialization.
>         If permitted subtrees were set to a list of attributes, the 
> validation process would fail if the anchor CA or a CA it certified went 
> beyond the restrictions of those attributes.  Likewise, if the excluded 
> subtrees were set to a list of attributes, the validation process would 
> fail if the anchor CA or a CA it certified went used values matching any 
> of those attributes.  I do not believe that I am arguing against Galileo.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[e-mail]>
> Sent by: [e-mail]
> 04/29/2004 11:12 PM
> 
>  
>         To:     <[e-mail]>
>         cc: 
>         Subject:        RE: Cross certificate format
> 
> 
> 
> 
> Tom:
> 
> The basic point (at the risk of repeating myself) is that a CA certificate
> or a self-signed certificate can be used as a means to provide trust 
> anchor
> information.  In that case, there is no need to check signature or 
> anything.
> 
> But, when the CA certificate is a certificate in the certificate path, 
> X.509
> logic kicks in.
> 
> This is consistent with X.509, 3280 and general security principles since
> the trust in a trust anchor can be derived through any number of means.
> 
> If you do not agree, feel free to argue against the definitions and 
> Galileo
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On
> Behalf Of Tom Gindin
> Sent: Thursday, April 29, 2004 8:43 PM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: RE: Cross certificate format
> 
> 
> 
>         Santosh:
> 
>         I don't think that a CA certificate and a trust anchor are as much 
> 
> 
> different things as different uses for the same thing.  They are both 
> identifiers of issuers which bind a public key to an issuer name, and it 
> is perfectly appropriate for any CA certificate to represent a trust 
> anchor.  I also do not see why such things as name constraints on a trust 
> anchor are inappropriate.  It is perfectly true that verifying a trust 
> anchor's certificate, when issued by another CA (who may not be trusted) 
> is a pointless operation.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[e-mail]>
> Sent by: [e-mail]
> 04/27/2004 09:14 AM
> 
>  
>         To:     <[e-mail]>
>         cc: 
>         Subject:        RE: Cross certificate format
> 
> 
> 
> 
> Tom:
> 
> My point is that even if the trust anchor is a self-signed certificate, 
> all
> you need to do is extract the required information.  There is no need to
> examine anything.
> 
> Cross certificate and trust anchor are very different things.  An element 
> of
> the cross certificate pair is nothing but an intermediate CA certificate 
> in
> a certification path.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On
> Behalf Of Tom Gindin
> Sent: Tuesday, April 27, 2004 7:33 AM
> To: Santosh Chokhani
> Cc: [e-mail]; [e-mail]
> Subject: RE: Cross certificate format
> 
> 
> 
>         Santosh:
> 
>         Of course, you are right that RFC 3280 6.1.1 d permits trust 
> anchor information to be provided outside a certificate.  If it is so, no 
> checks of the sort I indicated can be performed.  It also says that it can 
> 
> 
> 
> be provided as "a self-signed certificate", with no further qualification. 
> 
> 
> 
>  I do think it is somewhat odd that a self-signed certificate with 
> KeyUsage set to typical EE values would be considered a valid issuer as a 
> trust anchor while a cross certificate would not.  You can always extract 
> the needed anchor information from a cross-certificate, of course.
> 
>                 Tom Gindin
> 
> 
> 
> 
> 
> "Santosh Chokhani" <[e-mail]>
> Sent by: [e-mail]
> 04/26/2004 08:51 AM
> 
>  
>         To:     <[e-mail]>
>         cc: 
>         Subject:        RE: Cross certificate format
> 
> 
> 
> 
> Tom:
> 
> My reading of 3280 and X.509 is that a trust anchor need not even be a
> certificate.  Thus, no checks need to be performed on a trust anchor at 
> all.
> You get the DN, public key, algorithm OID, and parameters (if applicable)
> from a trust anchor.  Any checks are gratuitous and not required by either
> standard.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On
> Behalf Of Tom Gindin
> Sent: Sunday, April 25, 2004 7:06 PM
> To: Jean-Marc Desperrier
> Cc: [e-mail]
> Subject: Re: Cross certificate format
> 
> 
> 
>         Jean-Marc:
> 
>         RFC 3280 doesn't say that anywhere.  It does say that you don't 
> need to validate the trust anchor as part of the path, but it isn't clear 
> from the text that a v1 certificate is acceptable as a trust anchor - and 
> it certainly isn't clear that a v1 certificate is acceptable as an issuer 
> if it is a trust anchor while a v3 certificate with KeyUsage= { 
> DigitalSignature, keyEncipherment } is not acceptable as an issuer even if 
> 
> 
> 
> 
> it is a trust anchor.
>         I believe that the correct rules for versions are something like 
> the following: a certificate issued by a trust anchor which is represented 
> 
> 
> 
> 
> by a certificate is verifiable if the anchor certificate is either a v1 
> certificate or a v3 certificate with the CA flag present in the 
> basicConstraints extension.  If the anchor certificate is a v3 certificate 
> 
> 
> 
> 
> with the KeyUsage extension present, it is only a valid issuer certificate 
> 
> 
> 
> 
> if keyCertSign is set.
> 
>         Tom Gindin
> 
> 
> 
> 
> 
> Jean-Marc Desperrier <[e-mail]>
> Sent by: [e-mail]
> 04/21/2004 03:42 PM
> 
>  
>         To:     [e-mail]
>         cc: 
>         Subject:        Re: Cross certificate format
> 
> 
> 
> 
> Tom Gindin wrote:
> 
> 
>>       RFC 3280 does not support the use of v1 self-signed
>>certificates,
> 
> 
>>which contain no extensions at all (see the text of RFC 3280's 
>>basicConstraints section).  However, a number of public CA's still have 
>>them.
>>
>>
> 
> Applications implementing the path validation algorithm of RFC3280 MUST 
> accept them when they are used as trust anchors.
>  
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJNzCC
AvYwggJfoAMCAQICAww3ZDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE
ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv
bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDI4MjEwMTE0WhcNMDUwNDI4MjEwMTE0
WjBoMQ4wDAYDVQQEEwVIYW5uYTEVMBMGA1UEKhMMU3RlcGhlbiBSb3NzMRswGQYDVQQDExJT
dGVwaGVuIFJvc3MgSGFubmExIjAgBgkqhkiG9w0BCQEWE3N0ZXZlLmhhbm5hQHN1bi5jb20w
ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC11rLYp70KnKGmV6pNTFRhWBwq47mV
4hU6EaZxo6I3Vw96Rd3E4TH3SAthIl5N4/tpiMPtlTBiJOU6QHSlz1DgTCclmTK6taqtEyLq
amez8vYgSdOEnOFRYILptjbEwpE+yeUmFKOmZ7zSwBMqRQatMHMaLVUJJ3Ygw1V7fKSwvVU0
OJ8c+c3sJRtRyDLxq/vMzYQP+wyqRqlJPTHGFqVuMp0FZIV5X76z+O+W90m9jXjirz91Jz+W
N6rwqmPi8Qy0uxBKm6NKT1371p+WYaK9OfGk8vGbJ8ZsTP3DyQhuuemYPbkKPtoII6WnHIGT
/DOy2G7gff7GOIhUrs7PziddAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3N0ZXZlLmhhbm5hQHN1
bi5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB++aOP6sZVYlqBGc92hZ61
FHST+OqnKZHRGkqEO94RoxdeaSUFKVO2IaKLMBmqNzmh3N3pIsIKiLhJNvDgLhlRrMRVfR29
uixjTsprR26AacMx/gCiCstGIjkzTb83xAvZay5hnzUmlt/LSNX8e6jTNav6LP64WC+C7Tul
fM/PzDCCAvYwggJfoAMCAQICAww3ZDANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDI4MjEwMTE0WhcNMDUwNDI4
MjEwMTE0WjBoMQ4wDAYDVQQEEwVIYW5uYTEVMBMGA1UEKhMMU3RlcGhlbiBSb3NzMRswGQYD
VQQDExJTdGVwaGVuIFJvc3MgSGFubmExIjAgBgkqhkiG9w0BCQEWE3N0ZXZlLmhhbm5hQHN1
bi5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC11rLYp70KnKGmV6pNTFRh
WBwq47mV4hU6EaZxo6I3Vw96Rd3E4TH3SAthIl5N4/tpiMPtlTBiJOU6QHSlz1DgTCclmTK6
taqtEyLqamez8vYgSdOEnOFRYILptjbEwpE+yeUmFKOmZ7zSwBMqRQatMHMaLVUJJ3Ygw1V7
fKSwvVU0OJ8c+c3sJRtRyDLxq/vMzYQP+wyqRqlJPTHGFqVuMp0FZIV5X76z+O+W90m9jXji
rz91Jz+WN6rwqmPi8Qy0uxBKm6NKT1371p+WYaK9OfGk8vGbJ8ZsTP3DyQhuuemYPbkKPtoI
I6WnHIGT/DOy2G7gff7GOIhUrs7PziddAgMBAAGjMDAuMB4GA1UdEQQXMBWBE3N0ZXZlLmhh
bm5hQHN1bi5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQB++aOP6sZVYlqB
Gc92hZ61FHST+OqnKZHRGkqEO94RoxdeaSUFKVO2IaKLMBmqNzmh3N3pIsIKiLhJNvDgLhlR
rMRVfR29uixjTsprR26AacMx/gCiCstGIjkzTb83xAvZay5hnzUmlt/LSNX8e6jTNav6LP64
WC+C7TulfM/PzDCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYT
AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE
ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqG
SIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBa
Fw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs
dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz
dWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRw
nd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn
8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJg
t/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0
dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1Ud
DwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJ
KoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A
9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH
1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJ
BgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYD
VQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDDdkMAkGBSsOAwIa
BQCgggGnMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDUw
NTIxMjYwMFowIwYJKoZIhvcNAQkEMRYEFA7Sw9pTNCo0RINQDXkZNeztKBdaMFIGCSqGSIb3
DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcG
BSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgGCSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0
ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMMN2QwegYLKoZIhvcNAQkQAgsxa6Bp
MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu
MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDDdkMA0G
CSqGSIb3DQEBAQUABIIBAFFama7Nna/e3h+Ypq7znMk0R60dcDB/qtbY2bj5RSAnJzeSiDQL
GgiGRrx/1CuHNaPw0HPrj388hBX7rfMyvHCOCclNb+JV/4CuAyYzCqbZaNmD/KTRPnv41Yit
SqfDPgDbLfpBzym+SF/Yc3YxXQObkd2NOG4EpmpmmYhYrMpdlKvR+q4JEXDbWs94KF4ymiiB
A/Mbt8vmorCdT7Lww/631p0JUrKrTq0NwFy4EKxtZiEHpjavbZ9WzH5HdDk0+HQVAXLiCmGp
7urjS+JQEdSOYtjZn8hu/J+Qcz4pvOJvguDaTI1uVVE1jFuwQqfOwbHAQYoyHH9Jle1sVJkF
kqcAAAAAAAA=
--------------ms060201000805020401020705--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45L7Q8X070245; Wed, 5 May 2004 14:07:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i45L7QvO070244; Wed, 5 May 2004 14:07:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45L7Pbq070223 for <[e-mail]>; Wed, 5 May 2004 14:07:25 -0700 (PDT) (envelope-from [e-mail])
Received: from eur-imc-02.europe.corp.microsoft.com ([65.53.196.43]) by mail-eur.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 5 May 2004 22:07:20 +0100
Received: from 65.53.196.43 by eur-imc-02.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 05 May 2004 22:07:20 +0100
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); Wed, 5 May 2004 22:07:20 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-6cde8b41-7c06-442b-8e82-16cb7cf52a86"
Subject: RFC 3280 bug in name constraints
Date: Wed, 5 May 2004 22:07:19 +0100
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: RFC 3280 bug in name constraints
Thread-Index: AcQy5PNxPgauBM6ETtWBvVkKktiG8A==
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 05 May 2004 21:07:20.0309 (UTC) FILETIME=[F4231A50:01C432E4]
Sender: [e-mail]
Precedence: 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.

------=_NextPartTM-000-6cde8b41-7c06-442b-8e82-16cb7cf52a86
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C432E4.F54FFCD5"

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

If someone is keeping record of bugs for future update of RFC 3280 I
have a small one to file about name constraints.

=20

In section 4.2.1.11, starting at bottom of page 38:

=20

   When rfc822 names are constrained, but the

   certificate does not include a subject alternative name, the rfc822

   name constraint MUST be applied to the attribute of type EmailAddress

   in the subject distinguished name.

=20

Suppose/suggest that the intended meaning is:

=20

   When rfc822 names are constrained, but the certificate does not=20

   include an rfc822Name in a subject alternative name extension, the
rfc822

   name constraint MUST be applied to the attribute of type EmailAddress

   in the subject distinguished name.

=20

=20

Rationale:

Why would the constraint NOT apply to EmailAddress just because there is
a SubjAltName extension with e.g. just some unrelated other name
component present?

=20

/Stefan

=20


------_=_NextPart_001_01C432E4.F54FFCD5
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)">
<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:595.3pt 841.9pt;
	margin:3.0cm 2.0cm 3.0cm 2.0cm;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>If someone is keeping record of bugs for =
future update
of RFC 3280 I have a small one to file about name =
constraints.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
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 lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>In section 4.2.1.11, starting at bottom of =
page 38:<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;&nbsp; When rfc822 names are =
constrained, but
the<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;&nbsp; certificate does not include a =
subject
alternative name, the rfc822<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;&nbsp; name constraint MUST be applied =
to the
attribute of type EmailAddress<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp; in the =
subject
distinguished name.</span></font><font size=3D2 face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
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 lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Suppose/suggest that the intended meaning =
is:<o:p></o:p></span></font></p>

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

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;&nbsp; When rfc822 names are =
constrained, but
the certificate does not <o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;&nbsp; include an rfc822Name in a =
subject
alternative name extension, the rfc822<o:p></o:p></span></font></p>

<p class=3DMsoPlainText><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt'>&nbsp;&nbsp; name constraint MUST be applied =
to the
attribute of type EmailAddress<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3D"Courier New"><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:"Courier New"'>&nbsp;&nbsp; in the =
subject
distinguished name.</span></font><font size=3D2 face=3DArial><span =
lang=3DEN-US
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=
>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
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 lang=3DEN-US =
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 lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Rationale:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>Why would the constraint NOT apply to =
EmailAddress
just because there is a SubjAltName extension with e.g. just some =
unrelated other
name component present?<o:p></o:p></span></font></p>

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

<div>

<div>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-US =
style=3D'font-size:
10.0pt;font-family:Arial'>/Stefan<font color=3Dblack><span =
style=3D'color:black'><o:p></o:p></span></font></span></font></p>

</div>

</div>

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

</div>

</body>

</html>

------_=_NextPart_001_01C432E4.F54FFCD5--

------=_NextPartTM-000-6cde8b41-7c06-442b-8e82-16cb7cf52a86--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45HQLRI045092; Wed, 5 May 2004 10:26:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i45HQLfA045091; Wed, 5 May 2004 10:26:21 -0700 (PDT)
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.9) with ESMTP id i45HQKgp045084 for <[e-mail]>; Wed, 5 May 2004 10:26:20 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (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 i45HQLMM024084 for <[e-mail]>; Wed, 5 May 2004 13:26:21 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Cross certificate format
Date: Wed, 5 May 2004 13:26:15 -0400
Message-ID: <015901c432c6$1522eba0$[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.6626
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom:

I think we agree on what the standards currently do not require any checks.

X.509 is being revised (since I do not keep track of the process -- X.509
change may have been approved for all know) to permit the relying party to
specify these values.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Tom Gindin
Sent: Tuesday, May 04, 2004 11:39 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Cross certificate format



        Santosh:

        Of course, defining a trust anchor implies that the RP trusts the 
anchor's public key as an issuer for at least some purposes.  RFC 3280, in 
the parts of section 6.1.2 I cited, appears to forbid those state 
variables from being set from information defined by the RP or stored with 
the trust anchor.  This is consistent with its statements in 6.1.1 d which 
permit self-signed certificates but say nothing about other CA 
certificates.  As is probably clear to everyone reading this thread, I 
think that this is not an ideal set of suggestions.
        The current standard does contain some constraints on the trust 
anchor (notably inhibit-policy-mapping), but neither name constraints nor 
basic constraints.  I consider this an anomaly.  If I had free rein in 
rewording pieces of RFC 3280 section 6.1, I would change this wording to 
allow CA certificates along with self-signed ones as anchors and create 
extra optional (and optional to support) fields to be set from the trust 
anchor.
        I don't think that this is particularly inconsistent with general 
security principles, or with any part of X.509 with which I am familiar. 
It does represent an extension of RFC 3280 section 6, and it is only 
backward compatible with it, so it may be out of scope.

                Tom Gindin





"Santosh Chokhani" <[e-mail]>
Sent by: [e-mail]
05/01/2004 06:46 PM

 
        To:     <[e-mail]>
        cc: 
        Subject:        RE: Cross certificate format




Tom:

The standard does not require you to check how you initialize the 
variables.
You can get these from the cross certificate or from some configuration.

The basic point is that you trust the public key.  How you constrain it is
not address by the standard, where as if the same certificate appeared in 
a
path, you have to apply the constraints or be not compliant with the
standard.

You obviously do not believe in re-incarnation.  Just kidding......

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]] 
Sent: Saturday, May 01, 2004 6:31 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Cross certificate format


        Santosh:

        It is well known that trust in a trust anchor can be defined in a 
variety of ways.  However, there is every reason to think that an RP may 
constrain that trust and that the constraints he may apply include those 
which an issuer CA may apply to a subordinate one. The wording of RFC 3280 

section 6.2's first paragraph is an example of this.
        My comments about the meaning of a trust anchor are not purely 
theoretical.  If a cross certificate is used to represent a trust anchor, 
the variables permitted_subtrees (RFC 3280 6.1.2 b) and excluded_subtrees 
(RFC 3280 6.1.2 c) could easily be set from the contents of a 
NameConstraints extension, and the variable max_path_length (RFC 3280 
6.1.2 k) from the contents of a BasicConstraints extension.  In RFC 3280 
today, these variables are set to constants (although that interpretation 
is not absolutely clear for permitted_subtrees).  In fact, they are three 
of the four variables which are set to constants during initialization.
        If permitted subtrees were set to a list of attributes, the 
validation process would fail if the anchor CA or a CA it certified went 
beyond the restrictions of those attributes.  Likewise, if the excluded 
subtrees were set to a list of attributes, the validation process would 
fail if the anchor CA or a CA it certified went used values matching any 
of those attributes.  I do not believe that I am arguing against Galileo.

                Tom Gindin






"Santosh Chokhani" <[e-mail]>
Sent by: [e-mail]
04/29/2004 11:12 PM

 
        To:     <[e-mail]>
        cc: 
        Subject:        RE: Cross certificate format




Tom:

The basic point (at the risk of repeating myself) is that a CA certificate
or a self-signed certificate can be used as a means to provide trust 
anchor
information.  In that case, there is no need to check signature or 
anything.

But, when the CA certificate is a certificate in the certificate path, 
X.509
logic kicks in.

This is consistent with X.509, 3280 and general security principles since
the trust in a trust anchor can be derived through any number of means.

If you do not agree, feel free to argue against the definitions and 
Galileo

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
On
Behalf Of Tom Gindin
Sent: Thursday, April 29, 2004 8:43 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Cross certificate format



        Santosh:

        I don't think that a CA certificate and a trust anchor are as much 


different things as different uses for the same thing.  They are both 
identifiers of issuers which bind a public key to an issuer name, and it 
is perfectly appropriate for any CA certificate to represent a trust 
anchor.  I also do not see why such things as name constraints on a trust 
anchor are inappropriate.  It is perfectly true that verifying a trust 
anchor's certificate, when issued by another CA (who may not be trusted) 
is a pointless operation.

                Tom Gindin





"Santosh Chokhani" <[e-mail]>
Sent by: [e-mail]
04/27/2004 09:14 AM

 
        To:     <[e-mail]>
        cc: 
        Subject:        RE: Cross certificate format




Tom:

My point is that even if the trust anchor is a self-signed certificate, 
all
you need to do is extract the required information.  There is no need to
examine anything.

Cross certificate and trust anchor are very different things.  An element 
of
the cross certificate pair is nothing but an intermediate CA certificate 
in
a certification path.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
On
Behalf Of Tom Gindin
Sent: Tuesday, April 27, 2004 7:33 AM
To: Santosh Chokhani
Cc: [e-mail]; [e-mail]
Subject: RE: Cross certificate format



        Santosh:

        Of course, you are right that RFC 3280 6.1.1 d permits trust 
anchor information to be provided outside a certificate.  If it is so, no 
checks of the sort I indicated can be performed.  It also says that it can 



be provided as "a self-signed certificate", with no further qualification. 



 I do think it is somewhat odd that a self-signed certificate with 
KeyUsage set to typical EE values would be considered a valid issuer as a 
trust anchor while a cross certificate would not.  You can always extract 
the needed anchor information from a cross-certificate, of course.

                Tom Gindin





"Santosh Chokhani" <[e-mail]>
Sent by: [e-mail]
04/26/2004 08:51 AM

 
        To:     <[e-mail]>
        cc: 
        Subject:        RE: Cross certificate format




Tom:

My reading of 3280 and X.509 is that a trust anchor need not even be a
certificate.  Thus, no checks need to be performed on a trust anchor at 
all.
You get the DN, public key, algorithm OID, and parameters (if applicable)
from a trust anchor.  Any checks are gratuitous and not required by either
standard.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
On
Behalf Of Tom Gindin
Sent: Sunday, April 25, 2004 7:06 PM
To: Jean-Marc Desperrier
Cc: [e-mail]
Subject: Re: Cross certificate format



        Jean-Marc:

        RFC 3280 doesn't say that anywhere.  It does say that you don't 
need to validate the trust anchor as part of the path, but it isn't clear 
from the text that a v1 certificate is acceptable as a trust anchor - and 
it certainly isn't clear that a v1 certificate is acceptable as an issuer 
if it is a trust anchor while a v3 certificate with KeyUsage= { 
DigitalSignature, keyEncipherment } is not acceptable as an issuer even if 




it is a trust anchor.
        I believe that the correct rules for versions are something like 
the following: a certificate issued by a trust anchor which is represented 




by a certificate is verifiable if the anchor certificate is either a v1 
certificate or a v3 certificate with the CA flag present in the 
basicConstraints extension.  If the anchor certificate is a v3 certificate 




with the KeyUsage extension present, it is only a valid issuer certificate 




if keyCertSign is set.

        Tom Gindin





Jean-Marc Desperrier <[e-mail]>
Sent by: [e-mail]
04/21/2004 03:42 PM

 
        To:     [e-mail]
        cc: 
        Subject:        Re: Cross certificate format




Tom Gindin wrote:

>        RFC 3280 does not support the use of v1 self-signed 
> certificates,

>which contain no extensions at all (see the text of RFC 3280's
>basicConstraints section).  However, a number of public CA's still have 
>them.
> 
>
Applications implementing the path validation algorithm of RFC3280 MUST 
accept them when they are used as trust anchors.
 






















Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45Eeh7F031171; Wed, 5 May 2004 07:40:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i45EehUj031169; Wed, 5 May 2004 07:40:43 -0700 (PDT)
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.11/8.12.9) with ESMTP id i45EefgQ031150 for <[e-mail]>; Wed, 5 May 2004 07:40:42 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id i45EebN25746; Wed, 5 May 2004 16:40:37 +0200 (MEST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 5 May 2004 16:40:38 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id i45EebQ22331; Wed, 5 May 2004 16:40:37 +0200 (MEST)
Date: Wed, 5 May 2004 16:40:37 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: FW: scvp
Cc: [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>

- Is there a difference between asking for a key usage of certsign
  and setting the isCA flag?

- For an extendedkeyusage, is the server supposed to chacek whether
  there are the acceptable keyusages in the certificat? I think,
  yes, this should be made more precisely mentioned. 




  



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45Dts72024888; Wed, 5 May 2004 06:55:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i45Dtsnk024887; Wed, 5 May 2004 06:55:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from avir1.bancsabadell.com (tm01.bancsabadell.com [194.224.15.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45DtqV5024872 for <[e-mail]>; Wed, 5 May 2004 06:55:53 -0700 (PDT) (envelope-from [e-mail])
Received: from EFYBEM279076 (privadas.nuria.telefonica-data.net [172.18.16.2]) by mail.bancsabadell.com; Wed, 05 May 2004 15:52:53 +0200
From: =?iso-8859-1?Q?Carlos_Gonz=E1lez-Cadenas?= <[e-mail]>
To: <[e-mail]>
Subject: DataEncipherment
Date: Wed, 5 May 2004 15:54:26 +0200
Organization: e-xtendforce
Message-ID: <002901c432a8$7acb60e0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002A_01C432B9.3E5430E0"
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.1409
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_002A_01C432B9.3E5430E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable




Hi,

=0D

Just a question about keyUsage DataEncipherment.

=0D

In a RSA-based certificate (the public key included is coming from a RSA=
 key
pair), If I assert the DataEncipherment key usage, I=92m telling to the
relying third parties that my certificate (the public key included into)=
 can
be used for raw data encipherment, but, in the reality, RSA algorithm=
 cannot
be used to cipher large amounts of data (as opposed to a symmetric key, in,
for example, a CBC mode). The common technique with that is to use the
keyEncipherment bit to be able to cipher the symmetric session key used to
cipher the raw data.

=0D

Can anyone point me to the right direction, or provide me some links to
technical documentation, about real-life usages with the Data Encipherment
key usage??. Are there any other technologies/algorithms for RSA where this
key usage has more sense??.

=0D

Thank you very much in advance


Carlos

=0D

Carlos Gonz=E1lez-Cadenas
Jefe de Departamento de Arquitectura Software
Software Architecture Department Manager=0D
Responsable de Seguridad de la Informaci=F3n
Information Security Responsible=0D

e-xtendforce
by e-xtendnow BancSabadell=0D

C/Sena,12 nucli C planta 2
Edifici Landscape
08190 Sant Cugat del Vall=E8s
phone: [phone]
fax: [phone]
mailto:  <mailto:[e-mail]>
[e-mail]=0D

=0D



=0D
Advertencia legal:
Este mensaje y, en su caso, los ficheros anexos son confidenciales,
especialmente en lo que respecta a los datos personales, y se dirigen
exclusivamente al destinatario referenciado. Si usted no lo es y lo ha
recibido por error o tiene conocimiento del mismo por cualquier motivo, le
rogamos que nos lo comunique por este medio y proceda a destruirlo o=
 borrarlo,
y que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o
comunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo=
 pena
de incurrir en responsabilidades legales. El emisor no garantiza la=
 integridad,
rapidez o seguridad del presente correo, ni se responsabiliza de posibles
perjuicios derivados de la captura, incorporaciones de virus o cualesquiera
otras manipulaciones efectuadas por terceros.

=0D
Advertiment legal:
Aquest missatge i, si escau, els fitxers annexos tenen caire confidencial,
especialment pel que fa a les dades personals, i s'adrecen exclusivament al
destinatari referenciat. Si no es tracta d'aquest i l'ha rebut per error o=
 se li
ha fet arribar per qualsevol motiu, li preguem que ens ho comuniqui per=
 aquesta
mateixa via i el destrueixi o l'esborri, i que en tot cas s'abstingui=
 d'utilitzar,
reproduir, alterar, arxivar o comunicar a tercers aquest missatge i fitxers
annexos, tot sota pena d'entrar en responsabilitats legals. L'emissor no=
 garanteix
la integritat, la rapidesa o la seguretat d'aquest correu, ni es=
 responsabilitza
de possibles perjudicis derivats de la captura, incorporacions de virus o
qualsevol altres manipulacions que facin tercers.

=0D
Disclaimer:
This message and any attached files transmitted with it, is confidential,
especially as regards personal data. It is intended solely for the use of=
 the
individual or entity to whom it is addressed. If you are not the intended=
 recipient
and have received this information in error or have accessed it for any=
 reason,
please notify us of this fact by email reply and then destroy or delete the=
 message,
refraining from any reproduction, use, alteration, filing or communication=
 to third
parties of this message and attached files on penalty of incurring legal
responsibilities. The sender does not guarantee the integrity, the=
 accuracy, the
swift delivery or the security of this email transmission, and assumes no
responsibility for any possible damage incurred through data capture, virus
incorporation or any manipulation carried out by third parties.
------=_NextPart_000_002A_01C432B9.3E5430E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=
=3Diso-8859-1">


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

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Palatino Linotype";
	panose-1:2 4 5 2 5 5 5 3 3 4;}
@font-face
	{font-family:Verdana;
	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:"Palatino Linotype";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EstiloCorreo17
	{font-family:Arial;
	color:windowtext;}
span.name1
	{font-weight:bold;}
span.logo1
	{font-weight:bold;}
span.textlogo1
	{color:#999999;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

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

<div class=3DSection1>

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

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>Just a question about keyUsage=
 DataEncipherment.</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>In a RSA-based certificate (the public key=
 included
is coming from a RSA key pair), If I assert the DataEncipherment key usage,=
 I&#8217;m
telling to the relying third parties that my certificate (the public key
included into) can be used for raw data encipherment, but, in the reality,=
 RSA
algorithm cannot be used to cipher large amounts of data (as opposed to a
symmetric key, in, for example, a CBC mode). The common technique with that=
 is
to use the keyEncipherment bit to be able to cipher the symmetric session=
 key
used to cipher the raw data.</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>Can anyone point me to the right direction, or
provide me some links to technical documentation, about real-life usages=
 with the
Data Encipherment key usage??. Are there any other technologies/algorithms=
 for
RSA where this key usage has more sense??.</span></font></p>

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

<p class=3DMsoNormal><font size=3D2 face=3DArial><span lang=3DEN-GB style=
=3D'font-size:
10.0pt;font-family:Arial'>Thank you very much in advance</span></font></p>

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

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

<p class=3DMsoNormal><span class=3Dname1><b><font size=3D2 face=
=3DVerdana><span
style=3D'font-size:10.0pt;font-family:Verdana'>Carlos Gonz=
=E1lez-Cadenas</span></font></b></span><b><font
size=3D2 face=3DVerdana><span style=
=3D'font-size:10.0pt;font-family:Verdana;
font-weight:bold'><br>
</span></font></b><span class=3Dcargo1><font size=3D1 face=3DVerdana><span
style=3D'font-size:8.5pt;font-family:Verdana'>Jefe de Departamento de
Arquitectura Software</span></font></span><font size=3D1 face=
=3DVerdana><span
style=3D'font-size:8.5pt;font-family:Verdana'><br>
<span class=3Dcargo1><i><span style=3D'font-style:italic'>Software=
 Architecture
Department Manager</span></i></span> <br>
<span class=3Dcargo1>Responsable de Seguridad de la Informaci=
=F3n</span><br>
<span class=3Dcargo1><i><span style=3D'font-style:italic'>Information=
 Security
Responsible</span></i></span> <br>
<br>
</span></font><span class=3Dlogo1><b><font size=3D4 face=3DVerdana><span
style=3D'font-size:14.5pt;font-family:Verdana'>e-xtend<font color=
=3D"#0099cc"><span
style=3D'color:#0099CC'>force</span></font></span></font></b></span><font=
 size=3D1
face=3DVerdana><span style=3D'font-size:8.5pt;font-family:Verdana'><br>
</span></font><span class=3Dtextlogo1><font size=3D1 color=3D"#999999" face=
=3DVerdana><span
style=3D'font-size:7.5pt;font-family:Verdana'>by e-xtendnow=
 BancSabadell</span></font></span><font
size=3D1 face=3DVerdana><span style=
=3D'font-size:8.5pt;font-family:Verdana'> <br>
<br>
C/Sena,12 nucli C planta 2<br>
Edifici Landscape<br>
08190 Sant Cugat del Vall=E8s<br>
<u>phone:</u> [phone]<br>
<u>fax:</u> [phone]<br>
<u>mailto:</u> <a href=3D"mailto:[e-mail]"><font
color=3Ddarkblue><span style=
=3D'color:darkblue'>[e-mail]</span></font></a>
</span></font></p>

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

</div>

</body>

</html>

<table><tr><td bgcolor=3D#ffffff><font color=3D#000000><pre>=0D
Advertencia legal:
Este mensaje y, en su caso, los ficheros anexos son confidenciales,
especialmente en lo que respecta a los datos personales, y se dirigen
exclusivamente al destinatario referenciado. Si usted no lo es y lo ha
recibido por error o tiene conocimiento del mismo por cualquier motivo, le
rogamos que nos lo comunique por este medio y proceda a destruirlo o=
 borrarlo,
y que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o
comunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo=
 pena
de incurrir en responsabilidades legales. El emisor no garantiza la=
 integridad,
rapidez o seguridad del presente correo, ni se responsabiliza de posibles
perjuicios derivados de la captura, incorporaciones de virus o cualesquiera
otras manipulaciones efectuadas por terceros.
</pre></font></td></tr></table>
<table><tr><td bgcolor=3D#ffffff><font color=3D#000000><pre>=0D
Advertiment legal:
Aquest missatge i, si escau, els fitxers annexos tenen caire confidencial,
especialment pel que fa a les dades personals, i s'adrecen exclusivament al
destinatari referenciat. Si no es tracta d'aquest i l'ha rebut per error o=
 se li
ha fet arribar per qualsevol motiu, li preguem que ens ho comuniqui per=
 aquesta
mateixa via i el destrueixi o l'esborri, i que en tot cas s'abstingui=
 d'utilitzar,
reproduir, alterar, arxivar o comunicar a tercers aquest missatge i fitxers
annexos, tot sota pena d'entrar en responsabilitats legals. L'emissor no=
 garanteix
la integritat, la rapidesa o la seguretat d'aquest correu, ni es=
 responsabilitza
de possibles perjudicis derivats de la captura, incorporacions de virus o
qualsevol altres manipulacions que facin tercers.
</pre></font></td></tr></table>
<table><tr><td bgcolor=3D#ffffff><font color=3D#000000><pre>=0D
Disclaimer:
This message and any attached files transmitted with it, is confidential,
especially as regards personal data. It is intended solely for the use of=
 the
individual or entity to whom it is addressed. If you are not the intended=
 recipient
and have received this information in error or have accessed it for any=
 reason,
please notify us of this fact by email reply and then destroy or delete the=
 message,
refraining from any reproduction, use, alteration, filing or communication=
 to third
parties of this message and attached files on penalty of incurring legal
responsibilities. The sender does not guarantee the integrity, the=
 accuracy, the
swift delivery or the security of this email transmission, and assumes no
responsibility for any possible damage incurred through data capture, virus
incorporation or any manipulation carried out by third parties.
</pre></font></td></tr></table>
------=_NextPart_000_002A_01C432B9.3E5430E0--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45BQkFL007169; Wed, 5 May 2004 04:26:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i45BQk4b007168; Wed, 5 May 2004 04:26:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i45BQi9R007136 for <[e-mail]>; Wed, 5 May 2004 04:26:45 -0700 (PDT) (envelope-from [e-mail])
Received: from ms21.chttl.com.tw (ms21 [10.144.2.121]) by fw.chttl.com.tw (8.12.10/8.12.10) with ESMTP id i45BQWGG019139; Wed, 5 May 2004 19:26:33 +0800
Received: (from root@localhost) by ms21.chttl.com.tw (8.12.10/8.12.10) id i45BQXJH023820; Wed, 5 May 2004 19:26:33 +0800
Received: from wcwang ([10.144.133.79]) by ms21.chttl.com.tw (8.12.10/8.12.10) with SMTP id i45BQWL5023724; Wed, 5 May 2004 19:26:32 +0800
Message-ID: <00c101c43293$cfa00a90$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "PKIX List" <[e-mail]>
Cc: "Steve Hanna" <[e-mail]>
References: <[e-mail]>
Subject: Re: Comments on Path Building I-D
Date: Wed, 5 May 2004 19:26:29 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear List,

After reading the certpathbuild draft and the comments
from Steve Hanna, my feeling is that this draft is more
like a paper (or thesis) than a PKIX specification. I believe
that is why Steve criticized the text of the draft as if he is
a reviewer of a PKI paper. I really admire the authors and
Steve's rich and deep knowledge of optimization and
implementation technique for path building. I must confess
that I gained much from reading "the paper" and the
comments from Steve. However, I doubt whether it is
suitable for the PKIX WG to publish "the paper" as an RFC.
I think the text of the draft is good enough to become a
paper on a PKI conference proceedings or even  on a journal.
But, that does not mean it will be a good PKIX RFC.

As a faithful reader of PKIX specifications, I would expect that
if the PKIX WG would like to publish an RFC entitled
"Certification Path Building" then its text should focus on:

1. defining what is a legal certification path
           Can certificates with names in different encoding be chained?
           Can certificates with unmached issuer name and subject name
           be chained by matching SKID and AKID?
2. defining a algorithm for certification path building, also including
         specifying the inputs to the algorithm and
         specifying the outputs from the algorithm
3. specifying the format of certificate/CRL extensions (e.g. SKID, AKID,
    AIA, SIA, CRLDP...) that are related to certification path building.
    E.g.,
           the URL format of different procols (such as LDAP, HTTP, FTP...)
                (e.g., Should the LDAP URL contains the ";binary" option?)
4. specifying how a compliant implementation should process
    theose certificate/CRL extensions related certification path building
5. specifying what is the minimum set of repository retrieving protocols
    (such as LDAP, HTTP, FTP, SMTP...) a compliant implementation
    sould support and how these protocols should be supported. E.g.,
               What is the expected object format?
                    (e.g., DER binary vs.Base64-encoded)
               What is the expected MIME type if HTTP is used?
6. discussing security consideration

I believe that the PKIX certpathbuild specification should specify a
baseline certification path building algorithm in the fashion of RFC
3280 specifying a basic certification path validation algorithm. The
purpose of defining the algorithm is for precisely describe the
expected result of the certification path building. There is no need for
a PKIX specification to teach implementators the optimization and
implementation technique for path building. It is up to the
implementators themselves to choose their own the optimization and
implementation technique. Isn't it?

Therefore, I would like to suggest the authors to complete remove the
section 3 of the current draft. It is not only because a PKIX specification
is not supposed to be a paper or textbook for teaching the optimization
and implementation technique for path building, but also because the
optimization and implementation technique described in that section is
not, as Steve said, the consensus of the PKIX WG. I suggest that the draft
sould spend more space and time to cover the areas I mentioned above.
(I know the current draft already covers them, but I think it is still not
in-depth enough.)

Wen-Cheng Wang

----- Original Message ----- 
From: "Steve Hanna" <[e-mail]>
To: "PKIX List" <[e-mail]>
Sent: Wednesday, April 28, 2004 9:53 PM
Subject: Comments on Path Building I-D


> Here are my comments on draft-ietf-pkix-certpathbuild-03.txt.
> 
> I suspect that these will come off sounding negative.
> I'm sorry about that. I'm glad we have this document
> and I hope it will progress in a modified form, but
> I have some serious problems with the document as
> it now stands.
> 
> I also apologize for the length of these comments.
> I wanted to do a careful review of the document
> and there are a lot of problem areas (although
> some are minor). The fact that nobody else has
> commented on these leads me to suspect that nobody
> except the authors and myself has carefully reviewed
> the document. Can anyone refute that suspicion?
> 
> Thanks,
> 
> Steve
> 
> --------
> 
> Overall Comments:
> 
> * My main overall comment is the one I made last July.
>    There is not consensus on path building techniques
>    in the PKIX working group or the IETF. Why? Because
>    we don't understand the problem thoroughly yet.
> 
>    In this document, you advocate depth first search
>    and suggest that building forward is usually best.
>    I don't think you have carefully considered a wide
>    variety of other algorithms like breadth first search,
>    meet in the middle, etc. Can you show me any solid
>    evidence that shows your algorithms are better than
>    the alternatives?
> 
>    I doubt that you have any such proof. In fact, it
>    seems clear to me that depth first search is a poor
>    algorithm for building cert paths. I say this as a
>    person who has implemented that algorithm myself
>    and regretted it. The problem is that if you make
>    a wrong choice, you must completely explore that
>    part of the PKI before you consider backing out
>    and trying other options. I have heard stories of
>    path building taking 35 minutes or more when there
>    was a valid short path because the builder used
>    DFS and headed down the wrong path.
> 
>    We need to do our homework before making any solid
>    recommendations to implementers. I suppose it's better
>    to have some advice than none, but this document
>    should have a prominent warning that these techniques
>    are experimental. In fact, we might want to give
>    the RFC Experimental status.
> 
>    As I've suggested before, I want to see a careful
>    analysis of different path building strategies.
>    Theoretical analysis will probably be useful,
>    but I expect it will also be useful to compare
>    real-world performance with a variety of topologies
>    (some from real-world deployments, some looking at
>    possible futures like many cross-certified bridges).
>    We need to try out a lot of ideas without getting
>    committed to any too early. The cert path building
>    panel at the PKI R&D Workshop this year was a good
>    start, but we need to do more in-depth work. I've
>    started talking to some other researchers about this.
>    I hope that this documents' authors will join this
>    effort. Their experience and aid will be valuable.
> 
> * At several places in the document, you refer to the
>    "authors' opinions". If this was truly a working
>    group document, it would reflect the consensus of
>    the working group, not the opinions of the authors.
>    As I said before, I don't see working group consensus
>    on this topic. Has anyone other than me (and maybe
>    the authors) carefully reviewed the current draft?
>    I haven't seen any comments on it during Last Call.
> 
>    Since this document does not reflect working group
>    consensus, I do not think it should go forward
>    as a working group draft. It should be an individual
>    submission. But I suppose once it becomes an RFC
>    nobody will ever know whether it was a working group
>    submission or not. And I really do think it's useful
>    to have some guidance on cert path building (even if
>    we don't understand the problem very well). So I'd be
>    OK with having it be a working group submission if it
>    goes to Experimental status and a caveat is added
>    at the beginning warning that this is only the authors'
>    opinion (albeit an educated opinion) and that further
>    study is under way to determine which techniques are
>    actually preferred.
> 
> * You should include in this document a section with
>    guidance to PKI designers about what they can do to
>    make path building easier. Here are some ideas:
> 
>    Use a simple topology (hierarchical with one root),
>    when possible. Include AIA, SIA, and CRLDP extensions
>    in certificates. Make certificates (especially CA
>    certificates) and CRLs easily available by LDAP and
>    HTTP, populating both sides of the crossCertificatePair
>    attribute. Use name constraints and policy constraints
>    whenever possible, especially at high fanout points
>    like bridges. Avoid having more than two high fanout
>    CAs (at most) between any two points, if possible.
> 
> * I have a *serious* objection to the idea that someone
>    is going to specially configure path building software
>    for a particular PKI environment (as I think you imply
>    at the end of section 2.3, early in section 3.4, and in
>    a few other places). This is not practical. Most
>    organizations do not have a PKI wizard on staff
>    (especially a path building wizard). The path building
>    software must just work, automatically. If we can't do
>    that, PKI will never be widely used (at least, not in a
>    non-hierarchical topology). Fortunately, I see no reason
>    why we need special configuration. With AIA and SIA and
>    CRLDP and some good algorithms, we should be able to
>    build paths just fine in almost any PKI without any
>    configuration.
> 
> Substantive Comments:
> 
> * Section 1.2 (Purpose) says "... this document suggests
>    using ... depth first tree traversal. ... Other approaches
>    (e.g., building complete spanning trees of the PKI.) exist
>    and may be shown to be more effective under certain conditions."
> 
>    Building a complete spanning tree of the PKI is not a
>    decent solution. Please change this to something more
>    reasonable, like breadth first search. Otherwise, you're
>    just setting up a straw man, an impractical alternative.
> 
> * In section 1.4.1, you mention one disadvantage of the trust
>    list approach. You might want to mention the problem that
>    compromise of any trusted certificate compromises the
>    entire system.
> 
> * In section 1.4.2, you say that a partial mesh is a mixture
>    of unidirectional and bidirectional cross-certifications.
>    It's probably also important to note that in a partial mesh
>    there may be CAs that are not directly cross-certified at all.
> 
> * What is a Root CA doing in Figure 3? As you say, each EE
>    in a mesh usually trusts the CA that issued its certificate.
>    Because of this Root CA, Figure 3 does not depict a full mesh,
>    as stated in 1.4.2. I suggest that you remove the Root CA.
> 
> * At the end of section 1.4.3, you raise the concern that
>    the assurance of a high-assurance PKI may be diluted by
>    cross-certifying with a less restrictive PKI. If you're
>    going to raise this concern, you should mention that it
>    can be addressed through the use of certificate policies.
> 
> * At the end of section 1.4.4, you say that connecting
>    PKIs with a bridge results in a non-hierarchical PKI.
>    Certainly, this is true. But mesh and hybrid PKIs are
>    not hierarchical either. Why raise this here? And the
>    following sentence which states that any PKI can be
>    considered hierarchical from the right perspective
>    only applies if you remove and duplicate links in the
>    PKI. Since you don't have space to get into this here,
>    I suggest you remove those last two sentences.
> 
> * At the end of the first paragraph of section 2.1, you
>    explain that S/MIME messages commonly include certificates.
>    I think you would be wise to also mention SSL/TLS
>    since this is the most widespread use of PKI and it
>    also supplies certificates in the protocol.
> 
> * Before Figure 6, you explain how certificates are
>    depicted with arrows in your figures. You should also
>    explain the "B(A)" notation you use.
> 
> * At the end of the paragraph after Figure 6, you say
>    that building paths is as important as validating them.
>    I don't agree. Many products have been shipping for
>    years and work just fine without building. In a complex
>    PKI, building is important. But in a simple hierarchical
>    PKI, it's not.
> 
> * At the end of section 2.1, you have a large discussion
>    of why you believe building forward is usually better.
>    This duplicates later discussions on this topic. I suggest
>    you save this for later.
> 
> * In section 2.2, you could simplify and clarify Criterion 1
>    by changing it from this:
> 
>     Criterion 1: The implementation is able to find all possible paths.
>     By this, it is meant that all possible certification paths between
>     the trust anchor and the target certificate which may be valid paths
>     can be built by the algorithm.
> 
>    to this:
> 
>     Criterion 1: The implementation is able to find all possible paths.
>     By this, it is meant that all valid certification paths between
>     the trust anchor and the target certificate can be built by the
>     algorithm.
> 
> * In section 2.2, Criterion 2 seems rather odd. Who cares which
>    invalid paths you build first? The important thing is how quickly
>    and efficiently you can build a valid path or determine that
>    no valid path exists.
> 
> * In section 2.3, you say that because certificates are not
>    permitted to repeat, every potentially valid path has a
>    terminus. But every potentially valid path *always* has
>    a terminus, even if certificates are allowed to repeat.
>    As defined in RFC 3280, a certification path is a collection
>    of n certificates. Every path has a finite number of certificates.
>    I suggest you remove the sentence "As a result, every potential
>    valid path has a terminus, a leaf on the tree."
> 
> * In the following paragraph, you say that removing and
>    duplicating nodes and links in a PKI to turn it into
>    a hierarchy greatly simplifies software design. This
>    may be so, but it also removes many opportunities for
>    insight and optimization. For example, it increases
>    the number of nodes in the data structure and makes it
>    harder to mark a certain area of the PKI as unproductive
>    (since that area may appear several places in the tree).
> 
> * Later in that paragraph, you use the phrase "decision tree"
>    without defining it. I suggest that you define it in
>    section 1.3.
> 
> * One paragraph on page 16 (starting with "A more complicated
>    example") talks about problems with building in the
>    reverse direction when there are many trust anchors.
>    The real issue here is fanout. Whether you're building
>    forward or building reverse, it's bad news when you get
>    to a point where you have several choices. It's especially
>    bad if your heuristics (ranking) don't give you much
>    help in deciding which way to go. And it's even worse
>    if you're using depth-first search, since one wrong
>    move can send you off in the wrong direction for hours.
>    That's why I suggest breadth first search or (even
>    better) ranking all candidates at all points in
>    the tree at each decision time.
> 
>    Four trust anchors is a four-way fanout. A similar
>    situation would arise if you were building forward
>    and arrived at a CA that has four certificates with
>    it as the subject. In either case, you hope that your
>    ranking will help choose the right path. And if you're
>    using depth first search, you really hope that you
>    don't take a wrong turn. One technique for dealing
>    with extreme fanout with fairly equal rankings is to
>    start building from the other end. Another is to rank
>    the certs at the fanout point low and try another branch.
>    A third is to use DPD to get help. And a fourth is to
>    tell PKI designers to use name constraints and other
>    techniques at high fanout points (like bridges) to
>    help path building succeed.
> 
>    I hope that you find this analysis useful.
> 
> * In Figure 10, are W, X, Y, and Z all trust anchors?
>    I think so. That's pretty odd. Why would a relying
>    party have all four of those trust anchors? Who needs
>    the bridge CA in that case? I suspect that this
>    topology was created to support your arguments that
>    repeating a (name, key) pair is bad and that building
>    in reverse is bad. If so, I think you can do better.
> 
>    Let's do a careful theoretical analysis and try
>    out different algorithms on different topologies.
>    I suspect you're right that repeating a (name, key)
>    pair is bad but we need to think about this carefully
>    since it is a significant change to RFC 3280. I think
>    you will see below that building in reverse is a
>    useful tool that should be used in conjunction
>    with building forward. But we need to show the
>    merits of our approaches through analysis, not
>    by consructing topologies that serve our own purposes.
> 
> * In the paragraph after Figure 10, you have several
>    sentences explaining the diagram's notation. This
>    was explained much earlier. The rest of the paragraph
>    (explaining where certificates would be stored in
>    an LDAP directory) also duplicates material found
>    elsewhere. I suggest that you remove these, since
>    the document is already too long.
> 
> * In section 2.4.2, you seem to be proposing that
>    software should build a decision tree. I believe
>    you don't intend for the software to actually
>    build a tree for the entire PKI but only to
>    move incrementally through the PKI adding nodes
>    and links to the tree as needed. I hope that's
>    the case, anyway. Otherwise, you'd need to
>    download all certs in the PKI! If I'm right,
>    you need to be much clearer about this. I could
>    easily imagine a developer writing code that
>    actually builds the tree. That code would
>    work fine in a small test PKI but flood the
>    directory with requests and then die in a
>    large PKI.
> 
> * After Figure 11, you point out that building
>    in reverse is not good in this case. Sure.
>    The EE is in a simple hierarchy. Of course,
>    building forward is best there. If you don't
>    know the topology (especially if you have
>    several trust anchors), starting with forward is
>    fine. Then you can switch or meet in the middle
>    if things get hairy.
> 
> * In section 2.6, you say "[...] the path builder
>    only needs to store the current location in
>    the tree [...] All completed branches can be
>    discarded from memory [...]". Maybe. There's
>    a lot to be said for retaining records of
>    paths you have already tried and rejected.
>    Then you can avoid retrying them at a different
>    point in the graph (unless conditions are
>    sufficiently different to merit a retry).
> 
> * Later in section 2.6, you say "Consider HTTPS
>    support" for CRLDP and AIA. Why would this be
>    valuable? You're retrieving signed data. Using
>    HTTPS may trigger another path build, maybe
>    even a loop where one build triggers another
>    which triggers another and so on. I suppose
>    some repositories may require HTTPS to
>    authenticate the client or protect the
>    certs from prying eyes. But you should probably
>    warn that doing so may be expensive and that
>    implementers should protect against loops.
> 
> * Toward the end of section 2.6, you talk about
>    the path cache. You call for "a configurable
>    expiration date for each entry". Who would
>    configure the date and why? I'm a path building
>    geek and I can't imagine configuring such a
>    thing!
> 
> * A few sentences later, you suggest storing
>    issuer-subject cert relationships. If you
>    want to do this, I suggest that you use a
>    cert hash instead of an (issuer, serial)
>    tuple. Issuer, serial is *not* always unique,
>    especially across multiple PKIs or when
>    one CA is malicious (and remember that some
>    CAs are only partly trusted in a modern PKI).
> 
> * In section 2.7.1, you talk about the required
>    inputs. Instead of supplying the actual Target
>    Certificate, it is sometimes useful to provide
>    criteria that describe what sorts of target
>    certificates you're willing to accept. For instance,
>    when doing S/MIME encryption to a new correspondent
>    you may not have the correspondent's encryption
>    certificate. The path building software can
>    help find it if you tell it what you need.
> 
> * In section 3.2, you recommend that path building
>    software output a detailed log. I think you should
>    recommend that this log be carefully structured
>    so that the paths tried can be easily reconstructed
>    by a diagnostic program. My team built a tool that
>    shows the cert graph and then replays the paths
>    our builder tried, lighting up each one in sequence.
>    We found this a great help in understanding the behavior
>    of our software (finding bugs, improving algorithms,
>    etc.). It's also a very cool way to demo path building,
>    which otherwise is a pretty boring demo ("see, there's
>    the web page!").
> 
> * Later in that paragraph, you say "Ideally, there would
>    be a mechanism for turning this logging on and off [...]".
>    I'd change this to "There should be [...]". Logging is
>    expensive (in storage and CPU time), especially for path
>    building where you commonly try hundreds of certificates
>    or more to create a valid path. You really need a way to
>    turn logging off and on.
> 
> * A few paragraphs later, you say "it may be useful to
>    not rule out any paths" and just return each path as
>    its built, even if it's invalid. The problem with this
>    is that (especially with a depth first search) is that
>    there are many topologies that may cause you to wander
>    among many invalid paths. Why is this technique good?
>    You say it will "provid[e] a more rapid response to the
>    caller than one which builds all possible paths." Maybe.
>    I suspect you'll instead waste time by spending a lot
>    of time returning invalid paths to the caller. I don't
>    see much reason to return invalid paths except in a
>    diagnostic log or for your interesting idea of providing
>    one path that's *mostly* valid for debugging and in case
>    the caller finds that invalid path educational or compelling.
> 
> * A few paragraphs later, you lay out your approach.
>    Here are some comments on it:
> 
>    You say "Do not check revocation status if it requires
>    a directory lookup or network access." Why not start the
>    revocation check and let it run in parallel while you do
>    other things (like checking certs deeper in the graph)?
>    That way, you'll have the revocation check done when you
>    need it. And if the check fails you can abort all work
>    that was based on the validity of that certificate.
>    Of course, you'll want to cache the revocation status
>    of certificates for some time.
> 
>    You say "Do not check digital signatures". Again, why
>    not run this in parallel? Most of path building time
>    (about 90%, based on our data) is spent waiting for
>    the network (while downloading certificates and such).
>    That's an ideal time to be checking signatures. And,
>    of course, you'll want to cache the results of signature
>    checks.
> 
>    You say "Do not check anything that can not be checked
>    as part of the iterative process of traversing the tree."
>    Why not? I expect you would want to run these final checks
>    (like full policy processing when building forward) before
>    returning the path to the caller. Otherwise, the caller
>    will need to run a complete validation of the path, which
>    will take much more time than just running these last
>    few checks.
> 
> * In the last paragraph of 3.2, you say "Second, it is fairly
>    uncommon in typical application environments to encounter
>    a revoked key; therefore, most certificates validated will
>    not be revoked." In a PKI, we don't revoke a key. We revoke
>    a certificate. Therefore, this sentence should read "Second,
>    it is fairly uncommon in typical application environments to
>    encounter a revoked certificate."
> 
> * Why include section 3.3 at all? It's very odd to have
>    an IETF spec talking about internal data structures.
>    Maybe you should just give everyone a copy of your
>    code (since it is apparently ideal) and save them the
>    trouble of implementing it! I'm going to skip my more
>    detailed comments on this section since I think it
>    should be entirely removed.
> 
> * In section 3.4, you refer say "developers should evaluate
>    each method with respect to the environment that the
>    application will operate, and assign weights to each
>    accordingly in the path building software.". First, the
>    word "that" in this sentence should be "in which". Second,
>    this is a prime example of the awful idea that developers
>    must examine each PKI and configure their software to
>    run optimally there.
> 
> * In section 3.5.1, you say "According to [RFC 3280],
>    basicConstraints is required to be present with cA=TRUE
>    in all CA certificates." Actually, section 6.1.4 (k) of
>    RFC 3280 says "Verify that the certificate is a CA
>    certificate (as specified in a basicConstraints extension
>    or as verified out-of-band)." Maybe your software doesn't
>    make any provision for out-of-band indication of CA
>    certificates, but you should probably at least note the
>    possibility that other software may do so.
> 
> * In section 3.5.5, you say "Certificates in the path cache
>    have been validated previously. There is some probability
>    that the path from that certificate to a trust anchor is
>    still valid." The path may still be valid but it may
>    contain constraints that are inconsistent with the
>    path from the Target Certificate to this certificate.
>    You should probably note that possibility.
> 
> * In section 3.5.6, you say that the Previously Verified
>    Signatures sorting method doesn't apply when building
>    in reverse. Actually, it does. Your analysis is incorrect.
>    This method never tells you which way the Target or
>    Trust Anchor is (which certificate is most likely).
>    It only lets you rule out certificates because the
>    signature check would certainly fail.
> 
> * In section 3.5.7, you say the Path Length Constraints
>    sorting method "may be applied in reverse, but the
>    benefit is likely less than that of the forward direction".
>    Why? You can argue that the method is more effective
>    when building in reverse because path length constraints
>    often appear close to trust anchors.
> 
> * In section 3.5.8, you say "Certificates that contain
>    nameConstraints that would  be violated by certificates
>    already in the path to this point are given lower priority
>    (or perhaps eliminated)." They should definitely be
>    eliminated. You know they can't be used to build a
>    valid path, so what's the point (unless you're working
>    on building an invalid path)?
> 
> * In section 3.5.9, you say "While this is viable, the
>    signature verifications required make it less attractive
>    as an elimination method." Usually, a CRL check only
>    requires one signature verification so "verification"
>    should be singular.
> 
>    You also say "It is suggested that this method only
>    be used for sorting and that CRLs are validated post
>    path building." As I noted above, fetching CRLs and
>    performing signature checks can be done in parallel
>    with other work. It's a good idea to do this so that
>    you can discover revoked certs before you have invested
>    too much time in them (and also so that you have the
>    results of the revocation check ASAP).
> 
>    You should also probably change this section to include
>    discussion of OCSP. Right now, it's very focussed on
>    CRLs.
> 
> * Here's a sorting method similar to the "Issuer Found
>    in the Path Cache" method, but better suited to building
>    in reverse. Check whether the subject of the candidate
>    certificate matches the issuer of a certificate sent
>    by the target (in SSL/TLS, S/MIME, etc.). If so, then
>    the candidate certificate should be ranked more
>    highly because it is more likely to lead to a path
>    to the Target Certificate. You may also want to do
>    RDN Matching (as in 3.5.15) with the certificates
>    sent by the target.
> 
> * In section 3.5.15 (on RDN matching), you say "Additionally,
>    it should be noted that this method can require a lot of
>    processing if many trust anchors are present." Actually,
>    this should only require a few hash table lookups (of the
>    RDNs).
> 
> * Section 3.5.18 could be clearer. I think you're saying
>    that the subject and issuer of the candidate certificate
>    should have lots of RDNs in common. But this could be
>    understood to be saying that the subject of the
>    candidate certificate should have lots of RDNs in common
>    with the issuer of the next certificate. Of course,
>    they must match exactly so that can't be what you're
>    saying. But it would help if this section was more
>    explicit.
> 
> * Section 3.5.19 also should be clarified. The description
>    of the reverse method is much clearer than that of the
>    forward method. I suggest that you replace the forward
>    method language with language based on the reverse method
>    language. One change to the reverse method language, though.
>    Instead of saying "If an entity named by a reverse certificate",
>    say "If the subject of a certificate". There's no such
>    thing as a "reverse certificate".
> 
>    Note also that just because you find a name in the
>    certificate cache, that doesn't mean you have the
>    right certificates. There may be several different
>    CAs with the same name. Also, you may now have more
>    clues (like AIA and SIA) for finding certificates
>    than you had before. You should be sure to pursue
>    any such new clues.
> 
> * In the Justification for 3.5.19, you say "The presence of
>    required directory values populated in the cache increases
>    the likelihood that all the required certificates and CRLs
>    needed to complete the path from this certificate to the
>    trust anchor (or target if building in reverse) are present
>    in the cache from a prior path being developed [...]".
>    That's fine, but you might also want to keep the actual path
>    previously developed and look at that as a prime candidate
>    for the path this time.
> 
> * In section 3.5.20, you use the presence of a CRL in
>    the CRL cache to indicate whether a complete path
>    through a CA has previously been found. This is
>    rather indirect. It would be better to actually
>    track which certs have been previously included
>    in valid paths. Keeping a copy of the path would
>    also be quite useful.
> 
> * The discussion of Forward Policy Chaining in section 4
>    overstates the benefits of policy checks when building
>    in the forward direction. We should discuss this more.
> 
> * In section 5.2, you suggest that each name/key pair
>    only be allowed to appear once in a path. Since there
>    is no such requirement in X.509 or RFC 3280, this
>    would violate Criterion 1 as stated in section 2.2.
>    You would miss some valid paths.
> 
> * In section 6 (Retrieval Methods), you should mention
>    getting certificates and CRLs from the target (with
>    S/MIME or SSL/TLS, for instance). That's a *great*
>    way to get certificates and CRLs. The ones you get
>    are usually highly valuable.
> 
> * Sections 6.2 and 6.3 should include text that encourages
>    implementers to support AIA and SIA, especially HTTP.
>    This text from the end of section 6.4 could easily
>    be adapted:
> 
>        However, implementers of path building
>     and validation modules are strongly encouraged to support CRLDPs.  At
>     a minimum, developers are encouraged to consider supporting the LDAP
>     and HTTP transports; this will provide for interoperability across a
>     wide range of existing PKIs.
> 
> * In section 7, you should talk about prefetching and
>    parallel fetching. Both are good ways to improve the
>    performance of a cert path building implementation.
> 
> * In section 7.1, you say "Certificate processing systems can
>    cache data retrieved from external sources for some period
>    of time, but not to exceed the useful period of the data
>    (i.e., an expired certificate need not be cached)." CRLs
>    are often issued well before the nextUpdate of the previous
>    CRL. Could you mention this and suggest that implementers
>    check periodically for updated CRLs? Similarly,
>    crossCertificatePairs may be updated on an unpredictable
>    basis. If you don't check back every so often, you'll
>    never know that a new cross certificate is available!
> 
> * The last bullet in section 7.1 offers a few suggestions
>    for other things to cache. I'd add to that list previously
>    built paths and partial paths. If the cache is safe from
>    unauthorized modifications (as with an in-memory cache),
>    you may also want to cache validation and signature check
>    status for certificates and CRLs.
> 
> * In section 7.2 (Retrieval Order), you may want to consider
>    checking repositories in parallel instead of serially.
>    Also, you might want to run ahead with your path building
>    and validation while a network query is ongoing. Maybe
>    you can build and validate the path with just the certificates
>    and CRLs you have already (thus eliminating the need to
>    wait for the network query to complete). Anything to get
>    the answer to the user more quickly!
> 
> * In section 8.1, you should probably add a statement that
>    path building can be used as a denial of service attack.
>    Make a series of simple requests to a server and cause it
>    to do a bunch of long path builds. To avoid this, the
>    server can limit the amount of resources it's willing to
>    devote to a path build. This amount can be reduced when
>    the load is heavy. And standard DOS protections like
>    identifying attackers can be employed.
> 
> * Section 8.2 goes way beyond RFC 3280 and X.509. I know
>    that Santosh is working on getting this into X.509 and
>    the successor to RFC 3280. I'll debate the specifics
>    of his proposal in that context. But for this document,
>    I think you should be careful to explain that this goes
>    beyond the standards. If you implement it, you will
>    violate Criterion 1 from section 2.2. Maybe the best
>    thing to do is to just briefly point out that there's
>    an issue here and it's under discussion in the standards
>    groups. Once it's settled there, this document can be
>    revised to reflect whatever's agreed on.
> 
> Minor Comments:
> 
> * The first paragraph of section 2 says "... guidance is
>    provided on the capabilities path building implementations
>    required in order to ...". I think you want "require" or
>    (maybe better due to RFC 2119) "need" instead of "required".
> 
> * Just below Figure 6, "the certificates cannot be validated"
>    should be "certificates cannot be validated". You're not
>    referring to any particular certificates, just certificates
>    in general.
> 
> * In the paragraph after that, you should say "the
>    crossCertificatePair attribute" instead of "the cross
>    certificates". Otherwise, it's not clear what you mean.
> 
> * In the second paragraph of section 3.2, you say a
>    certificate "may appear again on another point in
>    the tree". That should be "at another point in
>    the tree".
> 
> * At the end of section 3.4, "The list" should be "the list".
> 
> * In section 3.5.17, there are two typos. "it priority"
>    should be "it has priority". "will not successfully"
>    (in the last paragraph) should be "will not verify
>    successfully".
> 
> * In section 5.4, you say certificates "will be" required
>    to use UTF-8 after January 1, 2004. This should now
>    be changed to "are".
> 
> * In section 6, the first sentence should mention CRLs
>    also. I suggest that the second sentence say "obtaining
>    these certificates and CRLs" instead of "performing
>    this retrieval", since retrieval has not yet been
>    mentioned and sometimes the certificates can be
>    obtained without having to be retrieved (as when the
>    EE sends them in SSL).
> 
> * In section 6.1, the description of userCertificate
>    should probably say that it "contains certificates
>    issued by one or more certification authorities with
>    a subject DN that matches that of the directory entry".
>    Also, there's an extra period at the end of the
>    parenthetical comment later in the paragraph.
> 
> * Later in section 6.1, the description of issuedByThisCA
>    should say it contains certificates issued to *other*
>    CAs. And there's an extra comma after "If both elements
>    are present" (later in that paragraph). Why include that
>    sentence anyway. The relying party doesn't need to
>    enforce this requirement. People may think they need
>    to do so.
> 
> * In section 6.2, you say "AIA may be used to retrieve one or
>    more certificates for entities that issued the certificate
>    containing the AIA extension." I think it would be clearer
>    to say "the CA" instead of "entities".
> 
> * At the end of the first paragraph of section 6.3, "AIA"
>    appears twice where it should be "SIA".
> 
> * In section 6.4, you say "the CRL(s) to which the CRLDP(s) refer
>    is the CRL that would contain revocation information for the
>    certificate." I'd say instead "the CRL(s) to which the CRLDP
>    refers are generally the CRLs that would contain revocation
>    information for the certificate." Why? Because a CRLDP may
>    refer an LDAP directory entry that contains many CRLs. Some
>    of them may not pertain to this certificate. And of course
>    there's usually only one CRLDP in a certificate.
> 
> * In section 8.2, "q CRL Signer" should be "a CRL Signer".
> 
> * In the Informative References, you include "[MINHPKIS]"
>    but it's never actually referred to anywhere in the document.
>    Similarly for [X.501] and [X.520]. You should probably
>    remove those references. If you're going to retain them
>    for some reason, please provide a decent reference for
>    [MINHPKIS]: publisher, publication date.
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i453dZLt031438; Tue, 4 May 2004 20:39:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i453dZsg031437; Tue, 4 May 2004 20:39:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i453dYGD031401 for <[e-mail]>; Tue, 4 May 2004 20:39:34 -0700 (PDT) (envelope-from [e-mail])
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i453dZiJ399862; Tue, 4 May 2004 23:39:35 -0400
Received: from d01ml062.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i453e5dm049804; Tue, 4 May 2004 23:40:06 -0400
To: "Santosh Chokhani" <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: RE: Cross certificate format
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Tue, 4 May 2004 23:39:26 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.2CF2 HFB2 +DEBUG|April 23, 2004) at 05/04/2004 23:39:34, Serialize complete at 05/04/2004 23:39:34
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Santosh:

        Of course, defining a trust anchor implies that the RP trusts the 
anchor's public key as an issuer for at least some purposes.  RFC 3280, in 
the parts of section 6.1.2 I cited, appears to forbid those state 
variables from being set from information defined by the RP or stored with 
the trust anchor.  This is consistent with its statements in 6.1.1 d which 
permit self-signed certificates but say nothing about other CA 
certificates.  As is probably clear to everyone reading this thread, I 
think that this is not an ideal set of suggestions.
        The current standard does contain some constraints on the trust 
anchor (notably inhibit-policy-mapping), but neither name constraints nor 
basic constraints.  I consider this an anomaly.  If I had free rein in 
rewording pieces of RFC 3280 section 6.1, I would change this wording to 
allow CA certificates along with self-signed ones as anchors and create 
extra optional (and optional to support) fields to be set from the trust 
anchor.
        I don't think that this is particularly inconsistent with general 
security principles, or with any part of X.509 with which I am familiar. 
It does represent an extension of RFC 3280 section 6, and it is only 
backward compatible with it, so it may be out of scope.

                Tom Gindin





"Santosh Chokhani" <[e-mail]>
Sent by: [e-mail]
05/01/2004 06:46 PM

 
        To:     <[e-mail]>
        cc: 
        Subject:        RE: Cross certificate format




Tom:

The standard does not require you to check how you initialize the 
variables.
You can get these from the cross certificate or from some configuration.

The basic point is that you trust the public key.  How you constrain it is
not address by the standard, where as if the same certificate appeared in 
a
path, you have to apply the constraints or be not compliant with the
standard.

You obviously do not believe in re-incarnation.  Just kidding......

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]] 
Sent: Saturday, May 01, 2004 6:31 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Cross certificate format


        Santosh:

        It is well known that trust in a trust anchor can be defined in a 
variety of ways.  However, there is every reason to think that an RP may 
constrain that trust and that the constraints he may apply include those 
which an issuer CA may apply to a subordinate one. The wording of RFC 3280 

section 6.2's first paragraph is an example of this.
        My comments about the meaning of a trust anchor are not purely 
theoretical.  If a cross certificate is used to represent a trust anchor, 
the variables permitted_subtrees (RFC 3280 6.1.2 b) and excluded_subtrees 
(RFC 3280 6.1.2 c) could easily be set from the contents of a 
NameConstraints extension, and the variable max_path_length (RFC 3280 
6.1.2 k) from the contents of a BasicConstraints extension.  In RFC 3280 
today, these variables are set to constants (although that interpretation 
is not absolutely clear for permitted_subtrees).  In fact, they are three 
of the four variables which are set to constants during initialization.
        If permitted subtrees were set to a list of attributes, the 
validation process would fail if the anchor CA or a CA it certified went 
beyond the restrictions of those attributes.  Likewise, if the excluded 
subtrees were set to a list of attributes, the validation process would 
fail if the anchor CA or a CA it certified went used values matching any 
of those attributes.  I do not believe that I am arguing against Galileo.

                Tom Gindin






"Santosh Chokhani" <[e-mail]>
Sent by: [e-mail]
04/29/2004 11:12 PM

 
        To:     <[e-mail]>
        cc: 
        Subject:        RE: Cross certificate format




Tom:

The basic point (at the risk of repeating myself) is that a CA certificate
or a self-signed certificate can be used as a means to provide trust 
anchor
information.  In that case, there is no need to check signature or 
anything.

But, when the CA certificate is a certificate in the certificate path, 
X.509
logic kicks in.

This is consistent with X.509, 3280 and general security principles since
the trust in a trust anchor can be derived through any number of means.

If you do not agree, feel free to argue against the definitions and 
Galileo

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
On
Behalf Of Tom Gindin
Sent: Thursday, April 29, 2004 8:43 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Cross certificate format



        Santosh:

        I don't think that a CA certificate and a trust anchor are as much 


different things as different uses for the same thing.  They are both 
identifiers of issuers which bind a public key to an issuer name, and it 
is perfectly appropriate for any CA certificate to represent a trust 
anchor.  I also do not see why such things as name constraints on a trust 
anchor are inappropriate.  It is perfectly true that verifying a trust 
anchor's certificate, when issued by another CA (who may not be trusted) 
is a pointless operation.

                Tom Gindin





"Santosh Chokhani" <[e-mail]>
Sent by: [e-mail]
04/27/2004 09:14 AM

 
        To:     <[e-mail]>
        cc: 
        Subject:        RE: Cross certificate format




Tom:

My point is that even if the trust anchor is a self-signed certificate, 
all
you need to do is extract the required information.  There is no need to
examine anything.

Cross certificate and trust anchor are very different things.  An element 
of
the cross certificate pair is nothing but an intermediate CA certificate 
in
a certification path.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
On
Behalf Of Tom Gindin
Sent: Tuesday, April 27, 2004 7:33 AM
To: Santosh Chokhani
Cc: [e-mail]; [e-mail]
Subject: RE: Cross certificate format



        Santosh:

        Of course, you are right that RFC 3280 6.1.1 d permits trust 
anchor information to be provided outside a certificate.  If it is so, no 
checks of the sort I indicated can be performed.  It also says that it can 



be provided as "a self-signed certificate", with no further qualification. 



 I do think it is somewhat odd that a self-signed certificate with 
KeyUsage set to typical EE values would be considered a valid issuer as a 
trust anchor while a cross certificate would not.  You can always extract 
the needed anchor information from a cross-certificate, of course.

                Tom Gindin





"Santosh Chokhani" <[e-mail]>
Sent by: [e-mail]
04/26/2004 08:51 AM

 
        To:     <[e-mail]>
        cc: 
        Subject:        RE: Cross certificate format




Tom:

My reading of 3280 and X.509 is that a trust anchor need not even be a
certificate.  Thus, no checks need to be performed on a trust anchor at 
all.
You get the DN, public key, algorithm OID, and parameters (if applicable)
from a trust anchor.  Any checks are gratuitous and not required by either
standard.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
On
Behalf Of Tom Gindin
Sent: Sunday, April 25, 2004 7:06 PM
To: Jean-Marc Desperrier
Cc: [e-mail]
Subject: Re: Cross certificate format



        Jean-Marc:

        RFC 3280 doesn't say that anywhere.  It does say that you don't 
need to validate the trust anchor as part of the path, but it isn't clear 
from the text that a v1 certificate is acceptable as a trust anchor - and 
it certainly isn't clear that a v1 certificate is acceptable as an issuer 
if it is a trust anchor while a v3 certificate with KeyUsage= { 
DigitalSignature, keyEncipherment } is not acceptable as an issuer even if 




it is a trust anchor.
        I believe that the correct rules for versions are something like 
the following: a certificate issued by a trust anchor which is represented 




by a certificate is verifiable if the anchor certificate is either a v1 
certificate or a v3 certificate with the CA flag present in the 
basicConstraints extension.  If the anchor certificate is a v3 certificate 




with the KeyUsage extension present, it is only a valid issuer certificate 




if keyCertSign is set.

        Tom Gindin





Jean-Marc Desperrier <[e-mail]>
Sent by: [e-mail]
04/21/2004 03:42 PM

 
        To:     [e-mail]
        cc: 
        Subject:        Re: Cross certificate format




Tom Gindin wrote:

>        RFC 3280 does not support the use of v1 self-signed
> certificates,

>which contain no extensions at all (see the text of RFC 3280's 
>basicConstraints section).  However, a number of public CA's still have 
>them.
> 
>
Applications implementing the path validation algorithm of RFC3280 MUST 
accept them when they are used as trust anchors.
 






















Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i44HM6nb004456; Tue, 4 May 2004 10:22:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i44HM6Rl004455; Tue, 4 May 2004 10:22:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from exchange.microsoft.com ([131.107.8.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i44HM6N9004448 for <[e-mail]>; Tue, 4 May 2004 10:22:06 -0700 (PDT) (envelope-from [e-mail])
Received: from DF-VRS-01.redmond.corp.microsoft.com ([157.54.4.14]) by exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Tue, 4 May 2004 10:22:09 -0700
Received: from 10.197.0.83 by DF-VRS-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 04 May 2004 10:22:09 -0700
Received: from DF-GROMMIT-01.mercury.corp.microsoft.com ([10.197.0.61]) by DF-BEG.mercury.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 4 May 2004 10:22:09 -0700
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: FW: scvp
Date: Tue, 4 May 2004 10:22:07 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: FW: scvp
thread-index: AcQxwLsmZ8FgwcdIRS2lew779l5wYwAOIYEg
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 04 May 2004 17:22:09.0831 (UTC) FILETIME=[54DA0370:01C431FC]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i44HM6N9004449
Sender: [e-mail]
Precedence: 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,
There is no mandate in 3379 that a validation policy must be expressed
with a single value. It is not clear that is any value is doing so since
it only raised more ambiguity. This is well trod turf by many groups who
have debated the merits of providing suits vs. "al a carte" combinations
of inputs and the broader consensus is for a "al a carte".
Trevor

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Tuesday, May 04, 2004 3:15 AM
To: Trevor Freeman
Cc: [e-mail]
Subject: Re: FW: scvp

Trevor,

> Hi Denis,
> 
> 3379 does not require that the validation policy be specified in a
> single value. 

You are playing with words. The text says:
"most clients will simply reference a validation policy"

This means that validation policies can be referenced and thus
parameters do 
not need to be defined through this interface.

A simple and good reference is an OID.

> With SCVP14 a client can accept the default of the SCVP
> server or specify a set of parameters which constitutes its validation
> policy. That is consistent with the requirements of 3379.

The specification of the set of parameters should be done through a 
different interface. This different interface can then return an OID 
Whatever this additional interface can be, it will never be rich enough
to 
pass all the details of the validation policy. Thus OIDs can also be
defined 
not using this additional interface.

Denis

> Trevor
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Thursday, April 29, 2004 3:54 AM
> To: Trevor Freeman
> Cc: [e-mail]
> Subject: Re: FW: scvp
> 
> Trevor,
> 
> 
>>Hi Denis,
> 
> 
>>Can you please be more specific how you think SCVP 14 does not comply
>>with 3379.
>>
>>I can find no section in 3379 where is there a requirement that a
>>validation policy MUST be represented as an OID. 
> 
> 
> There cannot be a requirement with such a level of detail, but the
text
> states:
> 
>     The protocol MUST allow the client to include
>     these policy dependant parameters in the DPV request; however, it
is
>     expected that most clients will simply reference a validation
policy
>     for a given application or accept the DPV server's default
> validation
>     policy.
> 
> A simple reference is an OID.
> 
> FYI, I do not expect to use the "default validation policy".
> 
> Denis
> 
> 
> 
>>Given hiding the detail of what a policy is within an OID simply opens
>>the rat hole of what change to the policy constitutes a change to the
>>OID, it is less ambiguous to refer to the primary data. Once you are
> 
> in
> 
>>the business of managing state on a client, then there is negligible
>>cost increase incurred in managing several data points vs. a singe
> 
> data
> 
>>point.
>>
>>Trevor
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]] 
>>Sent: Tuesday, April 27, 2004 11:01 AM
>>To: Trevor Freeman
>>Cc: [e-mail]
>>Subject: Re: FW: scvp
>>
>>Trevor,
>>
>>
>>
>>>HI Denis,
>>>In SCVP13, the concept of validation policy was not completely in
>>>alignment  with 3379 definition. 
>>
>>
>>Well, it is different and this is a major problem.
>>
>>
>>
>>>It also blurred the distinction between
>>>validation policy and validation algorithm. 
>>
>>
>>This is also a majo problem.
>>
>>
>>
>>>Therefore I have defined
>>>what each is in SCVP 14 and aligned the structures accordingly.
>>>Section 1.3 has the following.
>>>"In SCVP, the validation policy comprises of an algorithm for
>>>certificate path processing and the input parameters to the
>>
>>algorithm."
>>
>>This does not comply with RFC 3379.
>>
>>
>>
>>>Therefore trust anchors are an input into the algorithm  and
therefore
>>>separate.
>>
>>
>>Therefore I do not follow you.
>>
>> From an interface point of view the simplest validation policy is
>>defined 
>>by an OID where all the parameters necessary to perform the validation
>>check 
>>are "behind" the OID. There is no need to provide any parameter
> 
> through
> 
>>the 
>>interface.
>>
>>When there are some parameters, then they are specific to the
> 
> validation
> 
>>policy. I have no problem to provide specific parameters for what is
>>called 
>>the "default validation policy" which is only a particular validation
>>policy 
>>among many others.
>>
>>Simple clients will be unable to pass any parameter but will know
> 
> which
> 
>>OIDs 
>>(for the validation policy) are appropriate for their applications.
>>
>>Denis
>>
>>
>>
>>>This is in alignment with 3379s definition of validation policy.
>>>
>>>Trevor
>>>
>>>-----Original Message-----
>>>From: Denis Pinkas [mailto:[e-mail]] 
>>>Sent: Monday, April 26, 2004 1:09 AM
>>>To: Peter Sylvester
>>>Cc: [e-mail]; Trevor Freeman
>>>Subject: Re: FW: scvp
>>>
>>>Peter and Trevor,
>>>
>>>I have major problems too.
>>>
>>>
>>>
>>>
>>>>in version 13 the syntax for a Query has been changed from
>>>>
>>>> Query ::= SEQUENCE { 
>>>>     queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference, 
>>>>     checks                CertChecks, 
>>>>     wantBack              WantBack, 
>>>>     serverContextInfo [0] OCTET STRING OPTIONAL, 
>>>>     valPolicy         [1] ValidationPolicy OPTIONAL, 
>>>>     validityTime      [2] GeneralizedTime OPTIONAL, 
>>>>     trustAnchors      [3] TrustAnchors OPTIONAL, 
>>>>     intermediateCerts [4] CertBundle OPTIONAL, 
>>>>     revInfos          [5] RevocationInfos OPTIONAL, 
>>>>     queryExtensions   [6] Extensions OPTIONAL } 
>>>
>>>
>>>In this structure trustAnchors was more or less an alternative to
>>>valPolicy.
>>>
>>>In fact, IF the valPolicy is the default policy, THEN additional
>>>parameters 
>>>MUST be provided. So the structure below does not fit as well.
>>>
>>>This leads to have the two following elements:
>>>
>>>    valPolicy               ValidationPolicy,
>>>    paramsDefValPolicy      ParamsDefValPolicy OPTIONAL,
>>>
>>>where the first one is mandatory and the second one optional.
>>>
>>>
>>>
>>>
>>>>to  
>>>>
>>>>  Query ::= SEQUENCE { 
>>>>    queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>>
>>>
>>>>    checks                  CertChecks, 
>>>>    wantBack                WantBack, 
>>>>    requestRefHash          BOOLEAN DEFAULT TRUE, 
>>>>    includePolResponce      BOOLEAN DEFAULT FALSE, 
>>>>    inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>>>    requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>>>    ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>>>    valAlgorithm            ValidationAlgorithm, 
>>>>    serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>>>    validityTime        [1] GeneralizedTime OPTIONAL, 
>>>>    trustAnchors        [2] TrustAnchors OPTIONAL, 
>>>>    intermediateCerts   [3] CertBundle OPTIONAL, 
>>>>    revInfos            [4] RevocationInfos OPTIONAL, 
>>>>    queryExtensions     [5] Extensions OPTIONAL } 
>>>
>>>
>>>I would thus propose to have something like:
>>>
>>>Query ::= SEQUENCE {
>>>        queriedCerts            SEQUENCE SIZE (1..MAX) OF
>>>CertReference,
>>>        checks                  CertChecks,
>>>        wantBack                WantBack,
>>>        requestRefHash          BOOLEAN DEFAULT TRUE,
>>>        serverContextInfo       OCTET STRING OPTIONAL,
>>>        validityTime            GeneralizedTime OPTIONAL,
>>>        includePolResponse      BOOLEAN DEFAULT FALSE,
>>>        valPolicy               ValidationPolicy,
>>>        paramsDefValPolicy  [0] ParamsDefValPolicy OPTIONAL,
>>>        intermediateCerts   [1] CertBundle OPTIONAL,
>>>        revInfos            [2] RevocationInfos OPTIONAL,
>>>        queryExtensions     [3] Extensions OPTIONAL }
>>>
>>>and then something like:
>>>
>>>   ParamsDefValPolicy :: = SEQUENCE {
>>>       trustAnchors                  TrustAnchors,
>>>       endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER
>>>OPTIONAL,
>>>       inhibitPolMap                 BOOLEAN DEFAULT FALSE,
>>>       caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER
>>>OPTIONAL }
>>>
>>>Denis
>>>
>>>
>>>
>>>
>>>>I am not sure whether I am the only person unable to construct a
>>>
>>>parser.
>>>
>>>
>>>
>>>>in version 14 an aditional flag has been added which is not
available
>>>
>>>in the
>>>
>>>
>>>
>>>>Chapter 9. Is the isCA flag an orthogonal attribut to other
>>>
> validation
> 
>>>>algorithms, or just to some of them, e.g,. the default name matching
>>>
>>>one? 
>>>
>>>
>>>
>>>>  Query ::= SEQUENCE { 
>>>>    queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>>
>>>
>>>>    checks                  CertChecks, 
>>>>    wantBack                WantBack, 
>>>>    requestRefHash          BOOLEAN DEFAULT TRUE, 
>>>>    includePolResponce      BOOLEAN DEFAULT FALSE, 
>>>>    inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>>>    requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>>>    ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>>>    isCA                    BOOLEAN DEFAULT FALSE, 
>>>>    valAlgorithm            ValidationAlgorithm, 
>>>>    serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>>>    validityTime        [1] GeneralizedTime OPTIONAL, 
>>>>    trustAnchors        [2] TrustAnchors OPTIONAL, 
>>>>    intermediateCerts   [3] CertBundle OPTIONAL, 
>>>>    revInfos            [4] RevocationInfos OPTIONAL, 
>>>>    keyUsage            [5] KeyUsage OPTIONAL, 
>>>>    extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
>>>>    queryExtensions     [7] Extensions OPTIONAL  
>>>>    producedAt          [8] GeneralizedTime OPTIONAL} 
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
> 
> 
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i44AFRsF026411; Tue, 4 May 2004 03:15:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i44AFRpM026410; Tue, 4 May 2004 03:15:27 -0700 (PDT)
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.9) with ESMTP id i44AFPTI026360 for <[e-mail]>; Tue, 4 May 2004 03:15:26 -0700 (PDT) (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 MAA09266; Tue, 4 May 2004 12:24:33 +0200
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 MAA19222; Tue, 4 May 2004 12:11:20 +0200
Message-ID: <[e-mail]>
Date: Tue, 04 May 2004 12:15:28 +0200
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: Trevor Freeman <[e-mail]>
CC: [e-mail]
Subject: Re: FW: scvp
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>

Trevor,

> Hi Denis,
> 
> 3379 does not require that the validation policy be specified in a
> single value. 

You are playing with words. The text says:
"most clients will simply reference a validation policy"

This means that validation policies can be referenced and thus parameters do 
not need to be defined through this interface.

A simple and good reference is an OID.

> With SCVP14 a client can accept the default of the SCVP
> server or specify a set of parameters which constitutes its validation
> policy. That is consistent with the requirements of 3379.

The specification of the set of parameters should be done through a 
different interface. This different interface can then return an OID 
Whatever this additional interface can be, it will never be rich enough to 
pass all the details of the validation policy. Thus OIDs can also be defined 
not using this additional interface.

Denis

> Trevor
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Thursday, April 29, 2004 3:54 AM
> To: Trevor Freeman
> Cc: [e-mail]
> Subject: Re: FW: scvp
> 
> Trevor,
> 
> 
>>Hi Denis,
> 
> 
>>Can you please be more specific how you think SCVP 14 does not comply
>>with 3379.
>>
>>I can find no section in 3379 where is there a requirement that a
>>validation policy MUST be represented as an OID. 
> 
> 
> There cannot be a requirement with such a level of detail, but the text
> states:
> 
>     The protocol MUST allow the client to include
>     these policy dependant parameters in the DPV request; however, it is
>     expected that most clients will simply reference a validation policy
>     for a given application or accept the DPV server's default
> validation
>     policy.
> 
> A simple reference is an OID.
> 
> FYI, I do not expect to use the "default validation policy".
> 
> Denis
> 
> 
> 
>>Given hiding the detail of what a policy is within an OID simply opens
>>the rat hole of what change to the policy constitutes a change to the
>>OID, it is less ambiguous to refer to the primary data. Once you are
> 
> in
> 
>>the business of managing state on a client, then there is negligible
>>cost increase incurred in managing several data points vs. a singe
> 
> data
> 
>>point.
>>
>>Trevor
>>
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]] 
>>Sent: Tuesday, April 27, 2004 11:01 AM
>>To: Trevor Freeman
>>Cc: [e-mail]
>>Subject: Re: FW: scvp
>>
>>Trevor,
>>
>>
>>
>>>HI Denis,
>>>In SCVP13, the concept of validation policy was not completely in
>>>alignment  with 3379 definition. 
>>
>>
>>Well, it is different and this is a major problem.
>>
>>
>>
>>>It also blurred the distinction between
>>>validation policy and validation algorithm. 
>>
>>
>>This is also a majo problem.
>>
>>
>>
>>>Therefore I have defined
>>>what each is in SCVP 14 and aligned the structures accordingly.
>>>Section 1.3 has the following.
>>>"In SCVP, the validation policy comprises of an algorithm for
>>>certificate path processing and the input parameters to the
>>
>>algorithm."
>>
>>This does not comply with RFC 3379.
>>
>>
>>
>>>Therefore trust anchors are an input into the algorithm  and therefore
>>>separate.
>>
>>
>>Therefore I do not follow you.
>>
>> From an interface point of view the simplest validation policy is
>>defined 
>>by an OID where all the parameters necessary to perform the validation
>>check 
>>are "behind" the OID. There is no need to provide any parameter
> 
> through
> 
>>the 
>>interface.
>>
>>When there are some parameters, then they are specific to the
> 
> validation
> 
>>policy. I have no problem to provide specific parameters for what is
>>called 
>>the "default validation policy" which is only a particular validation
>>policy 
>>among many others.
>>
>>Simple clients will be unable to pass any parameter but will know
> 
> which
> 
>>OIDs 
>>(for the validation policy) are appropriate for their applications.
>>
>>Denis
>>
>>
>>
>>>This is in alignment with 3379s definition of validation policy.
>>>
>>>Trevor
>>>
>>>-----Original Message-----
>>>From: Denis Pinkas [mailto:[e-mail]] 
>>>Sent: Monday, April 26, 2004 1:09 AM
>>>To: Peter Sylvester
>>>Cc: [e-mail]; Trevor Freeman
>>>Subject: Re: FW: scvp
>>>
>>>Peter and Trevor,
>>>
>>>I have major problems too.
>>>
>>>
>>>
>>>
>>>>in version 13 the syntax for a Query has been changed from
>>>>
>>>> Query ::= SEQUENCE { 
>>>>     queriedCerts          SEQUENCE SIZE (1..MAX) OF CertReference, 
>>>>     checks                CertChecks, 
>>>>     wantBack              WantBack, 
>>>>     serverContextInfo [0] OCTET STRING OPTIONAL, 
>>>>     valPolicy         [1] ValidationPolicy OPTIONAL, 
>>>>     validityTime      [2] GeneralizedTime OPTIONAL, 
>>>>     trustAnchors      [3] TrustAnchors OPTIONAL, 
>>>>     intermediateCerts [4] CertBundle OPTIONAL, 
>>>>     revInfos          [5] RevocationInfos OPTIONAL, 
>>>>     queryExtensions   [6] Extensions OPTIONAL } 
>>>
>>>
>>>In this structure trustAnchors was more or less an alternative to
>>>valPolicy.
>>>
>>>In fact, IF the valPolicy is the default policy, THEN additional
>>>parameters 
>>>MUST be provided. So the structure below does not fit as well.
>>>
>>>This leads to have the two following elements:
>>>
>>>    valPolicy               ValidationPolicy,
>>>    paramsDefValPolicy      ParamsDefValPolicy OPTIONAL,
>>>
>>>where the first one is mandatory and the second one optional.
>>>
>>>
>>>
>>>
>>>>to  
>>>>
>>>>  Query ::= SEQUENCE { 
>>>>    queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>>
>>>
>>>>    checks                  CertChecks, 
>>>>    wantBack                WantBack, 
>>>>    requestRefHash          BOOLEAN DEFAULT TRUE, 
>>>>    includePolResponce      BOOLEAN DEFAULT FALSE, 
>>>>    inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>>>    requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>>>    ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>>>    valAlgorithm            ValidationAlgorithm, 
>>>>    serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>>>    validityTime        [1] GeneralizedTime OPTIONAL, 
>>>>    trustAnchors        [2] TrustAnchors OPTIONAL, 
>>>>    intermediateCerts   [3] CertBundle OPTIONAL, 
>>>>    revInfos            [4] RevocationInfos OPTIONAL, 
>>>>    queryExtensions     [5] Extensions OPTIONAL } 
>>>
>>>
>>>I would thus propose to have something like:
>>>
>>>Query ::= SEQUENCE {
>>>        queriedCerts            SEQUENCE SIZE (1..MAX) OF
>>>CertReference,
>>>        checks                  CertChecks,
>>>        wantBack                WantBack,
>>>        requestRefHash          BOOLEAN DEFAULT TRUE,
>>>        serverContextInfo       OCTET STRING OPTIONAL,
>>>        validityTime            GeneralizedTime OPTIONAL,
>>>        includePolResponse      BOOLEAN DEFAULT FALSE,
>>>        valPolicy               ValidationPolicy,
>>>        paramsDefValPolicy  [0] ParamsDefValPolicy OPTIONAL,
>>>        intermediateCerts   [1] CertBundle OPTIONAL,
>>>        revInfos            [2] RevocationInfos OPTIONAL,
>>>        queryExtensions     [3] Extensions OPTIONAL }
>>>
>>>and then something like:
>>>
>>>   ParamsDefValPolicy :: = SEQUENCE {
>>>       trustAnchors                  TrustAnchors,
>>>       endEntityCertificationPolicy  SEQUENCE OF OBJECT IDENTIFIER
>>>OPTIONAL,
>>>       inhibitPolMap                 BOOLEAN DEFAULT FALSE,
>>>       caCertificationPolicies       SEQUENCE OF OBJECT IDENTIFIER
>>>OPTIONAL }
>>>
>>>Denis
>>>
>>>
>>>
>>>
>>>>I am not sure whether I am the only person unable to construct a
>>>
>>>parser.
>>>
>>>
>>>
>>>>in version 14 an aditional flag has been added which is not available
>>>
>>>in the
>>>
>>>
>>>
>>>>Chapter 9. Is the isCA flag an orthogonal attribut to other
>>>
> validation
> 
>>>>algorithms, or just to some of them, e.g,. the default name matching
>>>
>>>one? 
>>>
>>>
>>>
>>>>  Query ::= SEQUENCE { 
>>>>    queriedCerts            SEQUENCE SIZE (1..MAX) OF CertReference,
>>>
>>>
>>>>    checks                  CertChecks, 
>>>>    wantBack                WantBack, 
>>>>    requestRefHash          BOOLEAN DEFAULT TRUE, 
>>>>    includePolResponce      BOOLEAN DEFAULT FALSE, 
>>>>    inhibitPolMap           BOOLEAN DEFAULT FALSE, 
>>>>    requireExplicitPol      BOOLEAN DEFAULT FALSE, 
>>>>    ignoreAnyPol            BOOLEAN DEFAULT FALSE, 
>>>>    isCA                    BOOLEAN DEFAULT FALSE, 
>>>>    valAlgorithm            ValidationAlgorithm, 
>>>>    serverContextInfo   [0] OCTET STRING OPTIONAL, 
>>>>    validityTime        [1] GeneralizedTime OPTIONAL, 
>>>>    trustAnchors        [2] TrustAnchors OPTIONAL, 
>>>>    intermediateCerts   [3] CertBundle OPTIONAL, 
>>>>    revInfos            [4] RevocationInfos OPTIONAL, 
>>>>    keyUsage            [5] KeyUsage OPTIONAL, 
>>>>    extendedKeyUsage    [6] ExtKeyUsageSyntax OPTIONAL, 
>>>>    queryExtensions     [7] Extensions OPTIONAL  
>>>>    producedAt          [8] GeneralizedTime OPTIONAL} 
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i41MkTFj024612; Sat, 1 May 2004 15:46:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i41MkTVp024611; Sat, 1 May 2004 15:46:29 -0700 (PDT)
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.9) with ESMTP id i41MkSrq024604 for <[e-mail]>; Sat, 1 May 2004 15:46:28 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani3 (pcp09271907pcs.arlngt01.va.comcast.net [69.143.130.247]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id i41MkUJA000603 for <[e-mail]>; Sat, 1 May 2004 18:46:30 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: Cross certificate format
Date: Sat, 1 May 2004 18:46:26 -0400
Message-ID: <004101c42fce$25dd3900$[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.6626
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
In-Reply-To: <[e-mail]>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id i41MkSrq024606
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom:

The standard does not require you to check how you initialize the variables.
You can get these from the cross certificate or from some configuration.

The basic point is that you trust the public key.  How you constrain it is
not address by the standard, where as if the same certificate appeared in a
path, you have to apply the constraints or be not compliant with the
standard.

You obviously do not believe in re-incarnation.  Just kidding......

-----Original Message-----
From: Tom Gindin [mailto:[e-mail]] 
Sent: Saturday, May 01, 2004 6:31 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Cross certificate format


        Santosh:

        It is well known that trust in a trust anchor can be defined in a 
variety of ways.  However, there is every reason to think that an RP may 
constrain that trust and that the constraints he may apply include those 
which an issuer CA may apply to a subordinate one. The wording of RFC 3280 
section 6.2's first paragraph is an example of this.
        My comments about the meaning of a trust anchor are not purely 
theoretical.  If a cross certificate is used to represent a trust anchor, 
the variables permitted_subtrees (RFC 3280 6.1.2 b) and excluded_subtrees 
(RFC 3280 6.1.2 c) could easily be set from the contents of a 
NameConstraints extension, and the variable max_path_length (RFC 3280 
6.1.2 k) from the contents of a BasicConstraints extension.  In RFC 3280 
today, these variables are set to constants (although that interpretation 
is not absolutely clear for permitted_subtrees).  In fact, they are three 
of the four variables which are set to constants during initialization.
        If permitted subtrees were set to a list of attributes, the 
validation process would fail if the anchor CA or a CA it certified went 
beyond the restrictions of those attributes.  Likewise, if the excluded 
subtrees were set to a list of attributes, the validation process would 
fail if the anchor CA or a CA it certified went used values matching any 
of those attributes.  I do not believe that I am arguing against Galileo.

                Tom Gindin






"Santosh Chokhani" <[e-mail]>
Sent by: [e-mail]
04/29/2004 11:12 PM

 
        To:     <[e-mail]>
        cc: 
        Subject:        RE: Cross certificate format




Tom:

The basic point (at the risk of repeating myself) is that a CA certificate
or a self-signed certificate can be used as a means to provide trust 
anchor
information.  In that case, there is no need to check signature or 
anything.

But, when the CA certificate is a certificate in the certificate path, 
X.509
logic kicks in.

This is consistent with X.509, 3280 and general security principles since
the trust in a trust anchor can be derived through any number of means.

If you do not agree, feel free to argue against the definitions and 
Galileo

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
On
Behalf Of Tom Gindin
Sent: Thursday, April 29, 2004 8:43 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Cross certificate format



        Santosh:

        I don't think that a CA certificate and a trust anchor are as much 

different things as different uses for the same thing.  They are both 
identifiers of issuers which bind a public key to an issuer name, and it 
is perfectly appropriate for any CA certificate to represent a trust 
anchor.  I also do not see why such things as name constraints on a trust 
anchor are inappropriate.  It is perfectly true that verifying a trust 
anchor's certificate, when issued by another CA (who may not be trusted) 
is a pointless operation.

                Tom Gindin





"Santosh Chokhani" <[e-mail]>
Sent by: [e-mail]
04/27/2004 09:14 AM

 
        To:     <[e-mail]>
        cc: 
        Subject:        RE: Cross certificate format




Tom:

My point is that even if the trust anchor is a self-signed certificate, 
all
you need to do is extract the required information.  There is no need to
examine anything.

Cross certificate and trust anchor are very different things.  An element 
of
the cross certificate pair is nothing but an intermediate CA certificate 
in
a certification path.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
On
Behalf Of Tom Gindin
Sent: Tuesday, April 27, 2004 7:33 AM
To: Santosh Chokhani
Cc: [e-mail]; [e-mail]
Subject: RE: Cross certificate format



        Santosh:

        Of course, you are right that RFC 3280 6.1.1 d permits trust 
anchor information to be provided outside a certificate.  If it is so, no 
checks of the sort I indicated can be performed.  It also says that it can 


be provided as "a self-signed certificate", with no further qualification. 


 I do think it is somewhat odd that a self-signed certificate with 
KeyUsage set to typical EE values would be considered a valid issuer as a 
trust anchor while a cross certificate would not.  You can always extract 
the needed anchor information from a cross-certificate, of course.

                Tom Gindin





"Santosh Chokhani" <[e-mail]>
Sent by: [e-mail]
04/26/2004 08:51 AM

 
        To:     <[e-mail]>
        cc: 
        Subject:        RE: Cross certificate format




Tom:

My reading of 3280 and X.509 is that a trust anchor need not even be a
certificate.  Thus, no checks need to be performed on a trust anchor at 
all.
You get the DN, public key, algorithm OID, and parameters (if applicable)
from a trust anchor.  Any checks are gratuitous and not required by either
standard.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
On
Behalf Of Tom Gindin
Sent: Sunday, April 25, 2004 7:06 PM
To: Jean-Marc Desperrier
Cc: [e-mail]
Subject: Re: Cross certificate format



        Jean-Marc:

        RFC 3280 doesn't say that anywhere.  It does say that you don't 
need to validate the trust anchor as part of the path, but it isn't clear 
from the text that a v1 certificate is acceptable as a trust anchor - and 
it certainly isn't clear that a v1 certificate is acceptable as an issuer 
if it is a trust anchor while a v3 certificate with KeyUsage= { 
DigitalSignature, keyEncipherment } is not acceptable as an issuer even if 



it is a trust anchor.
        I believe that the correct rules for versions are something like 
the following: a certificate issued by a trust anchor which is represented 



by a certificate is verifiable if the anchor certificate is either a v1 
certificate or a v3 certificate with the CA flag present in the 
basicConstraints extension.  If the anchor certificate is a v3 certificate 



with the KeyUsage extension present, it is only a valid issuer certificate 



if keyCertSign is set.

        Tom Gindin





Jean-Marc Desperrier <[e-mail]>
Sent by: [e-mail]
04/21/2004 03:42 PM

 
        To:     [e-mail]
        cc: 
        Subject:        Re: Cross certificate format




Tom Gindin wrote:

>        RFC 3280 does not support the use of v1 self-signed
> certificates,

>which contain no extensions at all (see the text of RFC 3280's 
>basicConstraints section).  However, a number of public CA's still have 
>them.
> 
>
Applications implementing the path validation algorithm of RFC3280 MUST 
accept them when they are used as trust anchors.
 



















Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i41MV3PN020769; Sat, 1 May 2004 15:31:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id i41MV3mh020768; Sat, 1 May 2004 15:31:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id i41MV2L1020759 for <[e-mail]>; Sat, 1 May 2004 15:31:02 -0700 (PDT) (envelope-from [e-mail])
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e2.ny.us.ibm.com (8.12.10/8.12.2) with ESMTP id i41MV1iJ390602; Sat, 1 May 2004 18:31:01 -0400
Received: from d01ml062.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by northrelay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i41MVV2M102712; Sat, 1 May 2004 18:31:31 -0400
To: "Santosh Chokhani" <[e-mail]>
Cc: [e-mail]
MIME-Version: 1.0
Subject: RE: Cross certificate format
X-Mailer: Lotus Notes Release 5.0.11   July 24, 2002
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Sat, 1 May 2004 18:30:55 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.0.2CF2 HFB2|March 16, 2004) at 05/01/2004 18:31:00, Serialize complete at 05/01/2004 18:31:00
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Santosh:

        It is well known that trust in a trust anchor can be defined in a 
variety of ways.  However, there is every reason to think that an RP may 
constrain that trust and that the constraints he may apply include those 
which an issuer CA may apply to a subordinate one. The wording of RFC 3280 
section 6.2's first paragraph is an example of this.
        My comments about the meaning of a trust anchor are not purely 
theoretical.  If a cross certificate is used to represent a trust anchor, 
the variables permitted_subtrees (RFC 3280 6.1.2 b) and excluded_subtrees 
(RFC 3280 6.1.2 c) could easily be set from the contents of a 
NameConstraints extension, and the variable max_path_length (RFC 3280 
6.1.2 k) from the contents of a BasicConstraints extension.  In RFC 3280 
today, these variables are set to constants (although that interpretation 
is not absolutely clear for permitted_subtrees).  In fact, they are three 
of the four variables which are set to constants during initialization.
        If permitted subtrees were set to a list of attributes, the 
validation process would fail if the anchor CA or a CA it certified went 
beyond the restrictions of those attributes.  Likewise, if the excluded 
subtrees were set to a list of attributes, the validation process would 
fail if the anchor CA or a CA it certified went used values matching any 
of those attributes.  I do not believe that I am arguing against Galileo.

                Tom Gindin






"Santosh Chokhani" <[e-mail]>
Sent by: [e-mail]
04/29/2004 11:12 PM

 
        To:     <[e-mail]>
        cc: 
        Subject:        RE: Cross certificate format




Tom:

The basic point (at the risk of repeating myself) is that a CA certificate
or a self-signed certificate can be used as a means to provide trust 
anchor
information.  In that case, there is no need to check signature or 
anything.

But, when the CA certificate is a certificate in the certificate path, 
X.509
logic kicks in.

This is consistent with X.509, 3280 and general security principles since
the trust in a trust anchor can be derived through any number of means.

If you do not agree, feel free to argue against the definitions and 
Galileo

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
On
Behalf Of Tom Gindin
Sent: Thursday, April 29, 2004 8:43 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: Cross certificate format



        Santosh:

        I don't think that a CA certificate and a trust anchor are as much 

different things as different uses for the same thing.  They are both 
identifiers of issuers which bind a public key to an issuer name, and it 
is perfectly appropriate for any CA certificate to represent a trust 
anchor.  I also do not see why such things as name constraints on a trust 
anchor are inappropriate.  It is perfectly true that verifying a trust 
anchor's certificate, when issued by another CA (who may not be trusted) 
is a pointless operation.

                Tom Gindin





"Santosh Chokhani" <[e-mail]>
Sent by: [e-mail]
04/27/2004 09:14 AM

 
        To:     <[e-mail]>
        cc: 
        Subject:        RE: Cross certificate format




Tom:

My point is that even if the trust anchor is a self-signed certificate, 
all
you need to do is extract the required information.  There is no need to
examine anything.

Cross certificate and trust anchor are very different things.  An element 
of
the cross certificate pair is nothing but an intermediate CA certificate 
in
a certification path.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
On
Behalf Of Tom Gindin
Sent: Tuesday, April 27, 2004 7:33 AM
To: Santosh Chokhani
Cc: [e-mail]; [e-mail]
Subject: RE: Cross certificate format



        Santosh:

        Of course, you are right that RFC 3280 6.1.1 d permits trust 
anchor information to be provided outside a certificate.  If it is so, no 
checks of the sort I indicated can be performed.  It also says that it can 


be provided as "a self-signed certificate", with no further qualification. 


 I do think it is somewhat odd that a self-signed certificate with 
KeyUsage set to typical EE values would be considered a valid issuer as a 
trust anchor while a cross certificate would not.  You can always extract 
the needed anchor information from a cross-certificate, of course.

                Tom Gindin





"Santosh Chokhani" <[e-mail]>
Sent by: [e-mail]
04/26/2004 08:51 AM

 
        To:     <[e-mail]>
        cc: 
        Subject:        RE: Cross certificate format




Tom:

My reading of 3280 and X.509 is that a trust anchor need not even be a
certificate.  Thus, no checks need to be performed on a trust anchor at 
all.
You get the DN, public key, algorithm OID, and parameters (if applicable)
from a trust anchor.  Any checks are gratuitous and not required by either
standard.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
On
Behalf Of Tom Gindin
Sent: Sunday, April 25, 2004 7:06 PM
To: Jean-Marc Desperrier
Cc: [e-mail]
Subject: Re: Cross certificate format



        Jean-Marc:

        RFC 3280 doesn't say that anywhere.  It does say that you don't 
need to validate the trust anchor as part of the path, but it isn't clear 
from the text that a v1 certificate is acceptable as a trust anchor - and 
it certainly isn't clear that a v1 certificate is acceptable as an issuer 
if it is a trust anchor while a v3 certificate with KeyUsage= { 
DigitalSignature, keyEncipherment } is not acceptable as an issuer even if 



it is a trust anchor.
        I believe that the correct rules for versions are something like 
the following: a certificate issued by a trust anchor which is represented 



by a certificate is verifiable if the anchor certificate is either a v1 
certificate or a v3 certificate with the CA flag present in the 
basicConstraints extension.  If the anchor certificate is a v3 certificate 



with the KeyUsage extension present, it is only a valid issuer certificate 



if keyCertSign is set.

        Tom Gindin





Jean-Marc Desperrier <[e-mail]>
Sent by: [e-mail]
04/21/2004 03:42 PM

 
        To:     [e-mail]
        cc: 
        Subject:        Re: Cross certificate format




Tom Gindin wrote:

>        RFC 3280 does not support the use of v1 self-signed 
> certificates,

>which contain no extensions at all (see the text of RFC 3280's
>basicConstraints section).  However, a number of public CA's still have 
>them.
> 
>
Applications implementing the path validation algorithm of RFC3280 MUST 
accept them when they are used as trust anchors.