SET协议

安全电子交易协议(SET，Secure Electronic Transaction) 由威士(VISA)国际组织、万事达(MasterCard)国际组织创建，结合IBM、Microsoft、Netscope、GTE等公司制定的电子商务中安全电子交易的一个国际标准，是一种基于消息流的协议。

SET协议是基于信用卡支付模式而设计的。它保证了开放网络上使用信用卡进行在线购物的安全，是一个专门针对于信用卡电子支付的安全协议，保证银行，商家和顾客之间的一致性和安全性问题，通过SET协议可以实现电子商务交易中的加密、认证、密钥管理机制等，具有保证交易数据的完整性，交易的不可抵赖性等种种优点，因此它成为目前公认的信用卡网上交易的国际标准。

六大组件：持卡人，商家，支付网关，清算机构，发卡机构，CA。 

 1、电子交易必备安全的因素

1）身份合法性：验证商家和我们消费者的身份，要保证不是第三方来冒充的。

2）抗抵赖性：，就是就发生过的形为，是不能抵赖的。

3）完整性：要保证信息在传送中没有被别人篡改。

4）机密性：第三方不可以看到我们所购买的物品的具体内容，要保证信息的机密性，不让第三方看到，特别是账号和密码的信息机密性。

2、主要目标

SET是一个复杂的协议，它详细而准确地反映了卡交易各方之间的各种关系。事实上，SET不只是一个技术方面的协议，它还说明了每一方所持有的数字证书的合法含义，希望得到数字证书以及响应信息的各方应有的动作，与一笔交易紧密相关的责任分担。SET是一个基于可信的第三方认证中心的方案，其主要目的是解决信用卡电子付款的安全保障性问题，这包括：保证信息的机密性，保证信息安全传输，不能被窃听，只有收件人才能得到和解密信息；保证支付信息的完整性，保证传输数据完整接收，在中途不被篡改；认证商家和客户，验证公共网络上进行交易活动。

 它要实现的主要目标有下列三个方面。

1）保障付款安全：确保付款资料的隐密性及完整性，提供持卡人、特约商店、收单银行的认证，并定义安全服务所需要的算法及相关协定。

2）确定应用的互通性：提供一个开放式的标准。明确定义细节，以确保不同厂商开发的应用程序可共同运作，促成软件互通；在现存各种标准下构建协定，允许在任何软硬件平台上执行，使标准达到相容性与接受性目标。

3）达到全球市场的接受性：在容易使用与对特约商店、持卡人影响最小的前提下，达到全球普遍性。允许在目前使用者的应用软件下，嵌入付款协定的执行，对收单银行与特约商店、持卡人与发卡银行间的关系，以及信用卡组织的基础构架改变最少。

3、工作流程

SET主要用于消费者与商店、商店与收单银行（付款银行）之间。其运作方式参照图：简述如下：

 ①消费者在验证商家的CA证书之后，发送给商家有订购信息和支付信息的用顾客签名加密了的信息，使用双重签名技术使商家只能得到订购信息，得不到支付信息；

在消费者与特约商店之间，由持卡人在消费前先确认商店的合法性，由商店出示它的证书。

②商家验证消费者身份，通过网关，清算机构，向发卡机构确认交易；

持卡人确认后即可下订单，其订单经消费者以数字签名方式确认，而消费者所提供的信用卡资料则另由收单银行以公钥予以加密。这里，特约商店会收到两个经过加密的资料，其中一个是订单资料，另一个是关于支付的资料；按规定特约商店可以解密前者，但无法解密后者，以避免特约商店搜集或滥用持卡人消费资料。

③特约商店将客户的资料连同自己的SET证书发给收单银行，向银行请求交易授权及授权回复。收单银行同时检验两个证书以确定是否为合法的持卡人及特约商店。所以，收单银行由支付网关来解密，核对资料无误后，再连接到传统的网络（比如Visa或MasterCard）进行交易授权及清算。

④授权确认后由特约商店向消费者再行确认订单，交易完成。

⑤特约商店基于该授权向收单银行提出请款的要求。

⑥支付网关通知持卡人开户行向商家开户行付款。

4、SET的安全性

1.采用公钥加密和私钥加密相结合的办法保证数据的保密性

SET协议中，支付环境的信息保密性是通过公钥加密法和私钥加密法相结合的算法来加密支付信息而获得的。它采用的公钥加密算法是RSA的公钥密码体制，私钥加密算法是采用DES数据加密标准。这两种不同加密技术的结合应用在SET中被形象的成为数字信封，RSA加密相当于用信封密封，消息首先以56位的DES密钥加密，然后装入使用1024位RSA公钥加密的数字信封在交易双方传输。这两种密钥相结合的办法保证了交易中数据信息的保密性。

2.采用信息摘要技术保证信息的完整性

SET协议是通过数字签名方案来保证消息的完整性和进行消息源的认证的，数字签名方案采用了与消息加密相同的加密原则。即数字签名通过RSA加密算法结合生成信息摘要，信息摘要是消息通过HASH函数处理后得到的唯一对应于该消息的数值，消息中每改变一个数据位都会引起信息摘要中大约一半的数据位的改变。而两个不同的消息具有相同的信息摘要的可能性及其微小，因此HASH函数的单向性使得从信息摘要得出信息的摘要的计算是不可行的。信息摘要的这些特征保证了信息的完整性。

3.采用双重签名技术保证交易双方的身份认证

SET协议应用了双重签名（Dual Signatures）技术。在一项安全电子商务交易中，持卡人的定购信息和支付指令是相互对应的。商家只有确认了对应于持卡人的支付指令对应的定购信息才能够按照定购信息发货；而银行只有确认了与该持卡人支付指令对应的定购信息是真实可靠的才能够按照商家的要求进行支付。为了达到商家在合法验证持卡人支付指令和银行在合法验证持卡人订购信息的同时不会侵犯顾客的私人隐私这一目的，SET协议采用了双重签名技术来保证顾客的隐私不被侵犯。

关键技术

1）电子信封:用对方的公钥加密用来通信的对称密钥，形成一个装着密钥的信封，将密钥传递给对方；

2）双重签名:用于分离支付信息和订购信息；

前言与摘要

背景要求

• 证书申请的基本原理：可以参考《图解密码技术》-- 结城浩 – 第十章 证书。
• 了解基本的openssl 命令行使用。

摘要

本文没有介绍证书申请的背景知识和相关的openssl使用。本文直接开始介绍，使用openssl命令，生成证书请求。为了搞明白证书请求需要包含哪些内容，我们去阅读了证书请求的相关RFC规范。接着，我们阅读openssl命令执行证书请求的源码执行流程。阅读源码的过程中，我们浅尝辄止，没有深入阅读具体的函数实现。所以，我们不知道，在证书申请这块，openssl是否完全遵守了RFC规范。最后，我们使用C++封装了openssl api，实现了一个简单的证书请求类。

---

openssl命令行-生成证书请求

openssl req ：req - PKCS#10 certificate request and certificate generating utility.

openssl-genrsa：genrsa - generate an RSA private key.

我们使用genrsa生成临时RSA密钥。接着，我们使用req生成证书请求。关于命令使用的详细介绍，参见上面两个官方文档链接。

# 生成一个私钥
➜  openssl genrsa -out private_key.pem 2048 # pem格式

# 交互式的构造证书请求
➜  openssl req -key private_key.pem -new -out cert_req.pem

我个人更喜欢使用配置文件生成证书请求。下面内容，保存在ruler.conf中。(简单起见，我注释掉了扩展项部分)

[req]
prompt = no # 如果设置为值 no 这将禁用证书字段的提示，并且直接从配置文件中获取值。
utf8 = yes	
distinguished_name     = req_distinguished_name
# req_extensions         = v3_req


[req_distinguished_name]
organizationName         = galactic alliance
emailAddress             = unknow@haha.gal
commonName               = ruler of earth

# [v3_req]
# basicConstraints = critical, CA:false

接下来，我们使用openssl命令行，生成证书请求。证书请求输出在ruler_csr.pem文件中。

➜  openssl req -key private_key.pem -new -config ruler.conf -out ruler_csr.pem

我们来解析证书请求，看下ruler_csr.pem文件中，有哪些内容。

➜  openssl req -in ruler_csr.pem -text -noout
Certificate Request:
    Data:
        Version: 1 (0x0)
        Subject: O = galactic alliance, emailAddress = unknow@haha.gal, CN = ruler of earth
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:ad:29:30:ec:c7:26:ae:69:89:68:81:d5:76:c6:
                    7e:af:f9:32:b8:d1:03:f1:ed:a6:5f:fa:3a:f2:a6:
                    bf:39:6a:61:e4:6a:cc:1b:12:b5:ea:f9:ef:4f:2f:
                    43:6a:78:c3:62:39:8c:26:b1:ac:1d:6f:66:60:32:
                    8d:4d:53:6f:98:5c:f2:04:2c:2a:78:bf:74:29:7a:
                    5c:99:2a:c1:6f:fe:07:c2:d7:7a:bf:a2:73:22:29:
                    db:45:3e:dc:5d:e8:22:d6:4a:81:7d:fa:d5:be:bd:
                    43:09:e9:0a:63:a9:e7:62:9f:cc:67:a4:39:38:61:
                    ed:f8:b9:79:1c:1c:b0:d9:47:7b:4c:1e:57:17:89:
                    8a:9a:d0:4e:da:e8:47:fe:87:db:6c:1f:34:2e:2f:
                    77:d2:7a:76:ed:c3:be:ef:a2:0a:23:72:9e:44:31:
                    8c:a6:4f:bc:93:48:42:cd:c2:05:db:4e:ab:a3:74:
                    84:9e:3f:73:04:f5:da:de:ab:95:d3:ce:30:a5:1d:
                    4b:3a:90:85:b6:5e:e6:b2:0b:a9:33:91:33:b6:f5:
                    24:e9:f4:3a:ba:33:4d:8f:92:74:15:76:f8:23:ca:
                    f3:c0:0b:71:a3:fc:50:50:49:06:ee:9a:b6:57:4e:
                    dd:ac:ee:f7:cf:9b:0d:52:21:24:38:ab:62:1c:e8:
                    b1:7f
                Exponent: 65537 (0x10001)
        Attributes:
            a0:00
    Signature Algorithm: sha256WithRSAEncryption
         89:29:6e:ee:3a:00:bd:e9:0a:c0:31:c8:3d:96:a5:38:88:18:
         e0:7d:31:84:a2:ea:e0:fa:bd:03:9a:4a:58:9a:28:c8:02:a6:
         50:02:03:d1:25:23:a3:16:14:5b:d4:8d:48:32:95:48:0d:55:
         38:88:f4:d6:bf:f4:1e:e7:c2:7c:e6:4b:df:34:ce:2c:82:58:
         6e:0c:52:8e:d5:d1:d0:cc:06:61:84:9e:d1:19:8b:07:9b:ab:
         75:b8:e9:bc:a4:ca:bd:e1:9d:ab:cf:ad:eb:6d:2b:a0:90:b7:
         0b:33:6f:bc:a2:13:36:d7:1a:d7:e9:7d:f0:1f:63:93:1a:e9:
         c5:d1:5c:f4:1f:7e:ce:e6:c4:95:77:2b:d7:68:c2:f0:53:23:
         e2:10:ae:d4:54:0f:f1:89:a4:7a:dd:78:49:ad:d0:7f:19:de:
         ee:e1:ee:87:f0:91:4b:53:f8:99:2f:d9:20:30:a9:52:95:6e:
         f0:7a:c6:81:1c:e3:04:33:5d:b0:d0:4f:ca:38:82:d5:35:59:
         49:4c:16:9e:ff:65:d7:8c:c3:a7:da:b3:9f:07:8c:6d:b1:a1:
         b9:e1:2f:42:6f:2c:2e:91:cb:c4:3a:61:7b:4c:5d:05:47:e5:
         76:a6:fe:b4:d8:10:b0:11:91:d7:10:6a:39:b7:0c:a4:e3:56:
         06:d4:65:bb

根据缩进，我们可以看到Certificate Request中包含两部分内容：Data和Signature。

Data中包含Subject和public key信息。Signature为摘要之后的签名。

此时，我们怀揣一个疑问：证书请求应该包含哪些内容，它的规范是什么？

下一节，我们来尝试解决这个问题。

---

RFC - 证书请求的消息格式( Certificate Request Message Format)

需要翻阅如下的RFC文档。关于如何查找这些文档，见“附录-RFC文件的查看方法”。

• RFC 2511 [英文 | 中文]
• RFC 4211 [英文 | 中文]
• RFC 9045 [英文]

虽然这三个RFC文档，我都翻了一遍。但我并没有看懂。详见上面链接。

哈哈，但问题不大。最起码知道，证书申请包含三部分内容：证书请求信息、证明证书主体的实体实际拥有相应私钥，证书请求上下文相关的补充信息。

  CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
        
   CertReqMsg ::= SEQUENCE {
      certReq   CertRequest,
      popo       ProofOfPossession  OPTIONAL,
      -- content depends upon key type
      regInfo   SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL
   }

certReq：由请求标识符、证书内容模板和可选的控制信息序列组成。（上一节中的subject和publicKey均为证书模板内容中的一部分）

popo：需要证明请求证书有对应的私钥。（上一节中这一部分是签名值）

regInfo：仅包含与证书请求上下文相关的补充信息。（不知道这啥东西）

那有个问题：openssl的实现是否满足上面规范，或者说，openssl如何实现上面规范。

这个问题跳过。下面虽然阅读了点openssl源码，但具体的函数内部没有去阅读。

---

openssl源码阅读-生成证书请求

调试下面命令对应openssl源码的执行过程。

openssl req -key private_key.pem -new -config ruler.conf -out ruler_csr.pem

# 调试下面命令会失败。因为如果没有指定配置文件，会加载默认配置文件openssl.conf。
# 而我没有源码安装openssl，所以会报错。
openssl req -new -sha256 -key private_key.pem -utf8 -subj /O=galactic alliance/emailAddress=unknow@haha.gal/CN=ruler of earth -out cert_req.pem

• 进入命令行指定的程序req：

  • pname = opt_progname(argv[0]);获取程序名。
  • do_cmd(prog, argc, argv);进入统一跳转函数。
  • fp = lh_FUNCTION_retrieve(prog, &f);、return fp->func(argc, argv);进入req_main函数。

• 循环获取参数：while ((o = opt_next()) != OPT_EOF)

• 根据参数进行处理：

  • pkey = load_key(keyfile, keyform, 0, passin, e, "private key");加载私钥
  • …

• 生成证书申请。

  • req = X509_REQ_new_ex(app_get0_libctx(), app_get0_propq());。创建证书申请空间。
  • make_REQ(req, pkey, fsubj, multirdn, !gen_x509, chtype)。填充证书。pkey为私钥；fsbj为X509_NAME格式，里面为subject信息。
    • X509_REQ_set_version(req, X509_REQ_VERSION_1)设置版本号。
    • X509_REQ_set_subject_name(req, fsubj);设置主题信息。
    • X509_REQ_set_pubkey(req, pkey)设置公钥。
  • PEM_write_bio_X509(out, new_x509);默认为pem格式输出。
  • X509_REQ_free(req);,X509_NAME_free(fsubj);``EVP_PKEY_free(pkey);释放空间。

• 此次调试没有进过parse_name函数。但由于下一节我自己写了一个简化版的这个函数。所以，还是看下这个函数。当调用-subj /type0=value0/type1=value1/type2=...,会触发这个函数 – 使用命令行的信息填充subject。

  • n = X509_NAME_new();开辟X509_NAME格式空间。
  • nid = OBJ_txt2nid(typestr);,X509_NAME_add_entry_by_NID(n, nid, chtype, valstr, strlen((char *)valstr), -1, ismulti ? -1 : 0))添加subject条目。

---

调用openssl api - 生成证书请求

参考自：《Openssl 编程》-- 赵春平 – 第二十五章 证书申请、OpenSSL中文手册 – 蓝月心语 – OpenSSL中文手册之X509库详解（未完待续）

下面为简略代码，删除了调用函数的返回值检查。需要用的时候，自行添加。

#pragma once

#include "exception.hpp"
#include "load_key.hpp"

#include <openssl/x509.h>
#include <openssl/err.h>
#include <boost/utility/string_ref.hpp>
#include <iostream>
#include <sstream>
#include <string>

class req {
private:
    X509_REQ* x509_req = nullptr;
    char ERR[1024] = {0};
    X509_NAME* get_subject(const std::string subject_contents); // 通过字符串subject_contents，生成X509_REQ结构

public:
    req(const std::string digest_name, const std::string private_key_path, 
        const std::string subject_contents);
    
    void out_to_file(int out_format, const std::string out_path); //证书申请输出到文件
    void out_to_stdout(int out_format); //证书申请输出到标准输出

    ~req();
};



req::req(const std::string digest_name, const std::string private_key_path, 
        const std::string subject_contents)
{
    // 填充版本号, 主题名，公钥, 摘要并私钥签名

    x509_req = X509_REQ_new();

    // 0对应版本1；
    // 1对应的是版本2;2对应版本3;
    long version = 0;
    X509_REQ_set_version(x509_req, version);
    X509_NAME* subject_name = get_subject(subject_contents);
   
    EVP_PKEY* pkey = load_private_key(private_key_path, _FORMAT_UNDEF);
    X509_REQ_set_pubkey(x509_req, pkey);

    const EVP_MD* md = EVP_get_digestbyname(digest_name.c_str());
    X509_REQ_sign(x509_req, pkey, md);

    // 释放不需要的资源
    X509_NAME_free(subject_name);
    EVP_PKEY_free(pkey);
}



X509_NAME* req::get_subject(const std::string subject_contents)
{
    // 通过字符串subject，生成X509_REQ结构

    X509_NAME* subject_name = X509_NAME_new();

    std::istringstream ins(subject_contents);
    
    std::string tmp;
    while(std::getline(ins,tmp,'/')) {
        std::string::size_type equal_sin_loc = tmp.find('=');
        if(equal_sin_loc == std::string::npos) {
            BOOST_THROW_EXCEPTION(arg_err()
                <<err_str("cant find = in subject agrs"));
        }

        std::string key = tmp.substr(0, equal_sin_loc);
        std::string value = tmp.substr(equal_sin_loc+1, tmp.length()- equal_sin_loc -1);

        // https://www.openssl.org/docs/manmaster/man3/X509_NAME_add_entry.html
        // For almost all applications loc can be set to -1 and set to 0. 
        if(key == "C") {
            X509_NAME_add_entry_by_txt(subject_name, "countryName", MBSTRING_UTF8, 
                        (const unsigned char*)value.c_str(), value.length(), -1, 0);
        } else if(key == "ST") {
            X509_NAME_add_entry_by_txt(subject_name, "stateOrProvinceName", MBSTRING_UTF8, 
                        (const unsigned char*)value.c_str(), value.length(), -1, 0);
        } else if(key == "L") {
           X509_NAME_add_entry_by_txt(subject_name, "localityName", MBSTRING_UTF8, 
                        (const unsigned char*)value.c_str(), value.length(), -1, 0);
        } else if(key == "O") {
            X509_NAME_add_entry_by_txt(subject_name, "organizationName", MBSTRING_UTF8, 
                        (const unsigned char*)value.c_str(), value.length(), -1, 0);  
        } else if(key == "OU") {
            X509_NAME_add_entry_by_txt(subject_name, "organizationalUnitName", MBSTRING_UTF8, 
                        (const unsigned char*)value.c_str(), value.length(), -1, 0);
        } else if(key == "EMAIL") {
            X509_NAME_add_entry_by_txt(subject_name, "emailAddress", MBSTRING_UTF8, 
                        (const unsigned char*)value.c_str(), value.length(), -1, 0);
        } else if(key == "CN") {
            X509_NAME_add_entry_by_txt(subject_name, "commonName", MBSTRING_UTF8, 
                        (const unsigned char*)value.c_str(), value.length(), -1, 0);
        } else {
            BOOST_THROW_EXCEPTION(arg_err()
                <<err_str("Illegal name appears in parameter. The legal names are follow: C/ST/L/O/OU/EMAIL/CN"));
        }
    }


    return subject_name;
}



void req::out_to_file(int out_format, const std::string out_path)
{
    // 将证书申请，写入文件
    BIO* out = BIO_new_file(out_path.c_str(), "w");
    
    if(out_format == _PEM) {
        PEM_write_bio_X509_REQ(out, x509_req);
    }else if(out_format == _DER) {
        i2d_X509_REQ_bio(out,x509_req);
    }
    BIO_free(out);
}


void req::out_to_stdout(int out_format)
{
    // 将证书申请，写入文件
    BIO* out = BIO_new_fp(stdout, BIO_NOCLOSE);
    if(out_format == _PEM) {
        PEM_write_bio_X509_REQ(out, x509_req);
    }else if(out_format == _DER) {
        i2d_X509_REQ_bio(out,x509_req);
    }
    BIO_free(out);
}

req::~req()
{
    X509_REQ_free(x509_req);
}

---

附录

RFC文件的查看方法

RFC-wiki中有一篇博客链接：[译] 如何阅读 RFC 文档。这篇博客给出了在RFC Editor查找需要的RFC文档。

以本篇博客为例，我想查找证书请求的RFC文档，可以得到如下结果。

RFC 2511 中规定的证书请求消息格式已经被RFC 4211淘汰。RFC 4211 中使用算法，在RFC 9045中有更新。

所以想了解证书的请求规范，需要翻阅：RFC 2511、RFC 4211、RFC 9045。

我不喜欢直接读英文文档，所以我去找翻译。

可以在这四个站点，找到大多数RFC的文档翻译：http://rfc.ac.cn/、https://rfc2cn.com/、https://docs.huihoo.com/rfc/、http://www.cnpaf.net/Class/RFC/

所以本篇博客需要阅读的RFC的链接如下：

• RFC 2511 [英文 | 中文]
• RFC 4211 [英文 | 中文]
• RFC 9045 [英文]

X509C

X.509 协议：V3/V4版证书（建议改进版记作X.509C）

       证书格式

       (1)待签名部分

       1、版本号 V3                                                Version

       2、序列号                                                      Serial Number

       3、签名算法OID*                                          Signature Algorithm Identifier

       4、签发者                                                      Issuer（各项名字的集合）

       5、有效期                                                      Validity

                     生效期                                                NotBefore

                     失效期                                                 NotAfter

       6、申请者                                                      Subject (各项名字的集合）

       7、申请者公钥信息                                        Subject Public Key Info

                     算法*                                                  Algorithm

                     公钥PK                                               Subject Public Key

       8、签发者唯一ID                                    Unique ID of CA

       9、申请者唯一ID                                    Unique ID of Subject

       10、扩展项                                                 Extension

                     标准扩展项

                     自定义扩展项

       (2)签名算法部分

              签名算法OID*                                   Signature Algorithm Identifier

       (3)签名部分

              签名体

几点说明

（1）签名算法OID（一、（1）中带*的地方）

目前主要有：

md2WithRSAEncryption = { 9, "\x2A\x86\x48\x86\xF7\x0D\x01\x01\x02"}；

md5WithRSAEncryption = { 9, "\x2A\x86\x48\x86\xF7\x0D\x01\x01\x04"}；

shaWithRSAEncryption = { 5, "\x2B\x0E\x03\x02\x0F"}；

sha1WithRSAEncryption ={ 9, "\x2A\x86\x48\x86\xF7\x0D\x01\x01\x05"}；

dsaWithSHA ={ 5, "\x2B\x0E\x03\x02\x0D"}；

dsaWithSHA1 ={ 7, "\x2A\x86\x48\xCE\x38\x04\x03"}；

dsaWithSHA1_2 ={ 5, "\x2B\x0E\x03\x02\x1B"}；

申请增加：

schWithRSAEncryption ={ 6, "\x2A\x56\x0B\x05x05\x03 "}; (1,2,86, 11,5,5,3)

schWithECCAEncryption ={ 6,"\x2A\x56\x0B\ x05\x05\x04"}; (1,2,86, 11,5,5,4)

（2）签发者和申请者

              目前主要有：

                     countryName                       //国名（二字节）

                     organizationName                 //组织名

                     organizationalUnitName    //部门名

                     stateOrProvinceName           //省名

                     commanName                      //通用名

                     localityName                       //所在地名

                     email                               //email地址

                     postalAddress                       //通信地址    

                     postalCode                           //邮政编码

                     postalOfficeBox                   //邮箱

                     telephoneNumber                 //电话号码

                     telexNumber                        //传真号码

                     title                                     //职务头衔

                     surName                              //姓0x550404

                     givenName                       //名

                     initials                     //

(3)有效期    

当时间采用UTCTime时，年份采用二字节（YY），当YY大于等于50，年将被认为是19YY；当YY不到50，年将被认为是20YY。而当时间采用GeneralizedTime时，年份采用四字节（YYYY）。

(4)签名体

              D=HashOID+（Hash结果），对D进行DER编码，再采用PKCS1标准进行私钥加密即签名。HashOID目前有：

                     md2 ={ 8, "\x2A\x86\x48\x86\xF7\x0D\x02\x02"}；

                     md5 ={ 8, "\x2A\x86\x48\x86\xF7\x0D\x02\x05"}；

                     sha ={ 5, "\x2B\x0E\x03\x02\x12"}；

       sha1 ={ 5, "\x2B\x0E\x03\x02\x1A"}；

申请增加：sch ={ 5, "\x2A\x56\x0B\ x05\x05"};  (1,2,86, 11,5,5)

（5）在KeyUsage类型中位（Bits）使用如下：

                     定义              比特位                       中文定义

              -------------------------------------------------------           

              digitalSignature        0x8000                     数字签名证书

              nonRepudiation        0x4000                     非抵赖证书

              keyEncipherment     0x2000                     密钥加密证书

              dataEncipherment   0x1000                      数据加密证书

              keyAgreement      0x0800                      密钥交换

              keyCertSign        0x0400                     签发证书

              crlSign            0x0200                      签发CRL文件

              encipherOnly       0x0100                     仅用于加密

       decipherOnly       0x0080                     仅用于解密

（6）标准扩展项

X.509C使用的标准扩展域如下：

权威密钥标识符（AuthorityKeyID）

主体密钥标识符(SubjiectKeyID)

密钥用法(KeyUsage)

私有密钥使用周期(PrivateKeyUsagePeriod)

证书策略(CertificatePolicies)

策略映射(PolicyMappings)

主体可替换名字(SubjectAlternativeName) 个人身份证号码 个人社会保险号 企业工商注册号 企业组织机构代码号 企业税号

发颁发者可替换名字(IssuerAlternativeName)

主体目录属性(SubjectDirectoryAttributes)

基本约束(BasicConstraints)

名字约束(NameConstraints)

策略约束扩大(PolicyConstraints)

扩大密钥使用领域(ExtendedKeyUsage)

CRL发布点(CRLDistributionPoints)

目前主要有：

         权威密钥标识符  

        主题密钥标识符  

 密钥使用 

 私有密钥使用周期

 证书策略 

 策略映射 

 主题可替换名字  

 发行者可替换名字

 主题目录服务系统属性   

 基本约束 

 名字约束 

 策略约束 

 扩大密钥使用领域

 CRL发布点

其中“权威密钥标识符”即AuthorityKeyIdentifier为必选项，且其结构中的可选项keyIdentifier 、authorityCertSerialNumber为必选。

    AuthorityKeyIdentifier ::= SEQUENCE {

      keyIdentifier           [0] KeyIdentifier            OPTIONAL,

      authorityCertIssuer      [1] GeneralNames            OPTIONAL,

      authorityCertSerialNumber[2]CertificateSerialNumber OPTIONAL  }

   KeyIdentifier ::= OCTET STRING，由两种从公开密钥产生密钥标识符的通用方法如下：

A: keyIdentifier由BIT STRING subjectPublicKey的值的160位SHA1哈希值组成（排除标签，长度和不在使用的bits数目）。

B: keyIdentifier 4 bit类型字段值为0100以及随后的由BIT STRING  subjectPublicKey的值SHA 1哈希的值中最后60 bits连接组成。

  

   统一采用A形式。

   

（7）自定义扩展项(扩展扩展项)

    自定义扩展项只要满足以下结构即可

    Extension  ::=  SEQUENCE  {

              extnID      OBJECT IDENTIFIER，       //OID

              critical      BOOLEAN DEFAULT FALSE， //是否是关键项

              extnValue   OCTET STRING              //扩展值

    }

    另外，Netscape证书、SET证书还有LDAP的一些自定义扩展可以直接引

（8）CRL作废链

       为适应安全EMAIL等SSL应用的证书链频繁下载需要，建议链文件在4K之内。把每100或200个证书放在一条链中，在每份证书中指明它所在的链名、URL。

4．3．3．2证书撤消表结构

版本号version

签名算法标识signature

颁发者名称issuer

本次更新（日期/时间）thisUpdate

下次更新（日期/时间）nextUpdate

注销证书链

用户证书序列号 userCertificate

注销日期revocationDate

CRL条目扩展项crlEntryExtentions

……

（CRL链长≤200个证书）

CRL扩展域crlExtentions

签名算法SignatureAlgorithm

签名signatureValue