Martin,
Now we released -12 based on my previous response to you as the result of
reflecting your comments.
Additionally,
- Introductionally text:
I basically agree with Stephen. To update the text, I'm talking with
co-authors.
Revised the first sentence in the Abstract as the following:
The objective of this document is to establish a terminology framework
and to suggest the operational requirements of PKI domain for
interoperability of multi-domain Public Key Infrastructure, where each
PKI domain is operated under a distinct policy.
Thanks,
--
Masaki SHIMAOKA <m-shimaoka(_at_)secom(_dot_)co(_dot_)jp>
SECOM IS Lab.
Core Technology Div.
+81 422 76 2105 (4122)
On Thu, 06 Dec 2007 12:57:42 +0900
Masaki SHIMAOKA <m-shimaoka(_at_)secom(_dot_)co(_dot_)jp> wrote:
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 <m-shimaoka(_at_)secom(_dot_)co(_dot_)jp>
SECOM IS Lab.
Core Technology Div.
+81 422 76 2105 (4122)
On Tue, 4 Dec 2007 23:49:05 -0500
Stephen Kent <kent(_at_)bbn(_dot_)com> wrote:
At 7:34 PM +0100 12/4/07, Martin Rex wrote:
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
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf