Subject: [pkix] TAMP's use by CAs

From: "Andrews, Rick" <[email-masked]>
Date: Tue, 8 Dec 2009 14:51:53 -0800

Has there been any discussion about using TAMP as a standard format for
use by Certificate Authorities to distribute their roots to relying
parties like browsers and app servers? It seems to me it might serve the
purpose of attaching meta-data to roots, like whether a root was
EV-capable, or whether the root can identify web sites, mail users, or
software makers.

-Rick

--
Rick Andrews                 __o    Phone: 650-426-3401
VeriSign, Inc.             _ \>,_   Fax:   650-426-5195
487 E. Middlefield Rd. ...(_)/ (_)  URL:   www.verisign.com
Mountain View, CA  94043            email: [email-masked]

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 08 Dec 2009 23:58:55 +0100

Hi Rick,

One of the core ideas behind breaking out TAF (Trust Anchor Format) was to
provide a list of roots/trust anchors without having to implement the full
TAMP but yet be compatible with the structure of TAMP.

/Stefan 

On 09-12-08 11:51 PM, "Andrews, Rick" <[email-masked]> wrote:

> Has there been any discussion about using TAMP as a standard format for use by
> Certificate Authorities to distribute their roots to relying parties like
> browsers and app servers? It seems to me it might serve the purpose of
> attaching meta-data to roots, like whether a root was EV-capable, or whether
> the root can identify web sites, mail users, or software makers.
>  
> -Rick
> --
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Carl Wallace" <[email-masked]>
Date: Wed, 9 Dec 2009 07:43:19 -0500

TrustAnchorUpdate messages could be used for this purpose as well,
giving the relying party more control over how the trust anchors are
used.  For example, a relying party may add a TA to a trust anchor
store, with the TA's scope limited by a set of constraints (e.g., name
constraints, policy constraints, etc.).  The TA store could later or
periodically download a TrustAnchorUpdate message signed by that TA to
add/remove/edit TAs within the scope established by the relying party.

There's probably a bit of work to be done to define constraints like the
ones that you cite and to ensure those constraints are enforced.  This
is similar to the recent discussion on the list about the potential need
for an EKU constraints extension that would originate with a trust
anchor.  The I-D that describes TA constraints enforcement is not a
working group draft:
http://tools.ietf.org/html/draft-wallace-using-ta-constraints-01.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stefan Santesson
Sent: Tuesday, December 08, 2009 5:59 PM
To: Andrews, Rick; [email-masked]
Subject: Re: [pkix] TAMP's use by CAs

Hi Rick,

One of the core ideas behind breaking out TAF (Trust Anchor Format) was
to provide a list of roots/trust anchors without having to implement the
full TAMP but yet be compatible with the structure of TAMP.

/Stefan 

 
-Rick

________________________________