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