【问题标题】:x509 certificate for only one application - which OIDs to choosex509 证书仅适用于一个应用程序 - 可供选择的 OID
【发布时间】:2010-11-13 02:35:15
【问题描述】:

我正在创建将为用户创建证书的应用程序。我想以某种方式标记这些证书,以便稍后我可以通过以下类别在 Windows 用户证书存储中搜索它们:

  • 应用程序 GUID(或名称 - 我想知道此证书适用于我的应用程序)
  • 证书角色(管理证书或用户证书)
  • 用户邮箱

我知道对于最后一个我应该使用“E = J.Doe@mail.com”或 OID 号“1.2.840.113549.1.9.1 = J.Doe@mail.com” 但我不知道为应用程序 GUID 和证书角色选择哪些 OID。

或者我应该使用“Key Usage”字段?

我不知道这是否重要,但证书将用于对我的应用程序进行身份验证并解密数据库中的数据。

有什么标准的方法吗?

【问题讨论】:

    标签: certificate x509certificate


    【解决方案1】:

    您的任务是一项相当复杂的任务。要解决它,最好的方法是使用 openssl 进行一些内部证书颁发机构的工作。请记住,分配给您引用以下规则的实体的 PKI:

    1. 专有名称:用于标识颁发证书的用户或实体。使用它来识别单个证书中的两个不同实体是不正确的:您的用户和应用程序。这两个实体应该在两个不同的地方被识别。

    2. Key Usage 是一个 8 位的位字段,用于定义密钥的使用。每个位都有其预定的含义,不能用于其他目的。

    我建议你:

    1. 将应用程序 GUID 作为 x509 扩展名。您可以为该扩展分配和个人 OID 并查询它。如果您在内部使用 OID,则可以使用您想要的任何值。如果您计划分发您的证书,您可以从 IANA 获取您自己的 OID

    2. 按照 PKI 的建议,将邮件放在主题替代邮件字段中。

    3. 对于管理员或用户,您可以添加第二个 x509 扩展或创建证书树。主 CA 证书、管理员 CA 证书和用户 CA 证书。 admin 的每个证书都将由 admin CA 签名,每个用户证书都由用户 CA 签名。

    【讨论】:

      【解决方案2】:

      好的,几个小时后我带来了类似的东西。

      所有证书都将被主题字段识别。 对于管理员证书,它将如下所示:

      CN=<My application Name> Administrator,OU=Administrator,OU=<My application Name>,O=<My company Name>
      

      对于用户

      E=<User email>,CN=<User email>,OU=User,OU=<My application Name>,O=<My company Name>
      

      如果有人有更好的想法,我愿意提供建议:-)

      【讨论】:

        【解决方案3】:

        嗯...所以我的想法是您计划向每个用户颁发证书,并且您计划为每个应用程序制作不同的证书。因此,如果您有 10 个用户每人使用 3 个应用程序,那么您将制作 30 个证书。

        然后证书还描述了用户在应用程序中的角色,以及用户的电子邮件。

        说实话,我不会将所有这些信息都放在证书中。 PKI 很难提供——用户通常很难设置证书,并且重新颁发证书很痛苦。通常,PKI 部署策略会尽量减少必须颁发的证书数量,以平衡风险。

        我见过的最典型的情况是,用户获得了一个证书,他使用该证书来标识自己。证书包括用户的姓名和他的电子邮件。但它通常不包括用户的角色或特定的应用程序。相反,此信息在访问控制服务器上进行管理,当用户访问系统时会查询该服务器。这样,可以更改用户可用的角色和应用程序,而无需重新颁发证书。诸如 Active Directory 或 Select Access 之类的产品会执行此类操作。

        将每次使用分成单独的证书的原因是为了专门控制某种类型的风险。例如,如果单个用户在一台机器上执行高风险操作,而在另一台具有更高潜在风险的机器上执行低风险操作,则可能会有两个证书(每台机器一个),因此您可以撤销低风险证书而不禁用高风险功能。如果您计划将所有证书存储在同一台机器上,那么每个用户只分发一个证书会更容易。

        也就是说 - 如果您仍然需要为每个应用程序的每个角色的每个用户颁发 1 个证书,我建议您找到一种方法将应用程序 GUID、角色和电子邮件塞入专有名称。

        您不会从 Key Usage 或 Extended Key Usage 中获得太多好处 - 它们具有非常具体的价值,我怀疑它们是否会传达您想要描述的信息。此外,各种其他应用程序以特定方式使用它们,因此如果您需要与其他东西集成,这可能会变得很棘手。

        【讨论】:

        • 实际上,对于少数特别敏感的应用程序,我们将为每个用户配备一张智能卡,这些应用程序具有共同的“管理员”(即我们的财务总监)。而且我只有两种类型的管理员证书和用户证书。所有用户证书均由管理员签署。所有其他角色都在数据库中定义并由管理员签名。正如您所说的那样 - 数据泄露的风险很大 - 这就是我们采取这些特殊步骤来保护它们的原因。
        • 考虑到 PKI 的约定,这听起来像是一个非常不寻常的设置。通常,证书颁发机构 (CA) 处理所有证书签名,高权限用户使用他们的凭据来操作 CA。这样做是为了限制风险——CA 可以比管理员证书受到更严格的保护。此外,使用 PKI 标准概念可以让您利用证书吊销技术——如 CRL 和 OCSP。传统的 PKI 在风险管理方面经过了很好的审查,您最好不要重新发明轮子。
        猜你喜欢
        • 2022-01-25
        • 1970-01-01
        • 2022-11-15
        • 1970-01-01
        • 1970-01-01
        • 2019-06-15
        • 1970-01-01
        • 2022-01-03
        • 2022-01-07
        相关资源
        最近更新 更多