Self Sovereign Identity (aka SSI) is the only way out of those identity sovereignty issues. It shouldn't be acceptable that your identity depends on anything or anyone. It should just be your identity.
A paper or certificate can prove an entity trusts your identity to be <firstname, lastname, etc...> but that shouldn't be your identity.
You just are. Not your google Id, not your Apple Id either of course.
You are conflating the philosophical notion of identity with functional identification in the real world. There is no cryptographic escape hatch from the social contract.
>You just are/I just am
Is not an acceptable thing to say to a bar tender when being served an alcoholic drink when you're 22. You hand them government issued ID.
I agree, and that government ID isn't your identity, it's just a piece of it.
I'm not arguing against government ID, I'm saying identity doesn't have to be that piece of paper, or that Google ID.
Analogy: if google ID is your primary key in your User table, then you're cooked. Instead use a uuid for the PK, and add Google ID as just another id. But the identity is the PK.
eIDAS tends to hear "our European Sovereignty" when they hear Self-Sovereign.
You can't have a government issue a Self-Sovereign identity to you, it's an oxymoron. They can only issue credentials. But then they'd feel like they're losing control, so they pervert it. Now they call it SSI but it's just digital credentials.
The very title says it all: German implementation of eIDAS will require Google or Apple ID. That's not self-sovereign identity.
Hi! thanks for your feedback. Indeed the site fails to tell you what ezS3 does: it's not an alternative to Minio, it's not an S3 storage implementation. S3 is made for machines, ezS3.net "proxies" it for humans: it's a web-based S3 browser, and adds RBAC and sharing.
The scalable way (up to thousands of certificates) is https://sslboard.com. Give it one apex domain, it will find all your in-use certificates, then set alerts (email or webhook). Fully external monitoring and inventory.
Looks like it relies on certificate transparency logs. That means that it won’t be monitor endpoints using wildcard certs. Best thing it could do would be to alert when a wildcard cert is expiring without a renewed cert having been issued.
Is that enough though? You may have wildcards on domains that are not even on a public DNS and you may forget to replace it "somewhere". For that reason it is better to either dump list of domains from your local DNS or have e.g. zabbix or another agent on every host machine checking that file for you.
That's exactly my point. Is that while this service sounds quite useful for many common cases, it's going to fail in cases where there's not a 1-to-1 certificate-to-server mapping. Even outside of wildcards, you have to account for cases where the cert might be installed on N number of load balancers.
If you're using a cert on multiple IPs, or IPv4+v6, SSLBoard will monitor all IPs. It's not foolproof, but it covers most common practices. btw wildcard certs don't have a good reputation (blast radius)...
I'd say that load balancers (one-address-to-N-servers) count as a common practice, but I otherwise agree in that regard.
Regarding wildcard certs, eh. I wouldn't say they have a bad reputation. Sure, greater blast radius. But sometimes it can certainly simplify things to use one. Your ACME client configuration is easier and your TLS terminator configuration often becomes easier when the terminator would otherwise need to switch based on SNI.
one-address-to-N-servers is perfect if the N servers don't all terminate TLS. If not, it becomes impossible to actually test what certificates are actually served. I've seen this fail before (TLS tests flip/flop between good/bad between checks).
As for wildcard certs, I agree there are use cases where we really need them like dynamic subdomains {customer}.status.com
Can you share how they make ACME client configuration easier?
> Can you share how they make ACME client configuration easier?
It's not a profound difference, but you don't need to add each name to your config. Depending on the team's tooling and processes, that may be inconsequential. But in a setting where config management isn't handled super well, where the TLS terminator is a resource shared by multiple, distinct teams, this is a simplification that can make a difference at the margin.
Think less Cloudflare-scale, and more SMB scale (especially in a Windows shop or recovering Windows shop with a different kind of technical culture than what we might all be implicitly imagining).
I'm working on something that could help: linking sslboard with software that's making issuance and distribution of certs easier, ie. a proper CLM. It's not cloud based for security reasons. In that context, we know your wildcard certs because we issue them, and we could know where they are if we distribute them...
Please get in touch with me (chris@sslboard.com) if you're interested in early access and having a word in the development of the product!
I didn't realize you were behind SSLBoard. I think you should've disclaimed that involvement at the beginning. I see now that it's in your bio, but disclaiming is still on you.
Indeed, SSLBoard is scanning CT logs. You can add/import host names though, to allow monitoring of wildcard certs. Same if you're using ports that are not 443, you have to add these to the list of hostnames that are checked.
It's not as convenient, but it's the best SSLBoard can do...
Unsurprisingly it’s a European article. Europe will tax AI to death like it does with everything it can’t find a way to compete in. And it can’t compete in much…
I dearly remember seeing a PX-8 in the hands of a person (was it by a pool?) and thinking "it would be so nice if work could look like that". It must have been Byte magazine?
I was a kid in France, now I'm working remotely from Bangkok: dreams come true after all.
You could create a browser extension that normal users could install such would warn them of a phishing site or email from that domain. It would be 0 cost since you already have the data.
A paper or certificate can prove an entity trusts your identity to be <firstname, lastname, etc...> but that shouldn't be your identity.
You just are. Not your google Id, not your Apple Id either of course.
Governments are lame.
reply