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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:stefan@xxxxxxxxxxx]
> Sent: Tuesday, July 14, 2009 6:42 PM
> To: Carl Wallace; Pope, Nick; ietf@xxxxxxxx; ietf-pkix@xxxxxxx
> 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" <CWallace@xxxxxxxxxxxx> 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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-
> >> pkix@xxxxxxxxxxxx] On Behalf Of Pope, Nick
> >> Sent: Friday, July 10, 2009 4:02 AM
> >> To: 'ietf@xxxxxxxx'; ietf-pkix@xxxxxxx
> >> 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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-
> >> pkix@xxxxxxxxxxxx]
> >>> On Behalf Of The IESG
> >>> Sent: 10 July 2009 01:14
> >>> To: IETF-Announce
> >>> Cc: ietf-pkix@xxxxxxx
> >>> 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
> >>> ietf@xxxxxxxx mailing lists by 2009-07-23. Exceptionally,
> >>> comments may be sent to iesg@xxxxxxxx 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".
> >
> > _______________________________________________
> > Ietf mailing list
> > Ietf@xxxxxxxx
> > https://www.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]