Re: Critical certificate policies extension

Niklas Matthies <[email protected]> writes:

>Yes, but the flag is set by default, and the documentation [2] notes that if
>it is not set, then the implementation is not PKIX compliant by itself.

That seems incorrect, I'd expect it to be off by default.

Disclaimer: The spec has changed over time and there are inconsistencies
between the body text and the path-processing pseudocode, and in the case of
2459 the two sets of path-processing pseudocode, so there could be something
buried in there that I'm not aware of.  E&OE.

>Right. So I gather that rejecting all certificates containing a critical
>certificate policies extension with an unknown policy OID would be a valid
>interpretation of the RFC requirements I cited.

Uhh... pass.  Technically it's OK if it's in the initial policy set, but then
you get into the rathole of what it means to "regcognise" an extension.  Which
was also debated endlessly on the list, see e.g. the PKIX thread "What is
meant by recognizing critical extensions?" [0].  And then there are additional
RFCs that layer on their own semantics, see for example Qualified Certs where
you have to recognise, meaning in this case act on and process [1], at least
one specific policy OID in the qcStatements saying it's a qualified cert.

Peter.

[0] You are not actually expected to read through these things; insanity may
    result.
[1] With the same caveat for "process" as for "recognize".