6.2 證書格式

本標準使用GB/T 16264.8-200X的證書格式。雖然ITU-T建議的X.509的修訂版沒有公布，但版本3的格式已經被廣泛采用，并且ANSI的X9.55和IETF的RFC 2459都對其作了詳細說明。GB/T 16264.8-200X的證書包括以下內容：
·　Version 版本；
·　Serial Number 證書序列號；
·　Issuer Signature Algorithm 頒發者簽名算法；
·　Issuer Distinguished Name 頒發者可辨別名；
·　Validity Period 證書有效時間；
·　Subject Distinguished Name 主體可辨別名；
·　Subject Public Key Information 主體公鑰信息；
·　Issuer Unique Identifier 頒發者唯一標識符(可選，本標準不使用)；
·　Subject Unique Identifier 主體唯一標識符(可選，本標準不使用)；
·　Extensions 證書擴展(可選)；

6.2.1　證書字段

X.509證書語法的ASN.1定義見附錄A。 出于簽名考慮，證書用ASN.1 DER編碼表示。ASN.1 DER是一個為每個元素賦予標簽，長度和值的編碼系統。詳見GB/T 16263.1-200X
以下介紹GB/T 16264.8-200X的證書。除了可選的subjectUniqueID和issuerUniqueID字段，CA應該產生下面這些字段，而且客戶根據GB/T 16264.8-200X標準可以處理它們。CA可以不頒發包括issuerUniqueID和subjectUniqueID的證書。客戶也可以不處理subjectUniqueID和issuerUniqueID。他們可以拒絕那些含有這兩部分字段的證書。
a) Version
version字段表示證書的版本號。該字段的值應為2，以表示版本3證書。
b) Serial Number
serialNumber是CA給每個證書分配的一個整數。對一個給定的CA，它提供的證書序列號應該是唯一的（即，頒發者和證書序列號唯一標識一個證書）。
c) Signature
signature字段包含了一個算法標識符，用于表示簽署證書的算法。此字段包括一個algorithmIdentifier，用于傳遞參數。在5.2.2.3中列出了algorithmIdentifier的內容。證書不應該使用signature字段去傳遞參數（看下面的Subject Public Key Information），因為該字段沒有被頒發者的簽名保護。
d) Issuer Name
issuer 字段提供了簽署證書機構的全球唯一標識符。頒發者的名字是一個X.500標識名。該標識名由屬性類型和屬性值組成。通常屬性類型由X.500系列建議定義，屬性值為DirectoryString 類型。
DirectoryString可選擇PrintableString, TeletexString, BMPString, UniversalString和 Utf8String中的一種。PrintableString是一個基本拉丁字符集，可使用大小寫字母，數字和少量特殊字符。TeletexString是PrintableString的擴展集，在拉丁字符中加入了重音符和日本字符。BMPString 是雙字節字符集，它滿足絕大多數的歐洲字符集。UniversalString是多字節字符集，包括了所有的主要字符集。Utf8String 是 UniversalString 的替代編碼。
當創建新名字時，CA要從PrintableString, BMPString, 和Utf8String里選擇最嚴格的類型來創建DirectoryString。也就是說，僅需基本拉丁字符的AttributeValue一般就使用PrintableString。包含重音符拉丁字符的AttributeValue就使用BMPString。當BMPString字符集不夠用時才使用Utf8String。
仍然保留TeletexString, 和 UniversalString 是為了向后兼容性的需要，不應該在新主體的證書中使用它們。但是，此種類型可能會在已經頒發的證書中使用。Clients 可能會收到使用這些類型的證書。
可選的名字可放在issuerAltName擴展字段，一些GB/T 16264.8-200X證書的使用者希望issuer字段為空。然而，遵從本標準的證書中的這個字段都含有X.500的可辨別名。
e) Validity
validity字段說明了證書開始生效的日期（notBefore）和變成無效的日期(notAfter)。validity字段的時間表示形式用UTCTime或GeneralizedTime。
對于1950年到2049年（含）的日期，validity字段一般使用UTCTTime。UTCTTime使用格林威治時間，而且要精確到秒。秒要清楚表示，即使為零。UCTCTime的格式為YYMMDDHHMMSSZ。
年字段做如下規定：
1） 如果YY等于或大于50，年代為19YY；
2） 如果YY小于50，年代為20YY。
對于2050年以后的日期，validity字段一般用GeneralizedTime。GeneralizedTime使用格林威治時間，而且要精確到秒。秒要清楚表示，即使為零。GeneralizedTime的格式為YYMMDDHHMMSSZ。GeneralizedTime 不能包括分秒。（1950年前的日期對本標準來說無效，所以不予考慮。）
f) Subject Name
subject 字段的目的是給證書主體提供唯一的標識符。主體名使用X.500可辨別名。像在issuer name中描述的一樣，在構建DirectoryString時CA使用最嚴格的選擇。可替代的名字可放在subjectAltName擴展中，GB/T 16264.8-200X證書的使用者希望本字段為空。然而，遵從本標準的證書都在這個字段里帶有主體的X.500可辨別名。
g) Subject Public Key Information
SubjectPublicKeyInfo字段是用來攜帶公鑰和公鑰使用的算法的。它包括subjectPublicKey字段和algorithmIdentifier字段，algorithmIdentifier字段有algorithm and parameters次級字段。
h) Unique Identifiers
證書里的subjectUniqueIdentifier 和 issuerUniqueIdentifier字段是用來處理主體名和頒發者名被過時重用的可能性。CA不會頒發含有這些唯一標識符的證書。PKI客戶也不會被要求去處理含有這些標識符的證書。當然，如果它們不處理這些字段，他們會拒絕包含這些字段的證書。
i) Extesion
extension 字段的增加是GB/T 16264.8-200X證書最主要的改變。擴展有三部分：extnId，標識該擴展，critical，說明該擴展是critical或noncritical的，extnValue，擴展值。一個證書可以包括任意多個擴展字段，其中也包括局部定義的擴展。如果設置了critical標志，就要求客戶或者能夠處理該擴展字段，或者不能驗證該證書。
在GB/T 16264.8-200X中有完整的擴展標準。6.2.3詳述了這些標準擴展在本標準中的使用。
j) Issuer’s Signature

6.2.2　加密算法

6.2.2.1　加密算法概述

本標準使用四類算法：散列函數，數字簽名算法，消息認證算法和對稱加密算法。當描述數字簽名算法時，通常與散列函數一起介紹。當描述證書中的公鑰時，散列函數被忽略。這就允許當散列函數被另一個更強的算法替換時，證書也能使用。
要求一個PKI組件至少應該實現其中一個數字簽名算法。對于簡單的PKI客戶組件來說，能驗證由其中一個算法生成的簽名已經足夠了；要求其它的組件能夠產生和驗證由其中一個算法生成的簽名。遵守本標準的PKI組件應該支持一個加密算法。

6.2.2.2　散列函數

散列函數用于為證書和CRL產生數字簽名，它也用于將共享秘密散列為報文確認碼。
本標準中建議使用一種散列函數。以SHA-1為例，它是通過對象標識符以及數字簽名算法表示的。SHA-1的ASN.1對象標識符是：
sha1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 }

6.2.2.3　數字簽名算法

GB/T 16264.8-200X中指定了發放證書的簽名算法，和其它主體的加密算法。這兩種算法可以是不同的。本標準以RFC 2313中的RSA算法為例。
RSA的簽名算法在RFC 2313中定義。RSA也可使用幾種散列算法。本標準中引用的RSA定義為：
pkcs-1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) US(840)
rsadsi(113549) pkcs(1) 1 }
sha-1WithRSAEncryption OBJECT IDENTIFIER ::= { pkcs-1(1) 5 }
在RSA簽署的證書和證書撤銷列表中，它應出現在SIGNED類型中和signature字段中。只要實體的標識符作為算法標識符出現，那么參數的值必須是NULL。
當證書和證書撤銷列表簽署時，簽名將按下列規則生成和加密：證書和證書撤銷列表按ASN.1 DER加密，并作為SHA-1的散列函數的輸入。SHA-1散列函數的輸出為OCTET STRING并按照RSA的加密算法加密。簽署證書時，RSA生成一個整數y。y的值按照ASN.1的BIT STRING輸出。在y的signature字段包含了證書或證書撤銷列表。（通常分為兩步，整數y先轉化為octet string。然后再轉化為bit string。）
當CA發放了一個證書，并且它的subjectPublicKeyInfo字段包含了RSA的公鑰，那么對象標識符rsaEncryption將作為algorithmIdentifier出現在subjectPublickeyInfo字段中，來標識RSA的公鑰。
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1}
只要rsaEncryption對象標識符在算法類型中出現，那么參數字段必為NULL。
RSA的公鑰必須為ASN.1的RSAPublicKey:的類型。
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, – n
publicExponent INTEGER – e}
系數為n，publicExponent為公共指數e，RSAPublicKey編碼后為BIT STRING subjectPublicKey的值。

6.2.2.4　消息認證算法

本標準建議支持兩種消息認證算法。以DES-MAC和SHA1-MAC為例，推薦使用SHA1-MAC，DES-MAC是為了保證向后的兼容性。
SHA1-MAC
本算法通過為數據計算一個SHA-1 HMAC值（在RFC2104中詳細定義）而提供完整性保護。它的算法標識符如下：
SHA1-HMAC OBJECT IDENTIFIER ::= { 1 3 6 1 5 5 8 12 }
本標準中使用的mac長度為96bit。
DES-MAC
本算法通過為數據計算一個DES MAC值（在FIPS-113中詳細定義）而提供完整性保護。它的算法標識符如下：
DES-MAC OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 10
– MAC的長度是一個整數型的參數，在本標準中限制為32 }

6.2.2.5　對稱加密算法

本標準使用了對稱密鑰算法來實現挑戰－響應協議和保護私鑰傳輸。在本標準中，以使用tDEA（Triple Data Encryption Algorithm）算法的ECB模式為例說明對稱密鑰算法的使用。
tDEA算法在ANSI X9.52中定義。tDEA算法基于DES算法，使用3個56 bit的密鑰：K1、K2和K3。在本標準中，使用雙密鑰模式，K1=K3。tDEA算法的密鑰絕對不能出現在GB/T 16264.8-200X證書中。有的情況下，會在PKIMessage中傳輸tDEA的密鑰，這時候，tDEA的密鑰必須是經過加密的。
下文說明了tDEA的雙密鑰、ECB模式的加密方法和密鑰的編碼格式。
tDEA算法有AlgorithmIdentifier，而且要有tECB的OID。雙密鑰選項在ECBParams結構中指明。
ASN.1表示如下：
TDEAIdentifier ::= AlgorithmIdentifier {{ TDEAModes }}
TDEAModes ALGORITHM-ID ::= {
{ OID tECB PARMS ECBParms } | – mode 1 –
{ OID tCBC PARMS TDEAParms } | – mode 2 –
{ OID tCBC-I PARMS TDEAParms } | – mode 3 –
{ OID tCFB PARMS CFBParms } | – mode 4 –
{ OID tCFB-P PARMS CFBParms } | – mode 5 –
{ OID tOFB PARMS TDEAParms } | – mode 6 –
{ OID tOFB-I PARMS TDEAParms }, – mode 7 –
…
}
ECBParms ::= TDEAParms (WITH COMPONENTS {
…, ivGeneration ABSENT })
TDEAParms ::= SEQUENCE {
keyingOptions KeyingOptions OPTIONAL,
ivGeneration [0] IVGeneration OPTIONAL
}
– 本標準中只支持雙密鑰
KeyingOptions ::= BIT STRING {
option-1 (0), – (3-key) K1, K2 and K3 are independent keys
option-2 (1), – (2-key) K1 and K2 are independent and K3 = K1
option-3 (2) – (1-key) K1 = K2 = K3
}
id-ansi-x952 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-x952(10047) }
Second CRADA Draft, Version 2
mode OBJECT IDENTIFIER ::= { id-ansi-x952 1 }
tECB OBJECT IDENTIFIER ::= { mode 1 }

6.2.3　證書擴展

6.2.3.1　證書擴展概述

在GB/T 16264.8-200X中定義了一套標準擴展集合。擴展由三部分組成：擴展名稱、關鍵性標識位和擴展取值。在GB/T 16264.8-200X中做了如下規定：客戶如果不能處理設置了關鍵性標識位的擴展，就不能驗證證書是否有效。

6.2.3.2　密鑰和策略信息

此類擴展用于區分特定的公鑰和證書，它們可以用于區別具有多個證書的證書認證機構(CA) 中某一特定的公鑰/證書，有助于客戶查找某個特定的CA證書，以便建立驗證路徑。這些擴展可以限制密鑰用途，提供CA證書中關于策略映射的信息。
a) 權威密鑰標識符
擴展authorityKeyIdentifier提供了一種區別簽名證書的特定私鑰的手段，標識性信息既可以基于密鑰標識符，也可以基于頒布者名字和序列號。在本標準中，使用密鑰標識符的方法。本擴展用于具有多個簽名密鑰的頒發者（既可能是多個密鑰對，也可能是正在進行密鑰更換），證書認證機構(CA)應當能夠產生本擴展，而且客戶應能查找和驗證具有多個數字簽名密鑰的證書頒發者CA的驗證路徑。建議客戶既能夠處理密鑰標識符，又能夠處理由證書頒發者和證書序列號組成的密鑰標識符，便于找到驗證路徑。
b) 主體密鑰標識符
本字段用于區別一個主體所擁有的多個密鑰，在每個已頒發的證書中都應當包含本字段，本擴展應當是非關鍵的。
c) 密鑰用途
擴展keyUsage定義了證書中密鑰在使用上的限制，這種限制是基于策略和/或用途的（如簽名，加密）。CA應當能產生該擴展，而客戶應當能處理該擴展。如果keyUasge定義為BIT STRING，所有遵從本標準的CA都應當在終端實體證書中設置一個值，例如，一個終端實體證書中的KeyUsage不應當既是digitalSignature又是dataEncipherment，本擴展應當設置為關鍵性的擴展。
d) 私鑰使用期限
擴展privateKeyUsagePeriod僅適用于數字簽名密鑰。在私鑰使用期限之外的簽名是無效的，CA可以產生此擴展，但客戶不要求處理此擴展。
e) 擴展的密鑰使用范圍
擴展extendedKeyUsage用于定義在應用中對證書密鑰的使用限制，如果使用此擴展，就不考慮互操作的因素。符合本標準的PKI組件不要求支持該擴展。
f) 證書策略
擴展certificatePolicies包括一個或多個對象標識符（OIDs），每個OID代表頒發本證書的一個策略。CA應當能夠產生帶有一個或多個證書策略OID的證書，CA應當支持一個特殊策略OID，即任意策略anyPolicy。anyPolicy的OID可以認為是一個通用符，能夠匹配任何策略。客戶應當能夠處理policyIdentifier字段，并與可接受的策略列表（策略列表取決于相應的應用程序）中的標識進行比較。如果提供了一個可接受策略列表，并且至少要有一個列表中的策略或其映射策略存在于certificatePolicy中時，客戶才能驗證證書認證路徑。如果在證書策略中存在特定策略標識符anyPolicy，并且沒有禁止任何策略（見6.2.3.4），就可以認為列表中的所有策略都可以接受。
要求符合本標準的組件能處理certificatePolicy的子域policyQualifiers，并且支持id-pkix-cps 和id-pkix-unotice（見RFC2459）。符合本標準的CA不要求能產生該子域。
g) 策略映射

6.2.3.3　證書主體和頒發者特征

擴展subjectAltName，issuerAltName, subjectDirectoryAttributes和authorityInformationAccess都是非關鍵性的。它們提供了關于主體和頒發者的其它名稱和特征的附加信息。
a) 別名
subjetAltName和issuerAltName擴展提供了證書主體和證書頒發者的附加信息，這些附加信息包括RFC822名稱（電子郵件地址）、DNS名稱和統一資源標識符（URI）。擴展中可以包括多個名稱。如果需要在證書中提供這些信息，就應當使用擴展subjectAltName和issuerAltName。
根據本標準，擴展subjectAltName和issuerAltName應當是非關鍵的。識別這些擴展的應用沒有必要能支持所有可能的選擇。如果應用不能識別證書中的別名，就可以忽略該擴展。
在本標準中，擴展issuerAltName中包括URI信息，URI明確了頒發者證書的位置，這可以用來驗證數字證書中的簽名。在本標準中沒有規定subjectAltName中包含的信息的意義。
如果證書認證機構(CA)的證書不能從X.500目錄服務中得到，CA就應當在證書中的別名擴展中包含相應的URI信息，以指出簽名者證書的位置。要求客戶能處理URI別名格式，必須能夠識別LDAP URL[RFC1959]。不要求客戶能識別其它URI格式。
b) 主體目錄屬性
擴展subjectDirectoryAttributes可以包含任何關于主體的X.500目錄屬性信息。本擴展是非關鍵性的。本擴展的實現和使用是可選的。
c) 權威機構信息存取

6.2.3.4　驗證路徑限制

擴展basicConstraints, nameConstraints和policyConstraints用于限制有效的驗證路徑。
a) 基本約束
擴展basicConstraints通過CA部分的信息指定證書的實體是否是CA，通過pathLenConstraint部分的信息指定驗證路徑的長度。CA應當在證書中能產生擴展basicConstraints，客戶也應能夠處理本擴展。只有在CA為Ture的時候，pathLenConstraint才有意義。
在所有CA證書中都應當包括basicConstraints擴展，而且CA應當設置為True。在終端實體的證書中也可以包括擴展basicConstraints。如果在終端實體的證書中出現擴展basicConstraints，它應當是一個空的序列值。在所有CA證書中的擴展basicConstraints應當設置成關鍵性的。
b) 名字約束
擴展nameConstraints只能用在CA證書中，它指定證書的驗證路徑中所有后續證書的名字范圍。CA應當在證書中能產生擴展nameConstraints，客戶也應能夠處理該擴展。該擴展應設置為關鍵性的。
c) 策略約束
擴展policyConstraints只用于CA證書。它可以以兩種方式對策略解釋進行限制：既可以限制策略映射，又可以要求在驗證路徑中的每個證書包括一個可接受的策略標識符。
本擴展包括兩個字段：inhibitPolicyMapping和requireExplicitpolicy。如果inhibitPolicyMapping存在，它的值代表驗證路徑中的策略映射不再有效之前的其它證書的個數。如果requireExplicitPolicy存在，在后續的證書中應當明確包含可接受的策略標識符。RequireExplicitpolicy的值代表在驗證路徑中要求明確的策略前的其它證書的個數。
CA應當在頒發證書中包括本擴展，客戶應能夠處理本擴展。該擴展應設置為關鍵性的。
d) 禁止anyPolicy

6.2.3.5　CRL標識擴展

本類擴展包含如何獲得證書撤銷列表（CRL）的信息。通過標識CRL和頒發CRL者的名稱（頒發者可能不是產生證書的CA）的方式，可以將大的CRL列表劃分為多個小CRL列表。
CRL分發點：
CRLDistributionPoints擴展標識CRL分發點，或指導客戶如何驗證一個已撤銷的證書。本擴展由三部分字段組成：distributionPoint，reasons和cRLIssuer。
a)DistributionPoint存放如何獲得CRL的位置信息。如果本字段缺省，CRL分發點的名字就是頒發者名字。在CA頒發的CRL很大的情況下，此字段提供了一種將CRL劃分為多個可管理片斷的機制。
b)Reasons存放相應的distributionPoint分發的CRL撤銷的原因。如果reasons不出現，在distributePoints分發的CRL中可以包括由于任何原因而撤銷的證書。不要求客戶能處理reasons。
c)CRLIssuer確定分發并簽名CRL的權威機構。如果該字段不出現，CRL頒發者與證書頒發者相同。使用本字段可以建立統一的CRL，包括由多個CA頒發的證書。
CAs應當能夠產生帶有distributePoint部分的cRLDistributionPoints 擴展。如果不能從公共的X.500目錄服務中獲得CRL列表，CA應當在distributionPoint中用URI別名格式來標注相應CRL列表的位置。要求客戶能夠處理cRLDistributionPoint擴展。必須能夠識別URI格式，至少能夠處理LDAP URI格式。如果使用了cRLIssuer，要求客戶能夠使用分發點并驗證CRL。在6.3.3中對分發點做進一步的討論。