Beyond the suggested changes to SCT_LIST_validate() et. al. and documentation, IIRC at some point or other I noted that the chain verification status observed in resumed sessions may not be correct if handshakes without valid SCTs are allowed to complete and perhaps get reused.
Even without resumption, applications typically expect to find out chain validity via SSL_get_verify_result(). This suggests the view that SCT validation is a late phase of chain validation, and that if SCT processing is enabled, but no valid SCTs are presented, while the verify result is X509_V_OK, it perhaps ought to be set to some (new) error value, and as a result remain set in resumed sessions. This means that the difference between the permissive and the strict callback would be only in the return value, both would still look for at least one valid SCT and set an X509_V_ERR_<...> if still X509_V_OK (do not override any prior X509 error). It is unfortunate that we're doing SCT at the SSL layer and not the X.509 layer, but sadly it seems that not all the SCTs are available at the time we're processing the peer's certificate message. (stapled OCSP is after the chain IIRC). So this issue should be dealt with (or decided to be a non issue) in the next few days before beta2. -- Viktor. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4502 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev