Subject: Re: Changes to RFC2459

From: [email-masked]
Date: Wed, 24 Mar 1999 10:54:06 +0100 (MET)

Since nobody gave any comments to my previous mail about equivalent policies
in a basic path validation procedure, I would like to rise this issue again.
Is there a particular reason why certificates from policy mappings extension 
are not explicitly mentioned in the path processing actions in RFC 2459? 
The acceptable policy set in the procedure is defined as 

"a set of certificate policy identifiers comprising the policy or policies 
recognized by the public key user together with policies deemed equivalent 
through policy mapping. The initial value of the acceptable policy set is
the special value "any-policy".

Since in each step of the algorithm the acceptable policy set is obtained
as the intersection of the old value and critically marked policies extension,
does this mean that equivalent policies from the policy mappings extension
are added to the initial policy set and the acceptable policy set somewhere
in items (d) and (e) of the algorithm? Or is it assumed that for the 
computation of intersections (items g and h) equivalent policies are actually 
the same? In this case, is the definition of the acceptable policy set correct?

Regards,

Tomaz Klobucar

---

From: Tim Polk <[email-masked]>
Date: Wed, 24 Mar 1999 10:02:08 -0500

Tomaz,

I missed your earlier email, but you are right.  This section has a couple
of problems that were pointed out to me in the last week (off-list).

The omission of mapping is an oversight in the specification., and I will
be fixing it.  The acceptable policy set should be a state variable, not a
constant.  The text includes a catch-all (apply critical extensions,) but
that is insufficient.  This section deserves more detail.

There is also an X.509 defect report that may affect this section.  The
gist of the defect report is that mapping should be performed *before* the
comparison step.  PKIX is silent on this but the current X.509 text
specifies that mapping occurs afterwards.

The X.509 folks will settle this one in May, but I am guessing they will
agree and make the change.

I will have new text for this section next week, and will post it here for
discussion.  The new text will *assume* the defect report is approved with
the requested change.

Thanks,

Tim Polk