Subject: Re: Last Call: draft-shimaoka-multidomain-pki (Memorandum for

From: Martin Rex <[email-masked]>
Date: Tue, 4 Dec 2007 19:34:06 +0100 (MET)

The document

> - 'Memorandum for multi-domain Public Key Infrastructure
>    Interoperability'
>    <draft-shimaoka-multidomain-pki-11.txt> as an Informational RFC

creates the impression that "trust anchors" must always be
self-signed CA certificates.

What is a trust anchor MUST remain completely up to local policy (which
might be a client-local policy in some scenarios), there should
be NO restriction whatsoever what can be configured as a trust anchor.

The idea of a trust anchor is that we trust the (public) key of the
trust anchor, that the PKI implementation may perform a reduced
(certificate) path validation only up to the trust anchor.
The management of trust anchors is also completely a local (policy) issue,
i.e. what keys are considered trust anchors, how they are distributed,
managed and updated.

I am violently opposed to the documents requirements and restrictions
what may an what may not be a trust anchor certificate.  Document
published by the IETF (even if just Informational) should neither
make unconditional restrictions (MUST NOT) nor unconditional requirements
(MUST) for the selection of trust anchors.  Instead, Protocols and
implementations SHOULD support the use of arbitrary trust anchors
as desired by local policy.

-Martin

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Stephen Kent <[email-masked]>
Date: Tue, 4 Dec 2007 23:49:05 -0500

>as desired by local policy.

Martin,

You are right that a TA need not be a self-signed cert, although this 
is the most common format for TA representation.

Your statement about how a TA allows a relying party to "perform a reduced
(certificate) path validation" is confusing. I believe that we always 
assume that cert path validation terminates at a TA for the RP. We 
both agree that the selection and management of TAs is purely a local 
matter for each RP.

In general I do not worry too much about what an informational RFC 
that is not the product of a working group says. However, looking at 
the abstract for this document I do see some words that cause me some 
concern, i.e., "The objective of this document is to establish a 
standard terminology for interoperability of multi-domain Public Key 
Infrastructure (PKI), where each PKI Domain is operated under a 
distinct policy ..."

We ought not make such strong statements in a document of this sort. 
I agree that the authors need to soften the wording to indicate that 
this document defines terminology to describe multi-domain PKI 
models, as an aid to discussing issues in these contexts.

Steve

---

From: Masaki SHIMAOKA <[email-masked]>
Date: Thu, 06 Dec 2007 12:57:42 +0900

Stephen and Martin,
# sorry for twice posting.

Thanks for your quick comments.

- Trust Anchor definition:
I agree your comments. I think the term "trust anchor CA" is more
appropriate.

- MUST NOT and MUST for trust anchor:
I understand IETF statement, so I am going to replace "MUST" to
"strongly RECOMMEND" regarding the trust anchor.  

- Introductionally text:
I basically agree with Stephen.  To update the text, I'm talking with
co-authors.

For publishing this document as informational RFC, is there any word I
must consider elsewhere?

Thanks,
-- Shima
-- 
Masaki SHIMAOKA <[email-masked]>
SECOM IS Lab.
Core Technology Div.
+81 422 76 2105 (4122)

On Tue, 4 Dec 2007 23:49:05 -0500