OCSP makefile - 学习记录 2021/2/19

研二

---

OCSP

轻量级的证书状态查询数据结构，以ASN.1语法作为传输的编码。OCSP被提出的目的是替代CRL，CRL协议的原理是：客户端通过向服务端请求证书撤销列表来确认相应的证书是否已被撤销，证书撤销时间，证书有效期等信息。由于CRL返回的数据量过大，因此对客户端和服务端压力都较大。CRL的提出正是为了解决该问题。在CRL协议中，客户端将需要的证书的编号发给OCSP服务器，服务器通过查询证书状态后直接向客户端返回一个表述证书状态的整数值以及相应的详细信息（详细信息这一项是可选的，服务器发不发都可以）。其中中，整数值的集合包含：成功（0），非法请求（1），内部错误（2），请求重发（3）(这个不太懂），签名请求（5），请求方身份异常（6）。
OCSP遵循RFC6960[1]标准，在RFC中的分类为“Standard Track"，表明其已成为实际应用的国际标准。
OCSP作为查询证书状态的一种协议，包含Request（请求）和Response（应答）两部分。
“请求”部分由客户端或称为用户向服务端发起，至少应包含要查询的证书的编号、签发该证书的CA名称的Hash值、签发该整数的CA公钥的Hash值这三个基本信息。由于不同CA可以签发出相同编号的证书，因此这个仅仅在请求中提供这个证书编号并不能完全唯一地标识证书，因而需要上面提到的两个Hash值来选定相应的CA。
除以上三个必要信息外，OCSP“请求”中还可以选择性地包含：请求发起者对重要信息的签名值（须相应提供签名算法），请求发起者的证书信任链（本人的证书和CA的证书），用于防止重放攻击的随机数等。为了提高可扩展性，OCSP标准中定义了两个扩展域，扩展域中的值可由客户端和服务端自行协商，也就是可以让开发者自行定义。但相应的，OCSP标注中也提供了几个推荐的扩展域可供选择。
“应答”部分是服务端收到客户端的请求后，通过内部查询功能确认证书状态后返回给客户端的回复消息。回复消息包含的信息内容相当弹性，除了一个必须包含的“状态码”外，可以完全不含任何内容，也可以包含相当多的信息。之所以翻译成为“状态码”，而不是“证书状态”，是因为该返回码并不一定表示证书的状态，也可能表示网络请求有误、请求者身份不被OCSP服务器认同等各种状态。事实上，将该返回码称作“错误码”更贴切一些，只不过错误码听起来似乎并不是太亲切。
“应答”部分除了返回状态码外，还可以返回对错误的相应描述，证书状态的更新时间，下次更新时间，有效期，OCSP报文签发日期，服务器对以上数据的签名值等。

makefile

写了个比较大的makefile，复习了一下动态库[2]的知识。

prog:
	gcc -c $(SOURCES) -I $(INCLUDES)
	gcc $(OBJECTS) -o $(TARGET) -fPIC -shared -L. -lASN1

其中*-L.*的作用是设置链接库的位置，"."代表本目录，即 “./”

参考文献

[1] RFC6960: X.509 Internet Public Key Infrastructure Certificate Status Protocol - OCSP, https://tools.ietf.org/html/rfc6960
[2] GCC 编译使用动态链接库和静态链接库: https://blog.csdn.net/orzlzro/article/details/6460058