connect: don't colon-hex-encode the AuthorityKeyId and SubjectKeyId fields in connect certs

[rboyer]

The fields in the certs are meant to hold the original binary
representation of this data, not some ascii-encoded version.

The only time we should be colon-hex-encoding fields is for display
purposes or marshaling through non-TLS mediums (like RPC).

This obviates #6080

• update SigningKeyID examples on website

[hanshasselberg]

I didn't know what this is doing, but https://blog.golang.org/go-slices-usage-and-internals knows:

This is also the syntax to create a slice given an array:

x := [3]string{"Лайка", "Белка", "Стрелка"}
s := x[:] // a slice referencing the storage of x

[hanshasselberg]

Nice work!

I am wondering how this prevents the double encoding though. EncodeSigningKeyID uses HexString and it seems to me double encoding could still happen? On the other hand, there are tests proving me wrong :D.

[rboyer]

The SigningKeyID is a consul-only thing which is a colon-hex-encoded version of the thing stored in the x509 fields AuthorityKeyId or SubjectKeyId.

In x509 AuthorityKeyId and SubjectKeyId are both opaque bytes that "summarize" the entity they represent in a spec-suggested way (hash some stuff). Since these are part of the x509 spec they already get encoded, so there's no need to encode what goes into them.

If you use a command like openssl x509 -in root.pem -noout -text to pretty-print the contents of a PEM file in order to display those bytes back at you the openssl command will colon-hex encode them for display, which can easily confuse the matter when you are trying to understand what is actually stored in there.

We had been generating the AuthorityKeyId/SubjectKeyId values by hashing some fields and also colon-hex-encoding that before stuffing it into the x509 fields. This meant that when consul generated the SigningKeyID for comparison purposes it was colon-hex-encoding something that was erroneously already colon-hex-encoded.

That said the old way of doing things was at least self-consistent when you stick with one CA provider. If you mixed them (consul + vault, or likely what @tradel was doing) things didn't quite line up.

Now the only time things get colon-hex encoded is for informational display purposes, or for sending around as a consul SigningKeyID field.

[banks]

Nice! Good sleuthing RB. Glad we figured that out rather than plaster over it! Does this means the other PR can be closed now?

[rboyer]

Yep. Closed the other PR.