TSP、OCSP 和 CMS 的 Java 实现

发布于 2024-12-07 18:06:41 字数 329 浏览 1 评论 0原文

我正在尝试了解用于数字签名的 java API。 我应该使用自定义 cryptoprovider 来编写数字签名。我知道如何使用此 CSP 签署文档并获取分离签名,现在我需要向此签名添加时间戳和证书状态(以使签名对政府机构有效)。这些事情是使用 TSP 和 OCSP 完成的。 问题:

  1. TSP客户端应该去哪里获取?
  2. 我说得对吗,使用内置的 java OCSP 支持就足够了 用于验证证书?
  3. tsp 和验证信息是否以某种方式与 CMS 连接?
  4. 最后也是最有趣的:我应该如何处理时间戳 信息和证书验证信息:它是分离的文件还是它们 是签名的一部分吗?

I'm trying to understand java APIs for digital signatures.
I should use custom cryptoprovider to compose digital signature. I know how to sign document and get detached signature using this CSP, now I need to add timestamp and certificate status to this signature(to make signature valid for government authorities). These thing are done using TSP and OCSP.
The question:

  1. where should get TSP client?
  2. am I right that it is sufficient to use built in java OCSP support
    for verifing certificate?
  3. does tsp and verification info somehow connected with CMS?
  4. the last and the most interesting: what should I do with timestamp
    info and cert verification info: would it be detached files or they
    are parts of signature??

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

软的没边 2024-12-14 18:06:41

哪里可以获得TSP客户端?

要使用 CMS、TSP 和 OCSP,您可能需要查看 Bouncy Castle。他们支持主包以及补充 CMS 和 TSP 包中的所有内容。

使用内置的 java OCSP 支持来验证证书就足够了吗?

尽管标准 PKIX 证书验证机制支持 OCSP,但以自定义 PKIXCertPathChecker。您可以将其添加到现有验证之上,也可以将其作为完整的替代品,可以找到说明此处。通过代理连接时,我们在使用内置 OCSP 支持时遇到了问题,因此我们过去使用此技术替换了默认设置。

tsp 和验证信息是否以某种方式与 CMS 连接?

TSP 服务器发送给您的时间戳响应只不过是另一个 CMS SignedData,因此其本身又是一种签名。为了避免出现大量单独的文件,您通常会使用 CMS 的未签名属性功能将时间戳包含在原始签名本身中。您只需将时间戳作为未签名的签名属性添加到 SignerInfo 的 usignedAttrs 字段中,从而将单独的文件最小化为一个,即签名本身将所有附加信息嵌入到signedAttrs 和 unsignedAttrs 字段中。

最后也是最有趣的:我应该如何处理时间戳信息和证书验证信息:它是分离的文件还是签名的一部分?

时间戳我已经描述过了;验证信息(例如 CRL 和 OCSP 响应)可以嵌入到 SignedData 的“crls”字段中。您可以随时添加这些内容,而不会破坏实际签名 - 这些内容以及未签名的属性在生成或验证签名时都不会被考虑在内。

如果您仅使用 CMS (RFC 5652) 嵌入信息,则意味着您最终将得到一个相当专有的方案。根据您的需求,这可能已经足够好了。但是,如果您需要更具互操作性的东西,您可能需要研究 CAdES (ETSI TS 101 733),这是一个免费的 ETSI 标准,可以在 http://pda.etsi.org。该标准提供了有关如何正确嵌入附加签名数据(例如时间戳和吊销信息)的更多信息。

where should get TSP client?

To use CMS, TSP and OCSP you might want to check out Bouncy Castle. They have support for all of those in the main package as well as the supplementary CMS and TSP packages.

am I right that it is sufficient to use built in java OCSP support for verifing certificate?

Although the standard PKIX certificate validation mechanism supports OCSP it might make sense to integrate e.g. the Bouncy Castle OCSP code in the form of a custom PKIXCertPathChecker. You can either add it on top of the existing validation or make it a full-fledged replacement, instructions can be found here. We had problems using the built-in OCSP support when connecting through a proxy, so we replaced the default using this technique in the past.

does tsp and verification info somehow connected with CMS?

The timestamp response that the TSP server sends you is nothing more than another CMS SignedData, so in itself again a kind of signature. What you typically do in order to avoid myriads of separate files is using the unsigned properties feature of CMS to include your timestamp within the original signature itself. You simply add the timestamp as an unsigned signature property in the usignedAttrs field of SignerInfo, therefore minimizing the separate files to exactly one, the signature itself which embeds all additional information within the signedAttrs and unsignedAttrs fields.

the last and the most interesting: what should I do with timestamp info and cert verification info: would it be detached files or they are parts of signature??

Timestamps I have already described; the validation info such as CRLs and OCSP responses can be embedded within the "crls" field of SignedData. You can add these whenever you want without breaking the actual signature - these contents as well as the unsigned properties will not be taken into account for either generating or verifying the signature.

If you embed the information using just the CMS (RFC 5652) means you will end up with a fairly proprietary scheme. Depending on your needs, this might already be good enough. If you should need something more interoperable, however, you might want to look into CAdES (ETSI TS 101 733), a free ETSI standard that can be downloaded at http://pda.etsi.org. That standard provides more information on how to properly embed additional signature data such as timestamps and revocation information.

旧瑾黎汐 2024-12-14 18:06:41

如果您正在研究与提供商相关的 Java 加密技术,我建议您使用 BouncyCastle (http://www.bouncycastle.org/java.html)。

引用其网站:

  • OCSP 的生成器/处理器 (RFC 2560)。
  • TSP 的生成器/处理器(RFC 3161 和 RFC 5544)。

I would recommend using BouncyCastle (http://www.bouncycastle.org/java.html) if you are looking into Java Cryptography related for a provider.

Quoting from it's website:

  • Generators/Processors for OCSP (RFC 2560).
  • Generators/Processors for TSP (RFC 3161 & RFC 5544).
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文