summaryrefslogtreecommitdiffstats
path: root/src/include/ipxe/ocsp.h
Commit message (Collapse)AuthorAgeFilesLines
* [build] Mark known reviewed files as permitted for UEFI Secure BootMichael Brown2026-01-141-0/+1
| | | | | | | | | Some past security reviews carried out for UEFI Secure Boot signing submissions have covered specific drivers or functional areas of iPXE. Mark all of the files comprising these areas as permitted for UEFI Secure Boot. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Restructure handling of ASN.1 bit stringsMichael Brown2025-12-011-1/+1
| | | | | | | | | | | | Signature values in ASN.1 tend to be encoded as bit strings rather than octet strings. In practice, no existent signature scheme uses a non-integral number of bytes. Switch to using a standard ASN.1 cursor to hold signature values, to simplify consuming code. Restructure the API to treat entering an ASN.1 bit string in the same way as entering any other ASN.1 type. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ocsp] Accept response certID with missing hashAlgorithm parametersMichael Brown2019-03-101-2/+2
| | | | | | | | | | | | | | | | | | One of the design goals of ASN.1 DER is to provide a canonical serialization of a data structure, thereby allowing for equality of values to be tested by simply comparing the serialized bytes. Some OCSP servers will modify the request certID to omit the optional (and null) "parameters" portion of the hashAlgorithm. This is arguably legal but breaks the ability to perform a straightforward bitwise comparison on the entire certID field between request and response. Fix by comparing the OID-identified hashAlgorithm separately from the remaining certID fields. Originally-fixed-by: Thilo Fromm <Thilo@kinvolk.io> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ocsp] Allow OCSP checks to be disabledMichael Brown2018-03-181-0/+12
| | | | | | | | | Some CAs provide non-functional OCSP servers, and some clients are forced to operate on networks without access to the OCSP servers. Allow the user to explicitly disable the use of OCSP checks by undefining OCSP_CHECK in config/crypto.h. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [ocsp] Centralise test for whether or not an OCSP check is requiredMichael Brown2018-03-181-0/+15
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [legal] Relicense files under GPL2_OR_LATER_OR_UBDLMichael Brown2015-03-021-1/+1
| | | | | | | Relicense files for which I am the sole author (as identified by util/relicense.pl). Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Accept OCSP responses containing multiple certificatesMichael Brown2013-05-291-0/+19
| | | | | | | | | | | | | | RFC2560 mandates that a valid OCSP response will contain exactly one relevant certificate. However, some OCSP responders include extraneous certificates. iPXE currently assumes that the first certificate in the OCSP response is the relevant certificate; OCSP checks will therefore fail if the responder includes the extraneous certificates before the relevant certificate. Fix by using the responder ID to identify the relevant certificate. Reported-by: Christian Stroehmeier <stroemi@mail.uni-paderborn.de> Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Allow an error margin on X.509 certificate validity periodsMichael Brown2012-06-201-8/+0Star
| | | | | | | | | | | | | iPXE has no concept of the local time zone, mainly because there is no viable way to obtain time zone information in the absence of local state. This causes potential problems with newly-issued certificates and certificates that are about to expire. Avoid such problems by allowing an error margin of around 12 hours on certificate validity periods, similar to the error margin already allowed for OCSP response timestamps. Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Construct OCSP check URIMichael Brown2012-05-221-0/+2
| | | | Signed-off-by: Michael Brown <mcb30@ipxe.org>
* [crypto] Add framework for OCSPMichael Brown2012-05-151-0/+108
Add support for constructing OCSP queries and parsing OCSP responses. (There is no support yet for actually issuing an OCSP query via an HTTP POST.) Signed-off-by: Michael Brown <mcb30@ipxe.org>