Hi Claudio,
Claudio Jeker wrote on Sat, Dec 25, 2021 at 05:48:53PM +0100:
> On Sat, Dec 25, 2021 at 11:36:50AM +0100, Theo Buehler wrote:
>> These extensions MUST be marked critical by the sections of the spec
>> mentioned in the cryptowarnx(). That's determined by the ASN1_BOOLEAN
>> that is extracted and ignored after the FIXME a few lines below each of
>> the two hunks. Rather than getting the info from there, it's easier to
>> use an API call that checks what was already parsed by d2i_X509().
> I like this a lot. OK claudio@
Merely to avoid a misunderstanding:
I have no oponion whatsoever on this rpki-client patch.
> I would love to get rid of X509_V_FLAG_IGNORE_CRITICAL and use a callback
> to ensure the right extensions are critical but I never managed to
> understand how the X509_verify_cert() callback actually works.
> Documentation seems to be non-existent.
Not exactly non-existent, but admittedly very poor indeed.
There is X509_STORE_CTX_set_verify_cb(3), mostly written by
Dr. Stephen Henson in 2009. But it does not really explain how the
callback is used and instead only provides four examples.
The reasons for this being so badly documented are as follows:
1. X.509 PKI Path Validation as specified in RFC 5280 is ridiculously
complicated no matter the implementation.
2. Our API design and implementation was inherited from OpenSSL,
and everybody knows what that means.
3. Our documentation was inherited from OpenSSL, and everybody
knows what that means.
4. Beck@ has embarked on an epic quest to mitigate parts of the
consequences of item 2. Consequently, the surrounding airs
have been saturated with large amounts of dust for quite
some time now.
5. While parts of that dust have arguably started to settle,
the air still feels somewhat dusty to me, and i have been
fearing that spending the several days of work required
to throughly improve this particular part of the documentation
might end up as working straight for the waste paper basket
once beck@ achieves his next major steps forward.
So given that there are literally hundreds of other public API functions
in libcrypto that are still completely undocumented (as opposed to the
verification callback being documented very badly), i so far refrained
from even trying to attack that particular problem...
Yours,
Ingo
