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