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(用于编组)等效项。
9条答案
按热度按时间6rqinv9w1#
我不反对添加
SRVNames
,而x509.Certificate
已经远远超出了人体工程学API表面领域的范围。我更担心添加具有重叠含义和复杂可扩展性的API,导致像您用Extensions
识别的问题那样的麻烦。您认为还需要
XMPPAddresses
吗?cxfofazt2#
我不会反对只添加
SRVNames
。这听起来不错,我会准备一个CL。
你认为你还需要
XMPPAddresses
吗?我不抱怨,但如果感觉有点小众,我可以在紧急情况下不用它。
xzlaal3s3#
https://golang.org/cl/97376提到了这个问题:
crypto/x509: add SRV and XMPP fields
ipakzgxi4#
更新:我已经将证书和证书请求的解析和编组添加到了CL中,但在等待https://golang.org/cl/96378的结果之前,我不会进行任何验证,因为如果我现在就做的话,可能需要更复杂的重置。
qyyhg6bp5#
根据@FiloSottile的评论,已接受SRVName。
w7t8yxp56#
这是我暂时用来解决我的问题的方法(从标准库中复制和修改了很多代码)。如果这个问题中提出的某个解决方案(或类似的东西)被接受,我可以将其适应性地应用回
crypto/x509
: https://godoc.org/mellium.im/xmpp/x509。bvn4nwqk7#
CL 62693正在添加更多的约束检查,但没有SRVNames。我在那里做了注解,以便找出是否应该添加它。
bwleehnv8#
这并没有在CL 62693中得到解决;既然1.11树已经开放,上述提出的API是否可以接受?如果可以,我将在本周期内提交一个CL。谢谢!
pkbketx99#
/cc @FiloSottile@agl