Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 9 Jul 2009 17:13:41 -0700 (PDT)

The IESG has received a request from the Public-Key Infrastructure 
(X.509) WG (pkix) to consider the following document:

- 'Trust Anchor Format '
   <draft-ietf-pkix-ta-format-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2009-07-23. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-03.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17759&rfc_flag=0

---

From: "Pope, Nick" <[email-masked]>
Date: Wed, 15 Jul 2009 10:24:39 +0100

All,

I accept that we may not be able to change at this stage the TAF but we both
should bear in mind the existence the two solutions which need exist
together.

Nick

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Stefan Santesson
> Sent: 15 July 2009 02:16
> To: Carl Wallace; Pope, Nick; [email-masked]; [email-masked]
> Subject: Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to
> Proposed Standard
> 
> 
> Carl,
> 
> I agree with most of your assessment.
> 
> But Yes, there are interoperability issues on the larger scale.
> One current example is for example that the European and American Bridging
> CA models are incompatible from a technical perspective as the American
> model builds on cross certification while the European model builds on
> availability of TSLs.
> 
> A potential real impact scenario is that products may have to incorporate
> both architectures in order to function in both worlds. That is something
> I
> as standards guy would be pleased to avoid.
> 
> However, I don't think there is much we neither can or should do to change
> this.
> 
> 
> On 09-07-15 2:46 AM, "Carl Wallace" <[email-masked]> wrote:
> 
> >
> > TAF works with existing systems that use certificates as trust anchors
> > (a certificate is a TrustAnchorChoice object), offers a minor change to
> > that practice to allow relying parties to associate constraints with
> > certificates using syntax that is widely available (TBSCertificate) and
> > offers a minimal representation of trust anchor information for folks
> > who require such (TrustAnchorInfo).  I don't see an interoperability
> > issue with TAF.  Applications will use the appropriate format that meets
> > its needs.  Certificates are not suitable as trust anchors in all cases.
> > TAF is a relatively minimal, natural solution to this problem.
> >
> >
> >> -----Original Message-----
> >> From: Stefan Santesson [mailto:[email-masked]]
> >> Sent: Tuesday, July 14, 2009 6:42 PM
> >> To: Carl Wallace; Pope, Nick; [email-masked]; [email-masked]
> >> Subject: Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
> > Format)
> >> to Proposed Standard
> >>
> >> Carl,
> >>
> >> I think the critique of the TSL work is well founded from the
> >> perspective of
> >> TAM, but there is nevertheless an important point here.
> >>
> >> While TSL might not be an ideal standard for automated trust anchor
> >> management, very much caused by its mixed scope of fields for both
> >> human and
> >> machine consumption, it has despite this become a central component
> > for
> >> efforts in Europe, supported by the EU commission, to provide a common
> >> framework for trust in CAs in Europe.
> >>
> >> There is a substantial risk that we will see two very different
> >> approaches
> >> that at least overlap in scope, which may harm interoperability.
> >>
> >> /Stefan
> >>
> >>
> >>
> >> On 09-07-10 1:50 PM, "Carl Wallace" <[email-masked]> wrote:
> >>
> >>> This document has been discussed previously relative to TAF.  A
> >> portion
> >>> of that discussion is here:
> >>> http://www.imc.org/ietf-pkix/mail-archive/msg05573.html.
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: [email-masked] [mailto:owner-ietf-
> >>>> [email-masked]] On Behalf Of Pope, Nick
> >>>> Sent: Friday, July 10, 2009 4:02 AM
> >>>> To: [email-masked]'; [email-masked]
> >>>> Subject: RE: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
> >>> Format)
> >>>> to Proposed Standard
> >>>>
> >>>>
> >>>> Perhaps the authors should be aware of the existing European
> >> Technical
> >>>> Specification for trust status lists (TS 102 231), which have some
> >>>> overlap
> >>>> in function with the Trust anchor list in this internet draft.
> >>>>
> >>>> This is being adopted by all EU member states as a means of
> >> publishing
> >>>> information on CA recognised as trustworthy under the national
> >>>> accreditation
> >>>> or supervisory schemes.
> >>>>
> >>>> To obtain a copy go to:
> >>>>
> >>>> http://pda.etsi.org/pda/queryform.asp
> >>>>
> >>>> and enter TS 102 231 in the search box.
> >>>>
> >>>> Nick Pope
> >>>> Thales e-Security Ltd
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: [email-masked] [mailto:owner-ietf-
> >>>> [email-masked]]
> >>>>> On Behalf Of The IESG
> >>>>> Sent: 10 July 2009 01:14
> >>>>> To: IETF-Announce
> >>>>> Cc: [email-masked]
> >>>>> Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
> > Format)
> >>>> to
> >>>>> Proposed Standard
> >>>>>
> >>>>>
> >>>>> final comments on this action.  Please send substantive comments
> > to
> >>>> the
> > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag
> >>>> =17
> >>>>> 759&rfc_flag=0
> >>>> Consider the environment before printing this mail.
> >>>> "Thales e-Security Limited is incorporated in England and Wales
> > with
> >>>> company
> >>>> registration number 2518805. Its registered office is located at 2
> >>>> Dashwood
> >>>> Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge,
> >> Surrey
> >>>> KT15
> >>>> 2NX.
> >>>> The information contained in this e-mail is confidential. It may
> >> also
> >>>> be
> >>>> privileged. It is only intended for the stated addressee(s) and
> >> access
> >>>> to it
> >>>> by any other person is unauthorised. If you are not an addressee or
> >>> the
> >>>> intended addressee, you must not disclose, copy, circulate or in
> > any
> >>>> other
> >>>> way use or rely on the information contained in this e-mail. Such
> >>>> unauthorised use may be unlawful. If you have received this e-mail
> >> in
> >>>> error
> >>>> please delete it (and all copies) from your system, please also
> >> inform
> >>>> us
> >>>> immediately on +44 (0)1844 201800 or email postmaster@thales-
> >>>> esecurity.com.
> >>>> Commercial matters detailed or referred to in this e-mail are
> >> subject
> >>>> to a
> >>>> written contract signed for and on behalf of Thales e-Security
> >>>> Limited".
> >>>
> >>> _______________________________________________
> >>> Ietf mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/ietf
> >>
> >

Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email [email-masked].
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited".