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. -Rick _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
