Re: Issue with the requirements document: PKIX-centric terminology

[Leif Johansson <leifj@xxxxxxxx>]

David A. Cooper wrote:
> Leif,
>
> I am not referring to certificate extensions.  Section 6.1.1 of
> 3280bis lists the following inputs to the path validation algorithm in
> addition to the trust anchor, prospective certification path, and
> current date/time:  user-initial-policy-set,
> initial-policy-mapping-inhibit, initial-explicit-policy,
> initial-any-policy-inhibit, initial-permitted-subtrees, and
> initial-excluded-subtrees.  A TAA may wish to specify values for these
> inputs.  For example, the TAA may say that TA1 may be used with
> application X, but path validation should be performed with
> initial-explicit-policy=TRUE and user-initial-policy-set = {p1, p2}. 
> This may be done because TA1 issues certificates at different
> assurance levels, and certificates issued under some of these
> assurance levels (e.g., p3) are not considered acceptable for use with
> application X.
>
> This has nothing to do with the number of TAs.  Even if there is only
> a single TA, the TAA may wish to specify constraints so that not all
> certificates issued by the TA will be considered valid for use with an
> application.
>
> Dave
Thanks for clearing that up. It makes absolute sense and it sounds like
a reasonable case for typed data associated with TAs in the store. It does
not sound like an argument that the TA store needs to be aware of the
type of TA stored beyond an understanding of which associated data
types are "valid" for a given TA type (and that is only for UI validation
purposes so that you don't accidentally stick a PKIX policy oid next to
a PGP cert and expect things to make sense).
   
    Cheers Leif
>>
>>
>>   
>