go crypto/x509: 提供一种访问SRVNames的机制

ef1yzkbh  于 6个月前  发布在  Go
关注(0)|答案(9)|浏览(43)

X.509证书中由RFC 4985定义的SRVName字段允许证书用于验证某个实体管理了某个服务,而不需要给同一个实体控制整个域或子域(例如,如果使用了DNSName或CommonName)。

我想能够从使用x509.ParseCertificate等解析的证书中访问SRVNames。我可以看到有两种方法可以做到这一点,这取决于这个信息需要多容易获取。最简单的方法是在现有的SAN字段旁边添加一个字段到Certificate结构中:

type Certificate struct {
    …
    // Subject Alternate Name values
    DNSNames       []string
    SRVNames       []string
    EmailAddresses []string
    IPAddresses    []net.IP
    …
}

同时解析DNSNames时解析SRVNames。这种方法很容易使用,但可能不希望污染结构,添加更多其他Name值的字段(尤其是当#15196等问题可能已经导致它膨胀时)。

或者,原始的SAN字段可以从Extensions []pkix.Extension字段中提取出来。一种更具扩展性的方法是创建一个类似于Extensions的原始SAN字段,其中包含OID及其值的原始Map。例如:

type Certificate struct {
    …
    // Extensions contains raw X.509 extensions. When parsing certificates,
    // this can be used to extract non-critical extensions that are not
    // parsed by this package. When marshaling certificates, the Extensions
    // field is ignored, see ExtraExtensions.
    Extensions []pkix.Extension

    // SAN contains raw X.509 extensions that were not parsed into the DNSNames,
    // EmailAddresses, or IPAddresses fields..
    SAN []pkix.Extension
    …
}

这将使用户能够在不要求他们从Extensions中提取blob并再次解析的情况下获得SAN的任意字段。

请注意,这必须是附加到现有的Extensions中的原始SAN字段(我们可能无法删除它,因为代码可能已经在从Extensions中提取SAN字段)。出于这个原因,我没有包括一个ExtraExtensions(用于编组)等效项。

6rqinv9w

6rqinv9w1#

我不反对添加 SRVNames ,而 x509.Certificate 已经远远超出了人体工程学API表面领域的范围。我更担心添加具有重叠含义和复杂可扩展性的API,导致像您用 Extensions 识别的问题那样的麻烦。
您认为还需要 XMPPAddresses 吗?

cxfofazt

cxfofazt2#

我不会反对只添加SRVNames
这听起来不错,我会准备一个CL。
你认为你还需要XMPPAddresses吗?
我不抱怨,但如果感觉有点小众,我可以在紧急情况下不用它。

xzlaal3s

xzlaal3s3#

https://golang.org/cl/97376提到了这个问题:crypto/x509: add SRV and XMPP fields

ipakzgxi

ipakzgxi4#

更新:我已经将证书和证书请求的解析和编组添加到了CL中,但在等待https://golang.org/cl/96378的结果之前,我不会进行任何验证,因为如果我现在就做的话,可能需要更复杂的重置。

qyyhg6bp

qyyhg6bp5#

根据@FiloSottile的评论,已接受SRVName。

w7t8yxp5

w7t8yxp56#

这是我暂时用来解决我的问题的方法(从标准库中复制和修改了很多代码)。如果这个问题中提出的某个解决方案(或类似的东西)被接受,我可以将其适应性地应用回 crypto/x509 : https://godoc.org/mellium.im/xmpp/x509

bvn4nwqk

bvn4nwqk7#

CL 62693正在添加更多的约束检查,但没有SRVNames。我在那里做了注解,以便找出是否应该添加它。

bwleehnv

bwleehnv8#

这并没有在CL 62693中得到解决;既然1.11树已经开放,上述提出的API是否可以接受?如果可以,我将在本周期内提交一个CL。谢谢!

pkbketx9

pkbketx99#

/cc @FiloSottile@agl

相关问题