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

[Masaki SHIMAOKA <shimaoka@xxxxxxxxxxx>]

Dear Cooper,

> 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 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: shimaoka@xxxxxxxxxxx