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

From: "Carl Wallace" <[email-masked]>
Date: Fri, 10 Jul 2009 07:50:56 -0400

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
> >
> >
> > 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
> =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".

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 15 Jul 2009 00:42:28 +0200

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:

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 14 Jul 2009 16:49:43 -0700

>that at least overlap in scope, which may harm interoperability.

And....?

Are you proposing that the IETF abandon its efforts because of the EU's? Or that the EU abandon its work because of the IETF's? Or that the two dissimilar protocols somehow be merged (in a way that would cause less, not greater, confusion)? Or something else?

This is IETF Last Call. Please say what you think should happen in the IETF context with respect to this document.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 15 Jul 2009 02:16:29 +0200

Paul,

I just provided information.

I don't think we can do anything. It is not reasonable for IETF to accept
TSL as bases for our work and it is not possible to turn EU around and
abandon TSL.

However, it has a value to be aware of the situation.

/Stefan

On 09-07-15 1:49 AM, "Paul Hoffman" <[email-masked]> wrote:

> Are you proposing that the IETF abandon its efforts because of the EU's? Or
> that the EU abandon its work because of the IETF's? Or that the two dissimilar
> protocols somehow be merged (in a way that would cause less, not greater,
> confusion)? Or something else?
>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 15 Jul 2009 03:15:30 +0200

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.
> 
> 
>> 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,
>>

---

From: "Carl Wallace" <[email-masked]>
Date: Tue, 14 Jul 2009 20:46:38 -0400

Format)