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

RE: Does the problem need solving?

Just have in mind that TA management and certificate policies are controlled by, and serve, different entities.

TA management is the relying party's means to control trust in keys. By configuring the scope of trust in each TA key, the RL can control its use within his environment.
Certificate Policy management is the CA's means to define and limit the use of a particular certificate.

The result may be the same but when the RL has no influence over the content of certificates, TA management and local cross certification are the only means available.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: owner-ietf-trust-anchor@xxxxxxxxxxxxx [mailto:owner-ietf-trust-
> anchor@xxxxxxxxxxxxx] On Behalf Of Santosh Chokhani
> Sent: den 26 juni 2007 02:03
> To: ietf-trust-anchor@xxxxxxxx
> Subject: RE: Does the problem need solving?
> Steve,
> In addition to name constraints, we should permit to associate policy
> related extensions to constrain a TA.  Here is the rationale:
> Certificate policies will be used if a relying party does not want to
> trust a trust anchor for all the policies trust anchor operates under.
> Policy mapping will be used when the relying party acceptable policy
> set
> does not include a TA domain (oops) policy set.  The relying party will
> need to map its policies to TA domain policies.  The relying party
> could
> simply use the policies from the TA domain if the relying party is
> using
> that single TA for the application.  But, when more than one TA are
> used
> by a single application and some of the TAs have different policies,
> this facility is useful.  The relying party could take the union of the
> policies used by the various TAs as its acceptable policy set, but the
> policy mapping approach is cleaner and more flexible.
> Inhibit policy mapping will be used when the relying party wants to
> permit some TAs, but not all TAs to map policies to other domains.
> Naturally, this is only needed if TAs cross certify with other domains
> and the application wants to accept some cross certifications and not
> others.
> In summary, certificate policies should be required.  Policy mapping
> and
> policy constraints one could do without; its feature and complexity
> trade-off.
> -----Original Message-----
> From: owner-ietf-trust-anchor@xxxxxxxxxxxxx
> [mailto:owner-ietf-trust-anchor@xxxxxxxxxxxxx] On Behalf Of Stephen
> Kent
> Sent: Monday, June 25, 2007 10:01 AM
> To: Thomas Hardjono
> Cc: ietf-trust-anchor@xxxxxxxx
> Subject: RE: Does the problem need solving?
> At 2:44 PM -0700 6/22/07, Thomas Hardjono wrote:
> >
> >
> >...
> >
> >Agree, Steve. When I hear "TA" I immediately think X.509.  I was
> >thinking that this BOF/WG would (i) define a minimal X.509 TA (ie. one
> >that is not over-burdened with so many extensions and policy-related
> >information), and (ii) define a *protocol* to manage TA blobs
> >(regardless of what the TA structure finally looks like).
> >
> >/thomas/
> I think we do need to include support in a TA for name constraints,
> to address the sort of problem that Henry Hotz raised.  I am less
> enthusiastic about the policy mapping stuff, but I could be convinced
> otherwise if enough folks say that the policy extension is, pardon
> the pun, critical for them.
> Steve