6.5 事務消息格式

6.5.1　事務消息格式概述

本條給出了一套最小的支持PKI事務的消息格式。系統如果想實現這些事務就必須支持這些消息格式，并能夠正確的產生、識別它們。這些消息格式以ASN.1的形式定義；消息利用DER編碼傳輸。

6.5.2　全體PKI消息組件

a) PKI 消息
每個消息有四個組件：
PKIMessage ::= SEQUENCE {
header PKIHeader,
body PKIBody,
protection [0] PKIProtection OPTIONAL,
extraCerts [1] SEQUENCE OF Certificate OPTIONAL }
extraCerts 字段在本標準中用來放簽名的證書序列，后面消息的描述中對這個字段不再具體描述。
b) PKI 消息頭
所有的PKI消息都需要頭信息來識別地址和處理。一些頭信息會在傳輸特定包里給出。然而，如果PKI 消息被簽名，這個頭信息也是被保護的。
下面是消息頭的數據結構：
PKIHeader ::= SEQUENCE {
pvno INTEGER { ietf-version2 (1) },
sender GeneralName, – 標識發送者
recipient GeneralName, – 標識接收者
messageTime [0] GeneralizedTime OPTIONAL,
– 該消息的產生時間（發送者使用）
– 該時間對接收者來說仍然有意義。
protectionAlg [1] AlgorithmIdentifier OPTIONAL,
– 計算保護比特的算法
senderKID [2] KeyIdentifier OPTIONAL,
recipKID [3] KeyIdentifier OPTIONAL,
– 確定用來保護的特定密鑰
transactionID [4] OCTET STRING OPTIONAL,
– 確定事務, 也就是說,相應的請求、響應和確認消息的transactionID相同。
senderNonce [5] OCTET STRING OPTIONAL,
recipNonce [6] OCTET STRING OPTIONAL,
– nonces 用來提供重發保護，消息的產生者插入senderNonce；該消息的接收者在相
– 應消息中插入recipNonce。
freeText [7] PKIFreeText OPTIONAL,
– 這可以用來進行一些上下文說明（本字段的設計便于人工閱讀）
generalInfo [8] SEQUENCE SIZE (1..MAX) OF InfoTypeAndValue OPTIONAL
– 用來傳遞上下文相關信息
– (本字段不是主要為人工考慮的)}
PKIFreeText ::= UTF8String
頭消息中的transactionID字段允許響應消息的接收者將它與請求相關聯。一個RA或許在同一個時刻有很多請求未被處理。為了做到有效，從發送者的角度看，本字段的取值應當是獨一無二的。
MessageTime 字段表明消息產生的時間。它的值必須是格林威治時間，必須精確到秒（即年月日時分秒YYYYMMDDHHMMSSZ），即使秒是零。MessageTime 字段不包括分秒。
sender和recipient字段定義為GeneralName。系統必須支持X.500 標識名和RFC 822(Internet e-mail)標識名。
freetext 字段定義為PKIFree Text, PKIFree Text 是ASN.1中的UTF8String 型。UTF8String 是統一字符集，它包括了ASCII，本標準中， PKIFree Text 僅包括ASCII中的字符。
ProtectionAlg 所有的簽名消息，以及用消息認證碼保護的消息都要有該字段。當一個消息不受保護時（即，在含有PKIHeader 的PKIMessage 中不出現 protection 字段時），ProtectionAlg 必須被忽略。
senderNonce 和 recipNonce 在 client 和 RA 中是不需要的；CA如果收到了帶有senderNonce的PKIMessage， 就必須在隨后的消息里返回recipNonce。本標準中，senderKID, recipKID, generalInfo 是不需要的。
c) PKI消息正文
PKIBody ::= CHOICE {
– message-specific body elements
cr [2] CertReqMessages, –證書請求
cp [3] CertRepMessage, –證書響應
p10cr [4] PKCS10CertReqMessages, –引自[PKCS10]
rr [11] RevReqContent, –撤銷請求
rp [12] RevRepContent, –撤銷響應
conf [19] PKIConfirmContent, –確認}
其它的 message-specific 正文元素在RFC2510、RFC2511中定義。本標準并不需要這些元素，所以這里把它們省略了。附錄C中描述了message-specific正文元素的完整列表。
其它部分所說的CertReq、CertRep、RevReq、RevRep在PKIMessage里就是指ir、ip、cr、cp、rr、rp。一個PKCS#10請求是指帶有p10cr 正文元素的消息。一個確認消息帶有正文消息conf。
d) PKI消息保護
使用以下結構，所有PKI消息的完整性將得到保護：
PKIProtection::=BIT STRING
用來計算PKIProtection的輸入是如下數據結構的DER編碼：
ProtectedPart::=SEQUENCE{
Header PKIHeader,
body PKIBody}
在大多數情況下，PKIProtection字段將包含一個數字簽名，PKIHeader里的protectionAlg字段將包含一個AlgorithmIdentifier, 用來說明為保護消息所使用的數字簽名算法。

6.5.3　通用數據結構

下面的數據類型對幾個消息格式都是通用的。
a) 證書模板
在各種各樣的PKI管理消息中，始發者可能會提供一些值來識別一個已存在的證書，或申請一個證書時在請求中含有一些值。CertTemplate結構允許實體標明這些值。CertTemplate包含作為一個證書所需的所有信息。
CertTemplate ::= SEQUENCE {
version [0] Version OPTIONAL,
用來請求特殊語法版本
serial [1] INTEGER OPTIONAL,
用來請求一個特殊的序列號或聲明請求代表一個以前的證書持有者
signingAlg [2] AlgorithmIdentifier OPTIONAL,
subject [3] Name OPTIONAL,
validity [4] OptionalValidity OPTIONAL,
issuer [5] Name OPTIONAL,
publicKey [6] SubjectPublicKeyInfo OPTIONAL,
issuerUID [7] UniqueIdentifier OPTIONAL, – not supported
subjectUID [8] UniqueIdentifier OPTIONAL, – not supported
extensions [9] Extensions OPTIONAL,
包含請求者希望在證書里具有的擴展
}
OptionalValidity ::= SEQUENCE {
notBefore [0] Time OPTIONAL,
notAfter [1] Time OPTIONAL
}
CertTemplates ::= SEQUENCE OF CertTemplate
如果CertTemplate出現，validity字段將包含請求證書的請求發放日期（notbefore字段）和期滿日期（notAfter）。對CertTemplate 中的 validity字段和證書中的 validity 字段的解釋相同。（見5.2.1）
b) 簽名私鑰的擁有證明
若由主體產生密鑰對，CA需要驗證證書請求中主體擁有對應于相應公鑰的私鑰。這是通過ProofOfPossession字段來實現的。
當用戶申請一個簽名證書，則用ProofOfPossession中的signature字段實現的，該signature是一個POPOSigningKey 結構。該結構包含輸入數據、一個算法標識符和一個簽名。
輸入數據作為DER編碼的popInput，它是由證書請求中的數據生成的。通常，它包含CertTemplate里的主體名和公鑰。當一個新的主體請求通過公鑰mac驗證后，或是RA修改了主體名后，popInput必須由POPOSigningKey結構中的可選數據和CertTemplate里的公鑰構成。這就允許RA把擁有證明傳遞給CA而不用改變CertTemplate。
ProofOfPossession ::= CHOICE {
raVerified [0] NULL,
– 當RA已經驗證了請求者擁有相應私鑰時使用
signature [1] POPOSigningKey,
– 用戶產生證書密鑰對，并申請簽名證書時使用
keyEncipherment [2] POPOPrivKey,
– 本標準不使用該域
keyAgreement [3] POPOPrivKey
– 本標準不使用該域}
POPOSigningKey ::= SEQUENCE {
poposkInput [0] POPOSKInput OPTIONAL,
algorithmIdentifier AlgorithmIdentifier,
signature BIT STRING }
– 對popInput的DER編碼值簽名（用”algorithmIdentifier”）
– 注意: 如果在pop字段里出現poposkInput， popInput 就由otherinput構成。
– 如果 poposkInput 沒有出現, 主體就是CertTemplate中的名字。
– 注意PopInput的編碼值是有意含糊的。
PoposkInput ::= CHOICE {
Subject name,
Sender [0] generalName,
publicKeyMAC [1] PKMACValue}
– pop的計算是基于popInput的結構的。 PopInput的結構定義如下：
PopInput ::= SEQUENCE {
CHOICE {
otherinput popskInput,
subject name },
publicKey subjectpublicKey}
– 如果poposkInput在pop字段出現的話，popInput 就用otherinpu構成。 如果 poposkInput 不出現，主體就是CertTemplate中的名字。
– 注意PopInput的編碼值是有意含糊的。
c) 證書請求消息
CertReqMsg 是證書請求的基本結構。CertReqMsg 由三個字段構成的SEQUENCE , certReq; pop; regInfo（可選）。 certReq是類型CertRequest, pop 包括了證明擁有私鑰的信息，regInfo包含了特定的注冊過程信息。 regInfo字段是可選的。CertReqMsg定義見附錄D。
CertReqMsg ::= SEQUENCE {
certReq CertRequest,
pop ProofOfPossession OPTIONAL,
– 本標準規定加密密鑰對必須集中產生，此時該字段不出現
– 若集中產生簽名密鑰對，則該字段不出現
– 若是由終端實體產生簽名密鑰對，則該字段必須出現
regInfo SEQUENCE SIZE(1..MAX) of AttributeTypeAndValue OPTIONAL }
CertRequest
CertRequest 的組成包括：請求標識符，證書模板, 可選的控制信息。
CertRequest ::= SEQUENCE {
certReqId INTEGER, – 用來匹配請求和相應的ID
certTemplate CertTemplate, – 選定的證書中的某些字段
controls Controls OPTIONAL } – 控制頒發的一些屬性
certReqId 是一個 INTEGER, certTemplate 是 CertTemplate ，controls 的定義如下。
CertReqMessages
CertReqMessages 是一個或多個CertReqMessage 序列的結構。
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMessage
本標準中，CertReqMessages 可以假設為僅由一個CertReqMessage構成的SEQUENCE。即 MAX 可以定義為1。
Controls
CertRequest 的產生者可以包括一個或多個適合請求處理的control值。
Controls ::= SEQUENCE SIZE (1..MAX) OF AttributeTypeAndValue
下列control 在證書管理協議(CMP)里有定義: regToken； authenticator； pkiPublicationInfo； pkiArchiveOptions； oldCertId； protocolEncrKey。在具體實現規范中的事務時，這些control是可選的。 這些 control 的OIDs 如下。 本標準不需要的control （oldCertId, regToken, authenticator, pkiPublicationInfo, and pkiArchiveOptions）在這里沒有描述。
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
– arc for Internet X.509 PKI protocols and their components
id-pkip OBJECT IDENTIFIER :: { id-pkix pkip(5) }
– Registration Controls in CRMF
id-regCtrl OBJECT IDENTIFIER ::= { id-pkip regCtrl(1) }
id-regCtrl-oldCertId OBJECT IDENTIFIER ::= { id-regCtrl 5 }
id-regCtrl-protocolEncrKey OBJECT IDENTIFIER ::= { id-regCtrl 6 }
d) 協議加密密鑰控制
如果存在的話，協議加密密鑰控制明確了CA用來對CertReqMessages的響應進行加密的密鑰。
當CA發送給申請者的信息需要加密的時候就可以使用這一控制。 這些信息包括CA把產生的私鑰發給申請者供其使用。
protocolEncrKey 控制由屬性類型里的id-reg-protocolEncrKey 的OID來確定。它的值的語法是 SubjectPublicKeyInfo.
e) PKI消息狀態碼
所有的響應消息都包含一些狀態信息。定義如下的取值：
PKIStatus ::= INTEGER {
granted (0),
請求得到許可，沒有變更
grantedWithMods (1),
請求得到許可，有變更; 請求者負責確定變更。
rejection (2),
請求被拒絕
waiting (3),
已收到請求但還未處理，處理后將會附加一個響應
revocationWarning (4),
給予警告：撤銷已被請求，正在處理。
revocationNotification (5),
–通知：已經撤銷
keyUpdateWarning (6) }
本標準并未用到KeyUpdateWarning狀態碼。
f) 失敗信息
響應者使用以下句法提供更多失敗信息。
PKIFailureInfo ::= BIT STRING { 因為會以多種方式失敗!
badAlg (0), – 不被識別或不被支持算法名
badMessageCheck (1), – 完整性檢查失敗(例如, 簽名核對錯誤)
badRequest (2), – 事務不被允許或支持
badTime (3), – messageTime與系統時間相差太多
badCertId (4), – 證書標識名錯
badDataFormat (5), – 數據格式不對
wrongAuthority (6), – 請求中指出的 authority 和響應者不同
incorrectData (7), – 請求者的數據不對 (在公證服務里用)
missingTimeStamp (8), – 沒有時戳，但是策略需要
badPoP (9) – 擁有證明字段核實失敗,
– 需要更多的失敗信息}
PKIStatusInfo ::= SEQUENCE {
status PKIStatus,
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL}
g) 確認協議
確認消息會在PKIHeader中帶著所需的所有信息。因此，該數據結構內容為空。
PKIConfirmCotent::=NULL
h) 證書識別
為了識別特定的證書，采用了CerId結構
CerId::=SEQUENCE{
issuer GeneralName,
serialNumber INTEGER}
i) Centrally Generated Keys
本標準規定由第三方集中產生加密密鑰對并通過帶外方式提供給CA， 此時CA用CertifiedKeyPair結構發還證書。
CertifiedKeyPair ::= SEQUENCE {
certificate [0] Certificate OPTIONAL,
encryptedCert [1] EncryptedValue OPTIONAL,
privateKey [2] EncryptedValue OPTIONAL,
publicationInfo [3] PKIPublicationInfo OPTIONAL }
EncryptedValue ::= SEQUENCE {
intendedAlg [0] AlgorithmIdentifier OPTIONAL,
– the intended algorithm for which the value will be used
symmAlg [1] AlgorithmIdentifier OPTIONAL,
– 加密這一value的對稱算法
encSymmKey [2] BIT STRING OPTIONAL,
– 用來加密這一value的對稱密鑰（已加密）
keyAlg [3] AlgorithmIdentifier OPTIONAL,
– 用來加密對稱密鑰的算法
valueHint [4] OCTET STRING OPTIONAL,
– encValue 內容的簡要描述或標識符
– (可能只對發送實體有意義，僅當將來發送實體對EncryptedValue重新檢查時使用)
encValue BIT STRING
– 加密的 value}
j) 帶外信息
為了在帶外傳輸一個CA的公鑰，采用了OOBCert結構。OOBCert只是一個CA的證書。
OOBCert::=Certificate
6.5.4　特殊操作的數據結構
a) 注冊/證書請求
注冊和證書請求消息（cr）包含一個CertReqMessages 的數據結構，該結構規范了請求證書的特定取值。
CertReqMessages 是CertReqMsg結構的一個或多個序列。
CertReqMessages ::= SEQUENCE SIZE (1..MAX) OF CertReqMsg
例外的，本標準里定義的事務假設CertReqMessages僅是一個CertReqMsg的SEQUENCE。同時請簽名證書和加密證書的可選事務請求要求CertReqMessages 是大小為2的SEQUENCE。本標準不鼓勵同時申請兩個證書，但不禁止。
b) 注冊/證書響應
注冊響應消息(cp)包含一個CerRepMessage結構（一個可選的公鑰和一個response）。特別的，本標準里定義的事務都假設響應僅是一個CertResponse的序列。一個例外就是含有簽名證書和加密證書請求的事務；該事務的響應可以是響應消息的結合，即含有兩個CertResponse的字段的序列。
CertResponse包含一個請求id、狀態信息和一個CertifiedKeyPair(可選)。CertifiedKeyPair是一個包含四個可選字段的序列，四個可選字段分別是：一個證書，一個已加密證書、一個已加密私鑰，以及公開信息。本標準中，證書字段總出現在CertifiedKeyPair里。僅當集中產生密鑰管理密鑰時才用到PrivateKey，其余字段均不出現。
CertRepMessage ::= SEQUENCE {
caPub [1] Certificate OPTIONAL,
response SEQUENCE OF CertResponse}
CertResponse ::= SEQUENCE {
certReqId INTEGER, –與相應的請求相匹配
certRepStatus PKIStatusInfo,
certifiedKeyPair CertifiedKeyPair OPTIONAL；
－只有當狀態為granted或grantedWithMods才存在
rspInfo OCTET STRING OPTIONAL
– analogous to the id-regInfo-asciiPairs OCTET STRING defined
– for regInfo in CertReqMsg [CRMF]}
如果certRepStatus包含failInfo字段，CertResponse將不包含certifiedKeyPair 并且certRepStatus字段的status 的值將是rejection. status 的值是 waiting 時，可選字段就都不出現。status 的值 revocationWarning 和 revocatonNotification不會在消息中出現。
caPub 和 rspInfo 字段是不需要的，如果它們出現的話可以被忽略。本標準并不使用CertifiedKeyPair中的encryptedCert 和 publicationInfo 字段。
c) 撤銷請求的內容
當請求撤銷一個證書時采用以下數據結構。請求者的名字在PKIHeader中顯示。
RevReqContent ::= SEQUENCE OF RevDetails
RevDetails ::= SEQUENCE OF {
certDetails CertTemplate,
允許請求者盡可能多的指定所請求撤銷的證書的參數(例如，不知道序列號時)
revocationReason ReasonFlags,
來自DAM, 這樣CA 就知道該用哪個Dist. point
badSinceDate GeneralizedTime OPTIONAL,
– indicates best knowledge of sender
crlEntryDetails Extensions
要求的 crlEntryExtensions}
ReasonFlags定義見附錄B。 為清楚起見這里再說明一遍。
ReasonFlags ::= BIT STRING {
unused (0),
keyCompromise (1),
caCompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
removeFromCRL (8) }
badSinceDate 和 revocationReason 表示的信息可以在 crlEntryDetails 中也同樣表示出來，使用標準的X.509 CRL 擴展 invalidityDate 和 reasonCode。推薦的位置是crlEntryDetails，不過本標準建議CA處理其它位置的信息。當有沖突存在的時候，使用較早的日期。當撤銷原因不匹配時，CA應包括所有的原因。
d) 撤銷響應內容
當對撤銷請求做響應時，使用以下數據結構。把它發送給請求者。
RevRepContent ::= SEQUENCE {
status PKIStatusInfo,
revCerts [0] SEQUENCE OF CertId OPTIONAL,
確定要請求撤銷的證書
crls [1] SEQUENCE OF CertificateList OPTIONAL，
作為結果的相應的RL}
在本標準中，revCerts 是一個或多個 CertID 字段的SEQUENCE，crls字段并不出現。
e) PKCS#10 證書請求
這個證書請求句法在RFC 2314中有定義，為清楚起見在此重復一遍。
PKCS10CertReqContent ::= SEQUENCE {
certificationRequestInfo CertificationRequestInfo
signatureAlgorithm SignatureAlgorithmIdentifier,
signature Signature}
SignatureAlgorithmIdentifier ::= AlgorithmIdentifier
Signature ::= BIT STRING
CertificationRequestInfo::= SEQUENCE {
version Version,
subject Name,
subjectPublicKeyInfo SubjectPublicKeyInfo,
attributes [0] IMPLICIT Attributes}
Version ::= INTEGER
Attributes ::= SET OF Attribute
Attributes 在RFC 2985中有定義。為了互操作而對Attributes 的支持是可選的。 即使出現了，也可以被忽略。