Reaching out to you with a kind of unusual request. I am working on eSIMs (embedded SIM cards) and the matching Subscription Manager infrastructure (See GSMA SGP02 doc, barely 300 pages ).
Anyway to cut it short I am using ECC keys and have no trouble generating them using openSSL and LetsEncrypt to create my X509 certificates. However in the SIM card industry (and smart card in general) when we need to store public keys/certificates on the cards using Card Verifiable Certificate instead of x.509. For my usage I am referring to the certs described in GlobalPlatform Specification Amendment e.
Basically, I am building my String to be signed using defined TLVs, and need my CI to sign it for me, and then I add the signing data to the original string using an additional TLV and VOILA I got my card compatible cert.
So my question it:
Is there a way of using custom CSR to do just that (i could find a way to do all I wanted)?
Is there any way to use certbot and its verification mechanism to get Letsencrypt to sign data for me?
Thanks for your help.
For info, here is what the cert looks like:
The data to be signed is (more or less) the first part of the cert without the signature (new users like me can only post one image)
A higher-level question: do you really want DV-validated certificates referring to a subject Internet domain name from a public web PKI CA? That’s the only service that Let’s Encrypt offers… and it’s not obvious to me that it’s really the most relevant kind of certification service for SIM applications. What’s the verification and trust model like in your application?
Edit: In most SIM applications, the “subscriber identity” is created by the mobile carrier (or in practice by a SIM vendor whose customer the mobile carrier is), which means that the mobile carrier itself is the primary authority on whether a particular subscriber identity is authentic or not. That authenticity means that the private key in the SIM corresponds to a public key in the carrier’s subscriber database which associates that SIM with a specific current mobile subscriber.
No other entity could confirm the authenticity of such an assertion, because the subscriber relationship refers to the business relationships between the carrier and the subscriber. In Let’s Encrypt’s model, the assertions that we’re confirming ultimately relate to people’s claims to control Internet domain names in the DNS that are issued to them by domain registries. We can confirm these assertions because the DNS records are publicly visible on the Internet, so we can go look them up. Would this kind of verification really be relevant to a SIM application? Don’t operators in this field operate some other kind of PKI that’s separate from the web PKI?
Thanks for your feedback. To be honest, I am for from my comfort zone here when I talk about Certificate and Crypto related matter, so I am relly thanking you for the detailed answer!
For SIM applications, I wouldnt indeed not need that. However, the new eSIM specification doesnt only apply to the eSIM and its security domains: the management servers are also in scope.
In my case I am referring to the SM-DP in the cert chain diagram below.
SM-DP(or SM-SR) is/are server(s) that are not (necessarily) related to the Card manufacturer (EUM) or any Operator. So we are not leveraging on any separate PKI/KI infra.
I do need to leverage on standard certs to do SSL auth based authentication between servers and got valid onesusing LetsEncrypt and its DNS based verification. Then I found out I also needed this other format of certificates (when the servers and the cards are establishing new keysets to be precise). That’s why I was trying to keep doing in the same direction and keep leveraging on LetsEncrypt to do so.
So I take it there is not API to get LetsEcrypt to just sign a String for me?
Since the cert verification on the card is done offline using the pre-loaded CI public key, I can do with Self Signed for now. And in the long run, I ll definitely have to use one of the CI approved by the GSMA so those will support this kind of request.
Nope, we wouldn't have any way to know if that string's contents were "true". As a result, we shouldn't attempt to certify to other people that they are.
What kind of Subject Identifiers do you have in your application, anyway? Are they in fact Internet domain names, or something else?
).
Would this kind of verification really be relevant to a SIM application? Don’t operators in this field operate some other kind of PKI that’s separate from the web PKI?