rfc3029.txt

本程序为在linux下实现FTP传输文件的实现

本节说明把第8节中描述的通过Internet邮件来交换的协议转换成ASN.1编码消息的
一种方法。
 DER编码的DVCS请求和响应使用一个简单的具有适当Content-Transfer-Encoding 的
Content-Type应用/dvcs的MIME对象封装。
这个MIME对象可使用MIME处理引擎来接收和发送，并且为DVCS消息提供简单的
Internet 邮件传输。
为了把可能的错误响应和请求关联起来，请求者应使用'transactionIdentifier'字段。
请求者不应使用响应服务来假设消息头字段的使用，尤其是在使用象Subject, 
Message-ID或References等字段时。
11.  需要考虑的安全问题
这一章讨论安全问题。当设计数据有效性和证书服务时，已经考虑了以下这些影响数据
有效性证书的有效性或“可信度”的事项。
采取适当的安全和控制措施来保护用于签名DVCs的密钥，这是强制性的，以便将可能
的损害减少到最低程度。然而，如果私钥被损坏，则对DVCS产生的所有DVC都应进行审计
追踪，这是帮助区分真和假DVCs的一种方法。DVCS可以为vsd服务提供对由这个或另一个
单独地基于审核验证DCVS产生的DVCs进行地确认。
当要求机密性和服务器验证时，请求和响应可用适当地机制进行保护（例如RFC2630CMS
封装或RFC2246TLS）.
对于vsd和cpd服务来说，我们强烈推荐服务器验证。
客户端标识和验证可使用RFC2246TLS定义地服务，而不是使用CMS格式提供验证。
12.  专利信息
以下是作者所知现存的按年代排列的和数据有效性和证书服务有关的美国专利。这个列
表并不完备，随时都将补充存在的其它的专利。
使用此协议的DVCS协议和应用的实现应进行它们各自的专利查询和决定在实现过程中
是否存在障碍。
# 4,309,569  Method of Providing Digital Signatures(issued) January 5, 
1982(inventor) Ralph C.  Merkle(assignee) The Board of Trustees of the Leland 
Stanford JuniorUniversity
# 5,001,752  Public/Key Date-Time Notary Facility(issued) March 19, 
1991(inventor) Addison M.  Fischer
# 5,022,080  Electronic Notary(issued) June 4, 1991(inventors) Robert T.  
Durst, Kevin D.  Hunter
# 5,136,643  Public/Key Date-Time Notary Facility(issued) August 4, 
1992(inventor) Addison M.  Fischer(Note: This is a continuation of patent # 
5,001,752.)
# 5,136,646  Digital Document Time-Stamping with Catenate Certificate(issued) 
August 4, 1992(inventors) Stuart A.  Haber, Wakefield S.  Stornetta Jr.(assignee) 
Bell Communications Research, Inc.,
# 5,136,647  Method for Secure Time-Stamping of Digital Documents(issued) 
August 4, 1992(inventors) Stuart A.  Haber, Wakefield S.  Stornetta Jr.(assignee) 
Bell Communications Research, Inc.,
# 5,373,561  Method of Extending the Validity of a 
CryptographicCertificate(issued) December 13, 1994(inventors) Stuart A.  Haber, 
Wakefield S.  Stornetta Jr.(assignee) Bell Communications Research, Inc.,
# 5,422,95 Personal Date/Time Notary Device(issued) June 6, 1995(inventor) 
Addison M.  Fischer
# 5,781,629  Digital Document Authentication System(issued) July 14, 
1998(inventor) Stuart A. Haber, Wakefield S. Stornetta Jr.(assignee) Surety 
Technologies, Inc.,
13.  参考文献
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", 
BCP 14, RFC 2119, March 1997.
[RFC2510]Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure, 
Certificate Management Protocols", RFC 2510, March 1999.
[RFC2459]Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public 
Key Infrastructure, Certificate and CRL Profile", RFC 2459, January 1999.
[RFC2630]Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[ISONR]ISO/IEC 10181-5:  Security Frameworks in Open Systems.Non-Repudiation 
Framework.
[RFC2119]Bradner, S., "Key works for use in RFCs to Indicate Requirement Levels", 
BCP 14, RFC 2119, March 1997.
[RFC2511]Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet X.509 Certificate 
Request Message Format", RFC 2511, March 1999.
[RFC2246]Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC 2246, 
January 1999.
[RFC2634]Hoffman P., "Enhanced Security Services for S/MIME", RFC 2634, June 
1999.
[RFC2560]Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. Adams, "X.509 
Internet Public Key Infrastructure Online Certificate Status Protocol", RFC 2560, 
June 1999.
14.  作者地址
Carlisle Adams
Entrust Technologies
1000 Innovation Drive
Ottawa, Ontario
K2K 3E7
CANADA
EMail: [e-mail]

Michael Zolotarev
Baltimore Technologies Pty Limited
5th Floor, 1 James Place
North Sydney, NSW 2060
AUSTRALIA
EMail: [e-mail]

Peter Sylvester
EdelWeb SA - Groupe ON-X Consulting
15, Quai de Dion Bouton
F-92816 Puteaux Cedex
FRANCE
EMail: [e-mail]

Robert Zuccherato
Entrust Technologies
1000 Innovation Drive
Ottawa, Ontario
K2K 3E7
CANADA
EMail: [e-mail]
附录 A - PKCS #9 属性
定义了一个PKCS #9属性类。这个属性类具有ASN.1类的SignedData，且包含一个数
据有效性证书。对象标识符id-aa-dvcs-dvc标识数据有效性证书的属性类。
id-aa-dvcs-dvc OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) aa(2) 29}
这个属性可用在CMS SignedData 中，作为验证和未验证属性。
附录 B – 签名文档确认
我们列举了几个在签名文档确认环境中，DVCS的使用。
B.1签名文档确认
所示范例说明签名者使用的DVCS可用来证明包括一个和多个附属签名文档结构，在签
名后仍是正确的。DVC可由签名者信任的DVCS产生，也可由文档预计的验证者所信任的DVCS
产生。
签名者使用获得的DVC作为表明其目的是好的一个证据，使用已知正确的环境（如密钥、
算法）来产生签名文档。
产生的单机文档可用来扩展签名的生命期。此范例假设我们完全信任数据有效性和证书
服务器。
签名算法和密钥的生命期是有限的。因此，签名的生命期也是有限的。数据证书服务器
可要来延长签名的生命期。
为了用这种方法延长签名的生命期，要使用以下的技术：
1) 需被验证的签名:
签名的消息要出现在数据有效性和证书服务器的vsd服务请求中。
当检查终结日期、状态信息或DVCs时，DVCS验证签名和证书是有效的，并且返回一个
DVC。
2) 需被验证的DVC
数据证书标记中数据有效性和证书服务器的签名用数据证书服务器的有效验证密钥来
验证。
签名者的签名密钥（以及因此产生的签名）在某个指定时间T1是唯一有效的。DVCS的
签名密钥（以及因此产生的签名）在某个指定时间T2是有效的，T2通常在T1之后。如果
没有证书，签名者的签名就只在T1时间有效。如果有证书，签名者的签名在T2时间仍然有
效，不管随后是撤销或在T1时间就终结。
如果DVCS的签名有效，那么对DVCS的信任会使我们认为数据原始签名在包含到DVC
中时是有效的。
DVCS签名密钥必须足够长，以便有足够长的生命期。即使这样，密钥的生命期依然是
有限的。因为数据有效性证书仅是另一种形式的签名文档，所以它们可使用（其它）DVCS
进行确认。
附录 C – 验证公钥证书的状况
现在举三个例子说明如何产生一个数据有效性证书，此证书可用来声明公钥证书是有效
的、可信的，以及这个证书的特殊使用目的。
客户端希望使用一个给定的公钥证书或者验证文档的签名或者用来加密文档。
DVCS必须能够访问关于公共证书状态目前的信息，因为那样才能使它在此时可用来验
证证书的撤销状态。 
可以使用以下方法：
A)需要确认公钥证书。
证书出现在是使用'vpkc' 服务的数据证书服务器中。
数据有效性和证书服务器验证公钥证书是有效的，没有被撤销，然后返回一个数据有效
性证书。
B) 必须验证数据有效性证书。
数据证书标记中的数据证书服务器的签名应当用数据有效性和证书服务器的有效证书
进行验证。
C) 公钥证书用来：
C.1) 客户端自己的公钥证书（也就是对应的公钥）可用来给文档增加签名。签名证书
和数据有效性证书可作为签名的签名属性。
数据有效性证书可在使用公钥证书中包含的密钥签名的有效期内使用。这个由DVCS提
供的服务可被认为是检查撤销状态的通常方法的补充。
换句话说，最近一次的签名有效性并不一定需要访问用户签名证书的撤销状态，也不一
定需要访问DVCS服务，DVC的有效性就足够用来验证签名。注意：DVC不区分签名的创建时
间，它仅指示出什么时候签名证书是有效的。
C.2) 用于密钥交换的公钥证书在获得数据有效性证书对加密数据的证明后使用。DVC
可和数据一起存储，也可/或由加密文档的创建者存储。
如果预计的接收者宣称创建者没有使用合适的加密密钥，那么（接收者的DVCS获得的）
DVC可用来证明接收者的DVCS已经授权使用此公钥。
C.3) 上一段描述的过程可通过几种方式加强用来提供域加密。一般的机构会要求加密
的文档是可重获的。一个简单的方法是在加密文档时，始终带上作为“域加密中心”或“恢
复中心”的额外接收者信息。这在技术上并不是个困难问题，但是要求和终端用户之间有复
杂和较困难的交互，尤其是当文档的接收者位于几个不同的机构中时。
 一种可能的解决方法是增加其它证书到dvc中，确认用来加密的特殊公钥证书的使用。
在有几个机构的环境中，一个可能的过程是：
 客户端要求本地dvcs确认公钥证书，Dvcs把请求转发到一个远程机构。远程机构的
dvcs验证这个证书，并提供对此证书有效性的一个dvc声明。在certEtcChain结构中增加
一些用于密钥交换的证书，指示其余必要的接收者。本地dvc创建一个包含远程dvcs的这
个dvc的dvc。还可以往dvc中增加其它的证书和参考。客户端使用所有有效的证书用于密
钥交换，以扩展接收者列表。
 在本地，dvcs也可使用本地关于远程机构需要的其它接收者的信息。
附录 D - MIME 注册
至: [e-mail] 
主题：MIME介质类型应用/时间戳的注册
MIME介质类型名称：应用
MIME子类名称: dvcs
所需参数：没有
可选参数：没有
编码：二进制或Base64 
安全：带有一个数据有效性和证书服务的请求以及响应。请求是用加密算法签名的。响
应也将是用加密算法签名的。
互操作性：没有
发布说明：
RFC 3029 关于数据有效性和证书服务器协议
使用此介质类型的应用：数据有效性和证书服务器和客户端
其它信息：
  Magic number(s): None
  文件扩展名：.dvc
  Macintosh文件类型编码：没有
  了解更多信息需联系的人和邮件地址：Peter Sylvester  
<[e-mail]>
  预计的用法：普通
  作者/有权改变的人：Peter Sylvester<[e-mail]>
附录 E – 使用1988语法的ASN.1 模块
PKIXDVCS {iso(1) identified-organization(3) dod(6) internet(1) security(5) 
mechanisms(5) pkix(7) id-mod(0) id-mod-dvcs(15)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
  Extensions, AlgorithmIdentifier
  FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) 
security(5) mechanisms(5) pkix(7)  id-mod(0) id-pkix1-explicit-88(1)}

  GeneralName, PolicyInformation
  FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) 
security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}

  PKIStatusInfo, PKIStatusField FROM PKIXCMP {iso(1) 
identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 
id-mod(0) id-mod-cmp(9)}

  ContentInfo FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840) 
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}

  ESSCertID FROM ExtendedSecurityServices
  { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 
modules(0) ess(2) }

  CertId, OCSPResponse, CertStatus  FROM OCSP
  {iso(1) identified-organization(3) dod(6) internet(1) security(5) 
mechanisms(5) pkix(7) id-mod(0)  id-mod-ocsp(14)}

  SMIMECapabilities FROM SecureMimeMessageV3
  { iso(1) member-body(2) us(840) rsadsi(113549)  pkcs(1) pkcs-9(9) smime(16) 
modules(0) smime(4) }
  ;

-- 访问 DVCS的授权信息

id-ad-dvcs  OBJECT IDENTIFIER ::= {id-pkix id-ad(48) 4}

-- DVCS的主要功能 

id-kp-dvcs  OBJECT IDENTIFIER ::= {id-pkix id-kp(3) 10}

-- dvcs 请求和回应的eContentType 

id-ct-DVCSRequestData  OBJECT IDENTIFIER ::= { id-smime ct(1) 7 }
id-ct-DVCSResponseData OBJECT IDENTIFIER ::= { id-smime ct(1) 8 }

-- 数据有效性证明属性

id-aa-dvcs-dvc OBJECT IDENTIFIER ::= { id-smime aa(2) 29 }

-- 使用以下库：

id-pkix  OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) dod(6) 
internet(1) security(5) mechanisms(5) pkix(7)}

id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) 
pkcs(1) pkcs-9(9) 16 }

Version ::= Integer

DigestInfo ::= SEQUENCE {
 digestAlgorithmDigestAlgorithmIdentifier,
 digestDigest
}

Digest ::= OCTET STRING