Some changes in local anchors and identity.
I am now completely cut over to using my PGP key generated in 2013, as a 4096-bit RSA key, to replace the previous 1024-bit DSA keys from long ago.
The new key,
0x4D1E900E14C1CC04, is in the strong-set:
I took care to ensure that was the case before cutting over to it.
It has been signed by both my older keys, with a Signature Policy URL which
/self and the text retrieved therefrom asserts that it’s an “it’s me”
The key is available from the usual places (public keyservers, etc) and is referenced on my non-blog homepage together with a form for quick lookup of trust-paths.
In passing, I’ll also note that my OTR fingerprints are available there, together with PGP-signed statements of those fingerprints, so that those wishing to chat via XMPP have a trust-path to validate my OTR identity.
I am now on my fourth generation personal certificate authority (CA). As each time before, there is a limited claimed lifetime on the new CA; as each time before, the lifetime is a little longer this time. The old third-gen CA expires later this month.
The new CA,
CN=GlobNIX Certificate Authority 4, will expire in 2022.
It uses SHA2-256 for its self-signature, which is also the algorithm used for
each certificate issued. Each cert uses random serial numbers. The CA has a
3072-bit RSA key, most services are using 2048-bit RSA keys. I’d like to be
comfortable enough with the state of client applications to move towards ECC,
but we’re not there yet. If I’m not off RSA by the time CA5 is issued, I
shall be disappointed.
I don’t expect anyone outside of my household to install this CA as a trust anchor for general purpose usage; however, it is the trust-anchor in DNS as the TLSA record for various DANE-protected services. At this time, the number of clients verifying via DANE is low, but I hope that will change over the next eight years.
Thus I mention this CA because verification to most of my sites on HTTPS will fail for most people, as it always has, and so that this post can act as a public declaration of which CA is expected to be present (and to hint that if you used DANE verification, then things would succeed).
If you want to independently verify the trust anchorage, then you can fetch
globnixCA4.crt file from https://www.security.spodhuis.org/ – the
only one of my own sites to use a certificate from a public PKIX rentier.
Any service using
globnixCA3.crt should by now already be using the CA4
certificate, with a reissued certificate. If not, it’s a mistake on my part.
The only sites/services of mine not using a freshly reissued certificate are the aforementioned public PKIX one and those few still using CACert certificates. The latter group will dwindle over time, as I replace the certs as they expire, the replacements being issued by my own CA. The only one I think folks might be using and notice is the one on my git server, because it has some auto-updated mirrors which are occasionally convenient. When the time comes, I shall cut over to my own CA regardless of the state of TLSA verification.
To test, you could always try to access this blog over HTTPS – that uses my own CA. DNSSEC and TLSA are all in place. https://bridge.grumpy-troll.org/ If that works for you, then I’d be interested in knowing details of the browser and OS.
-The Grumpy Troll