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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf