I was sent a private key in plain text form to be used to Encrypt/Decrypt SAML2P request and response messages. However the routine that I'm using require an X.509 certificate. How do I store the private key in an X.509 certificate so that it may encrypt and decrypt the message.
Related
I have a JWT implementation which accessed by multiple clients. In the sense multiple client are sending me JWT token and they are creating the JWT token using the RSA public key I have shared among them. And I am decoding the JWT token using the RSA private key.
But now due to few security reasons I need to send them different public keys and will get the JWT token and I will decode it using one private key I have.
In short how I will generate multiple public keys and single private keys or any similar approach.
(...) send them different public keys and (...) decode it using one private key I have.
As far as I know a RSA private key can only have one public key.
But now due to few security reasons I need to send them different public keys (...)
Are they still "public" if you have to send different public key to each client ?
If I well understand your issue, I would recommend to switch for a PKI with certificates (like X.509) where you are the authority.
The flow would be:
The client generate a private key
The client create a CSR
The client send you the CSR
You generate a cert with your CA base on the CSR
You send back the CRT
The client use its private key to sign the JWT
The client send you the JWT
You check it with your CA
With this solution, you'll get all benefits of client certificate authentication.
If at some point you're not trusting anymore a client you can use a revocation list.
Btw, I never saw this kind of flow... and since I don't know what's you exactly want to achieve, you should read this as an answer of "How can I implement client certificate authentication with JWT ?"
They should each have their own private signing key. They sign the JWT. They then encrypt the JWT with your public key/cert.
You decrypt the jwt with your private key. You then validate the signature of each party using their public key/cert.
This way the JWT is encrypted and only you can access it. It is signed so you can verify the sender
I'd like to create a X.509 public key certificate to verify signatures, esp. JWT Tokens.
I'd like to know which properties and extensions properties to set to which values on the certificate to restrict it for JWT verification.
Unfortunately, the specification of X.509 extensions is pretty verbose. So, I'd also be very thankful for a brief overview of available X.509 extensions, properties and their meaning.
JWT signing and validation with asymmetric keys is done using exclusively a key pair, not certificates. It is only needed a public key to validate the token signature.
The public key can be contained in a certificate in order to be sent to the verification party, but this is not really needed, and the recipient is not obliged to perform the validation with respect to any attribute or extension that the X509 certificate may have.
The type of certificate extensions you need to enforce such restriction is... Key Usage and/or Extended Key Usage extensions. For any kind of digital signature, you need at least the Key Usage called... digitalSignature, as specified in RFC 5280. Standard (Extended) Key Usage extensions are all specified in ยง 4.2.1.3 and 4.2.1.12 of the RFC.
You can always avoid certificates for the sake of simplicity, by maintaining a truststore (a static list) of public keys (or fingerprints if you want to optimize memory/disk usage) on the JWT verifier's side. But this has some limitations, such as:
No standard revocation mechanism: if the signing key has been compromised, how does the verifier become aware of that? With certificates, you have the possibility to revoke certificates, and verifiers use standard OCSP or CRL to verify the revocation status.
You have to know in advance all public keys potentially used for JWT signing. This is not always the case. (E.g. in some cases, all you want to know as a verifier is that the key belongs to some trusted organisation's entity and that it has been allowed for signing.)
If the list of public keys is/becomes too big, it is hardly manageable.
If the keys change too often (remember that keys should be renewed regularly), it is hardly manageable.
Therefore, if such limitations affect you, X.509 certificates offer a more scalable and flexible solution, but with an extra layer of complexity of course. With certificates, it works like this:
Each JWT issuer has a certificate issued by one or more Certificate Authorities (CA)
JWT verifiers should trust these CAs (list of trusted CAs), instead of trusting each JWT issuer's certificate specifically.
JWT include the signer's certificate (or certificate chain if you use sub-CAs) in the x5c header parameter of the JWS header as per RFC 7515 (X.509 Certificate Chain), so that the verifier can link the certificate (chain) to one of the trusted CAs.
I would like to understand how e-mail encryption works.
If I want to store my already sent encrypted e-mails, are they encrypted by my public key or private key? And which key is used to sign those messages?
You are talking about Public-key cryptography, it does not depend on where you use it: email or files and etc.
Public key is used for encrypt messages. Private for decrypt and sign messages.
I'm trying to better understand JWT and how to properly use it.
In common JWT use cases (like JWT-based authentication or JWT access token in oauth), does it make sense to verify a JWT token client-side? In particular, I'm asking this to better understand the requirements on the public and private keys that are involved in the JWT signing and encryption. If the clients never need to verify the JWT signature than the server does not need to make its public key available. If this is true, I don't even need a full blown X.509 certificate: a bare public/private key pair or a self signed cert would suffice, right?
So all this boils down to the question: what is the right way to deal with asymmetric keys used in JWT? Do I need a public key infrastructure or is a simple private/public key pair enough?
I understand that JWT specs do not cover this: yet I'm curious to know what the common practices are in real JWT usage.
Of course this question has nothing to do with the certs involved in https: I'm just talking about the keys used in JWT signature and encryption.
does it make sense to verify a JWT token client-side?
It makes sense if you use the token payload data to perform an operation in client side, and you need to trust the token. If you use the token for authenticate in a server, then let the server verify the signature.
if this is true, I don't even need a full blown X.509 certificate: a bare public/private key pair or a self signed cert would suffice, right?
Do I need a public key infrastructure or is a simple private/public key pair enough?
You can use either a trusted certificate, a self-signed certificate or simply a RSA keypair. Usually is used an autogenerated keypair. But if you do not plan to verify the signature on client, you can just use a HMAC symmetric key (not assymetric
I created a token with the private key by JWT, but when I try to decode it on http://kjur.github.io/jsjws/tool_jwt.html, I found that the token can be decoded without any key given. So is it correct that the JWT token is just a signing? How to keep the token from decoded without the key?
There are two ways in which a public/private keys can be used by a JWT: signing and encryption.
If you use a private key for signing, it allows for the recipient to identify the sender of the JWT and the integrity of the message but not to hide its contents from others (confidentiality). Note that it would be the sender's private key that is used to sign the JWT and produce a JSON Web Signature (JWS) object. Apparently that applies to the JWT that you're looking at.
When using a public key for encryption it can be used to hide content from anyone but the intended recipient. The result is a JSON Web Encryption object. Note that it would be the public key of the recipient that is used to encrypt the JWT. Apparently that is what you're looking for.
See: http://jose.readthedocs.org/en/latest/