On Wed, 2019-03-27 at 09:01 +0100, Rick van Rein wrote: > Hi, > > > We used to always DER-re- > > encode certificates, but that caused problems interoperating with > > golang applications which used to generate certificates not > > following > > DER very strictly, thus gnutls was breaking the signatures for > > them. > > Liberal in what you accept, I see. I took a similar approach with > Quick DER, which accepts almost all BER forms as well. > > They are breaking standards however, and it has me concerned that > this was not debugged in the Go code. Even though I can even read > the RFCs to say that the TBSCertificate may be encoded differently > (including JER) the signature itself must be computed over de DER > form. Packing a certificate into JER might actually be useful to > some use cases, but it would break on Go certificates, apparantly. > > I am wondering if this might create a single-language ecosystem that > won't work with other applications. I would have stopped Google at > this point. It is a good reason to not use Go, or at least its > certificate "support" code. > > I would have started a debugging process in Go... and perhaps given > them some leeway for a few upcoming releases.
The issue was not something complex, but with the SET ordering in DER rules; it was treated as bug: (though not yet resolved) https://github.com/golang/go/issues/24254 regards, Nikos _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
