Subject: I-D ACTION:draft-ietf-pkix-certpathbuild-00.txt

From: [email-masked]
Date: Thu, 03 Jul 2003 11:32:03 -0400

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

	Title		: Internet X.509 Public Key Infrastructure:       
                          Certification Path Building
	Author(s)	: M. Cooper, Y. Dzambasow
	Filename	: draft-ietf-pkix-certpathbuild-00.txt
	Pages		: 59
	Date		: 2003-7-3
	
This document was written to provide 'best practice' guidance and 
recommendations to developers building X.509 public-key certification 
paths within their applications.  By following the guidance and 
recommendations defined in this document, an application developer is 
more likely to develop a robust X.509 certificate enabled application 
that can build valid certification paths across a wide range of PKI 
environments.

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Masaki SHIMAOKA <[email-masked]>
Date: Wed, 23 Jul 2003 12:11:58 +0900

Dear Cooper,

> 	Filename	: draft-ietf-pkix-certpathbuild-00.txt

This is an excellent trial.

Sorry for my delayed comments below.

1. path building over http

This text gives an example as path building algorithm based over LDAP.
Shall we consider also about a path building algorithm over http?
# I know and agree that  basically path building is used in the
environment which have directory system.
IMHO, path building over http may be achieved using cAIssuers
accessMethod in AIA extension, but it only describes single path like
strict hierarchy.

2. forward direction vs. reverse direction

My basic opinion is shown below as hybrid path building.
=====
Path building in the forward direction is very useful for tree topology
that each node has unique parent.
However, when each node has plural parent (e.g., mesh PKI or bi-lateral
cross-certified PKI), this method is useful only a bit.
First, therefore, a builder SHOULD attempt to build a path in the
forward direction till a self-signed certificate (or maybe intermediate
certificate issued by plural CAs).
Then, the builder MAY attempt to build the remain path either way.

        2) Path building by the reverse direction
        ----------------------------------------->
   +---------+     +--------------+      +-------------+   
   | Trusted |     | Intermediate |      | Self-Signed |   
   |  Root   |---->|  Certificate |----->| Certificate |   ^
   +---------+     +--------------+      +-------------+   |
                                                |          |
                                                |          |
                                                v          |
                                        +----------------+ | 1) Path
                                        |  Intermediate  | | building
                                        | Certificate(*) | |    by
                                        +----------------+ |  forward 
                                                 |         | direction
                                                 |         |
                                                 v         |
                                         +--------------+  |
                                         |     Target   |  |
                                         |  Certificate |   
                                         +--------------+   
        (*) Not self-signed certificate.
# I know more consideration yet is required for this.
=====

And this topic has one problem.
Some subordinate CA populate their CA certificate to issuedToThisCA of
crossCertificatePair attribute in their own (CA) directory entry. On the
other hand, most cross-certified (not subordinate) CA also populates
their cross-certificate to same location.
When a path builder attempts hybrid building as above, the builder in
second step (reverse direction) does not require obtaining the
subordinate CA information.

In almost (hierarchical) PKI, path building may finish before second step.
Only in some complex PKI, path building may need second step. Anyway,
this hybrid algorithm is useful for every PKI, I think.

3. Static path vs. Dynamic path
Static certification path means that the client is given beforehand all
certificates and all revocation information required for path validation.
On the other hand, dynamic certification path means that the client at
least must obtain some certificates and revocation information required
for path validation. Dynamic certification path may use some
certificates and revocation information in certificate store or local
cache.
For a client that cannot build a certification path dynamically,
we should consider static certification path, e.g., SSL/TLS handshake.

Your I-D describes that how build a certification path, and my 'memo for
mPKI' I-D aims to support how to design a certification path.
So I hope to review our documents each other frequently.

Best Regards,
-----
Masaki SHIMAOKA

SECOM Trust.net
System Engineering Dpt.
Tel: +81 422 91 8493 (ext.3551)
Fax: +81 422 45 0536
e-mail: [email-masked]

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Fri, 25 Jul 2003 17:45:35 +0800

> 1. path building over http
[snip]
> accessMethod in AIA extension, but it only describes single path like
Not exactly so, if we let caIssuers accessMethod be a HTTP URI points
to a PKCS#7 wrapped certificate list which contains all cross-certificates
issued to the issuer of the nominated certificate, there is no problem to
traverse the whole cross-certification network. However, AIA-assisted
path building only supports forward direction (I mean "from the target
certificate to a trusted root" as defined by the draft.).

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