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@xxxxxxxxxxx>
SECOM IS Lab.
Core Technology Div.
+81 422 76 2105 (4122)
On Thu, 06 Dec 2007 12:57:42 +0900
Masaki SHIMAOKA <m-shimaoka@xxxxxxxxxxx> 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@xxxxxxxxxxx>
> SECOM IS Lab.
> Core Technology Div.
> +81 422 76 2105 (4122)
>
>
> On Tue, 4 Dec 2007 23:49:05 -0500
> Stephen Kent <kent@xxxxxxx> 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@xxxxxxxx
> > https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf