Re[2]: Last Call: draft-shimaoka-multidomain-pki-11.txt

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@secom.co.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@secom.co.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@secom.co.jp>
> SECOM IS Lab.
> Core Technology Div.
> +81 422 76 2105 (4122)
> 
> 
> On Tue, 4 Dec 2007 23:49:05 -0500
> Stephen Kent <kent@bbn.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@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf