指示版本和“模式”的标准方式X509证书
我有一个系统，其中 X509 证书可以有多个“模式”，其中模式是证书主题中必需/可选的确切 OID 的集合。验证这些证书的应用程序需要知道给定证书使用了什么架构（以及该架构的哪个版本）。
例如，模式 A 需要 CN、O、OU，模式 B 需要 CN、UID、O、C、ST。
我正在寻找一种标准方法来对证书中的架构（+版本）进行编码，以便接收应用程序可以从证书中得知如何解析它。解决方案：
- 劫持一些完全不相关的OID，将这些信息塞到主题中。我不喜欢这个，但它可以作为一个 hack-y 后备。
- 使用扩展。我认为主题目录属性看起来可能是合适的，但它似乎仍然需要 OID 名称/值对作为其负载，那么又是哪些 OID？
- 完全是别的什么吗？
再说一次，我可以使用 #1 来完成这项工作，也可以使用 #2 进行类似的 hack，但我真正想要的是一种标准的非 hack 方式来实现这个目标。
I have a system in which X509 certificates can have a number of "schemas" where a schema is is a collection of the exact OIDs that are required/optional in the subject of the cert. The application that verifies these certificates needs to know what schema (and what version of that schema) has been used for a given certificate.
For example, Schema A requires CN, O, OU and schema B requires CN, UID, O, C, ST.
I'm looking for a standard way to encode the schema (+ version) in the certificate so the receiving application can tell from the certificate how to parse it. Solutions:
- Hijack some totally unrelated OID to stuff this information into the subject. I don't like this, but it would work as a hack-y fallback.
- Utilize an extension. I think the Subject Directory Attributes looks like it might be appropriate, but then it still seems to require OID name/value pairs as its payload, so again which OIDs?
- Something else entirely?
Again, I can make this work with #1 or could do a similar hack with #2, but what I really want is a standard non-hack way to accomplish this goal.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我假设您会关心使用什么模式。因此，这意味着您可能在 DN 中拥有这些字段 - 并且它们也构成了 CA 签署的内容（带有强制性杂项）。因此，假设您的模式不同 - 这会让您区分它们。
另一种选择是每个方案都有一个（子）CA；或者直接使用 netscape 评论字段:)。
然而，根据我的经验 - 当组织与广告、识别/重建和解释该计划相关时 - 这通常意味着它具有某种商业目的。所以它通常有一个有用的企业名称。在这种情况下；考虑一个（额外的）O 或 OU（如果需要的话，可以有多个变体）。
I'd assume you would care about what schema is used. So that means that you probably have exactly those fields in the DN - and that they are also making up the breath of exactly what is signed by the CA (with the mandatory sundry). So assuming your schema's are different - that would let you distinguish them.
Another option would be a (sub)CA per scheme; or simply use the netscape comment field :).
In my experience however - when it is relevant for the organization to thus advertise, recognize/reconstruct and interpret the scheme - that generally means that it has some business purpose. So it generally has a useful business name. In that case; consider an (extra) O or OU (multi variant if needed) with that in there.
我最终在 2.25 弧线下为我的两个元数据字段（架构和版本）使用基于 UUID 的 OID。
为了方便起见，以下站点提供了 UUID 生成器和注册链接（尽管并不严格要求注册）：
I've ended up utilizing a UUID-based OID under the 2.25 arc for each of my my two metadata fields (schema and version).
The site below offers a UUID generator as a convenience and a registration link (although registration isn't strictly required):
http://www.itu.int/ITU-T/asn1/cgi-bin/uuid_generate