The SRVName field of an X.509 certificate defined by RFC 4985 allows a certificate to be used to verify that a service is managed by a particular entity without giving the same entity control over the entire domain or subdomain (eg. if DNSName or CommonName were used).
I would like to be able to access the SRVNames from a certificate parsed using x509.ParseCertificate and the like. I can see two ways of doing this, depending on how accessible this information needs to be. The easiest would be to add a field to the Certificate struct alongside the existing SAN fields:
type Certificate struct {
…
// Subject Alternate Name values
DNSNames []string
SRVNames []string
EmailAddresses []string
IPAddresses []net.IP
…
}
and parse the SRVNames at the same time we parse DNSNames. This is easy to use, but it may not be desirable to pollute the struct with fields for more otherName values that aren't as widely used (especially when issues like #15196 may already cause it to balloon).
Alternatively, the raw SAN field can already be pulled out of the Extensions []pkix.Extension field. A more extensible approach might be to create a raw SAN field similar to Extensions that contains the raw map of OIDs and their values. Something like:
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
…
}
which would make it possible for users to get ahold of arbitrary fields from the SAN without requiring that they pull the blob out of Extensions and re-parse it again.
Note that this would have to be in addition to the existing raw SAN field from Extensions (we probably can't remove it since code might already be pulling the SAN field out of Extensions). I have not included an ExtraExtensions (for marshalling) equivalent for this reason (what happens when both exist and you go to create a certificate?).
/cc @agl
The
SRVNamefield of an X.509 certificate defined by RFC 4985 allows a certificate to be used to verify that a service is managed by a particular entity without giving the same entity control over the entire domain or subdomain (eg. if DNSName or CommonName were used).I would like to be able to access the SRVNames from a certificate parsed using
x509.ParseCertificateand the like. I can see two ways of doing this, depending on how accessible this information needs to be. The easiest would be to add a field to theCertificatestruct alongside the existing SAN fields:and parse the SRVNames at the same time we parse DNSNames. This is easy to use, but it may not be desirable to pollute the struct with fields for more otherName values that aren't as widely used (especially when issues like #15196 may already cause it to balloon).
Alternatively, the raw SAN field can already be pulled out of the
Extensions []pkix.Extensionfield. A more extensible approach might be to create a raw SAN field similar to Extensions that contains the raw map of OIDs and their values. Something like:which would make it possible for users to get ahold of arbitrary fields from the SAN without requiring that they pull the blob out of Extensions and re-parse it again.
Note that this would have to be in addition to the existing raw SAN field from Extensions (we probably can't remove it since code might already be pulling the SAN field out of Extensions). I have not included an ExtraExtensions (for marshalling) equivalent for this reason (what happens when both exist and you go to create a certificate?).
/cc @agl