Below are the publicly exposed asn1.ObjectIdentifier fields in the
golang/go repo. It has fairly limited exposure,
but I'm sure some people will argue it's too much (maybe ok in go 2.x but
not 1.x?).
1. encoding/asn1:
1. My guess is this would be primarily used by SNMP applications such
as https://github.com/soniah/gosnmp/search?q=asn1&unscoped_q=asn1
2. crypto/x509/pkix package has 4 exported fields using asn1.
ObjectIdentifier
3. crypto/x509 package:
1. ECDSA keys
2. Used in the x509.Certificate struct:
// A Certificate represents an X.509 certificate.
type Certificate struct {
...
UnhandledCriticalExtensions []asn1.ObjectIdentifier
UnknownExtKeyUsage []asn1.ObjectIdentifier
PolicyIdentifiers []asn1.ObjectIdentifier
}
I doubt there are many applications that actually inspect these 3 fields.
On Friday, June 26, 2020 at 12:53:43 PM UTC-7, Sebastien Rosset wrote:
>
> As an aside, the most common use of the encoding/asn1 package is most
> likely crypto/x509. x509. Certificate exposes public fields that use the
> asn1.ObjectIdentifier, so asn1 ends up being exposed in a lot of
> applications, such as for TLS connection management.
>
> On Friday, June 26, 2020 at 12:04:09 PM UTC-7, Sebastien Rosset wrote:
>>
>> sure, thank you. I will go through the PR review process for asn1 and
>> x509, maybe some good ideas will come up.
>> Sebastien
>>
>> On Friday, June 26, 2020 at 11:51:05 AM UTC-7, Ian Lance Taylor wrote:
>>>
>>> On Fri, Jun 26, 2020 at 11:03 AM Sebastien Rosset <[email protected]>
>>> wrote:
>>> >
>>> > @ianlancetaylor , thank you for the quick reply. The reason I was
>>> asking is because potentially this could have been used to fix `type
>>> ObjectIdentifier []int` in the `encoding/asn1` package and the
>>> `crypto/x509` package. Currently these package are not fully compliant with
>>> the ASN.1 specification, which means in practice some certificates cannot
>>> be parsed.
>>> >
>>> >
>>> > I am trying to fix the encoding/asn1 and crypto/x509 package by adding
>>> support for OID values that are greater than 2^31. There are multiple ways
>>> to fix the issues, and unfortunately it won't be possible to simply change
>>> the ObjectIdentifier type because that would break too many applications.
>>> If it's not possible to change the type, then most alternatives seem to be
>>> somewhat cumbersome. For reference the PR is
>>> https://github.com/golang/go/pull/39795.
>>>
>>> Thanks, understood.
>>>
>>> Generics don't solve all problems. I agree that there seems to be a
>>> way that we could modify generics to solve this particular problem.
>>> But it means introducing an idea that the rest of the language has
>>> decided to reject: default values for arguments. I don't think it
>>> would be consistent with the language to permit default values for
>>> type arguments when we do not permit default values for non-type
>>> arguments. While we don't have to be strictly consistent here, I
>>> think we need a good reason to break consistency. And in the larger
>>> scheme of things I don't think that making it easier to make a
>>> backward compatible change to one specific package, a package that is
>>> not all that widely used, is a good enough reason.
>>>
>>> I'm not claiming to have the final word, but that is my opinion.
>>>
>>> Ian
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/39bf626a-ed31-4c89-bc0f-a685927e7046o%40googlegroups.com.
