Re: [lamps] WG Last Call: draft-ietf-lamps-x509-policy-graph-01

[David Benjamin <[e-mail]>]

Hmm. I share your feelings on this feature, but changing things here wasn't
the intent. I did write it simplifies the process, but the new algorithm
still preserved them. It RECOMMENDS not keeping them, but if you find them
useful, you can still implement the new algorithm:

> Calculate the user_constrained_policy_set as follows. The
user_constrained_policy_set is a set of policy OIDs, along with associated
policy qualifiers.
https://www.ietf.org/archive/id/draft-ietf-lamps-x509-policy-graph-02.html#section-5.5-2.1.1

> If returning policy qualifiers in the output, collect all qualifiers in
the node, its ancestors, and descendants and associate them with
valid_policy. Returning policy qualifiers in the output is NOT RECOMMENDED.
https://www.ietf.org/archive/id/draft-ietf-lamps-x509-policy-graph-02.html#section-5.5-2.1.2.4.2.2.1

It's true that the document adds a NOT RECOMMENDED on the validator side.
The intent was "if you're building a new API based on this document and
aren't trying to serve such a use case, you're encouraged to ignore this
nonsense". I mostly saw this as the corollary to the existing
recommendation on the CA side: if your PKI doesn't believe in policy
qualifiers, you should not waste your time implementing support for them
because they won't change the result of path validation. (Our validator
throws it away.)

The simplification is that it avoids worrying about an ambiguity in X.509:
if there are two ways to get to some policy, with different qualifiers,
which do you pick? What I've currently written is you just collect all of
them together. Picking an arbitrary path would also be defensible.
Expanding out all the possible paths individual to get different
policy qualifier sets gets us back to the EXP-SPACE problem, so I want to
avoid that. (Since we don't implement it, I don't have any horse in this
race. I said to collect them all because it seemed the most natural
interpretation of the ITU X.509 document, though that document is kinda
ambiguous.) The other nuisance is I'm pretty sure collecting policy
qualifiers, whichever option you pick, is quadratic, but I think the only
remedy for that is to *actually* ban this feature.

Anyway, happy to soften or remove this text if folks prefer.

David

On Mon, Nov 27, 2023 at 3:05 PM Russ Housley <[e-mail]> wrote:

> I am concerned with this paragraph is Section 4.2:
>
>    X.509 implementations are additionally RECOMMENDED to omit policy
>    qualifiers from the output, as this simplifies the process.  Note
>    Section 4.2.1.4 of [RFC5280] conversely recommends that certificate
>    authorities omit policy qualifiers from policy information terms.
>    This document reiterates this and RECOMMENDS that certificate
>    authorities omit the policyQualifiers field in PolicyInformation
>    structures.
>
> This goes against an very long discussion prior to the publication of RFC
> 2459.  I raised the issee again prior to the publication of RFC 3280, and
> again prior to the publication of RFC 5280.  This paragraph reverses those
> discussions, and I am unwilling to do that without signficant discussion
>
> I hate policy qualifiers.  However, I was unable to convince the PKIX WG
> to ban their use.  In 1999, I wrote the message that is copied at the
> bottom of this message.  My opinion has only gotten stronger over the years.
>
> If the policy qualifier is not provided to the application, then all of
> the discussion about their usefulness in certain applications is lost.
> This seems like a backhanded way to eliminate them.
>
> I would be willing to support a separate update to RFC 5280 that forbids
> the use of policy qualifiers, but I do not think that removing them from
> this algorithm is the right way forward.
>
> Russ
>
>
>
> ----- BEGIN OLD MESSAGE FROM PKIX MAIL ARCHIVE -----
>
>
> Russ Housley <[e-mail]> Thu, 17 June 1999 16:58 UTC
>
> Persoanally, I really dislike policy qualifiers.  They have a negative
> imapct on interoperability.  If a policy is specified by an OID, then the
> cert path validation does not need to know any details of that policy.  On
> the other hand, when qualifiers are used, cert path validation must
> understand the syntax and possibly the semantics of the qualifier.
>
> How does one get every implementation, especially mass market software
> implementations, to support a particular policy qualifier?  Beats me.  That
> is why they cause interoperability problems.
>
> In drafting RFC 2459, I suggested that policy qualifiers be forbidden.
> Others disagreed, so we have a compromise position documented in RFC 2459.
> It says:
>
>    To promote interoperability, this profile RECOMMENDS that policy
>    information terms consist of only an OID.  Where an OID alone is
>    insufficient, this profile strongly recommends that use of qualifiers
>    be limited to those identified in this section.
>
> A small set of policy qualifiers was included with the hope that all
> implementations would include support for them.
>
> So, my advice is to avoid policy qualifiers.
>
> Russ
>
> ----- END OLD MESSAGE FROM PKIX MAIL ARCHIVE -----
>
>