|
| Re: rpk without certificate [message #1855006 is a reply to message #1854996] |
Fri, 23 September 2022 06:43  |
 Achim Kraus
Messages: 6
Registered: August 2021 |
Junior Member |
|
|
> is it posible to use multiple rpk without certificate?
That depends on where you want to use it.
Just a remark about the terms: Raw Public Key rfc7250 uses also certificates.
It's not a x509 certificate, it leaves a out the valid date range and it's has no signature from a CA, but it may be also seen as a x509 reduced to the public key.
Therefore the most stuff for "certificates" in Californium support also RPK.
> When we wanted to use that credentials we noticed the framework needs using of a keystore (java.security)
No, the java KeyStore is just one provider.
> Is there another way to add multiple rpk without a keystore?
You may use any other provider by implementing the CertificateProvider and/or NewAdvancedCertificateVerifier. The implementations in org.eclipse.californium.scandium.dtls.x509 may be used as example.
See also CertificateIdentityResult and CertificateVerificationResult for the usage of RawPublikKey
The StaticNewAdvancedCertificateVerifier should be easy to use to trust multiple rpks of other peers.
If you want to use multiple rpks for authentication of the peer itself, the question would be, which one of the multiple rpks should be used for a specific other peer?
If you know that, just implement a CertificateProvider, which keeps multiple rpks and returns the right one for the specific other peer.
CertificateIdentityResult requestCertificateIdentity(ConnectionId cid, boolean client, List<X500Principal> issuers,
ServerNames serverNames, List<CertificateKeyAlgorithm> certificateKeyAlgorithms,
List<SignatureAndHashAlgorithm> signatureAndHashAlgorithms, List<SupportedGroup> curves);
The cid is to correlate the requestCertificateIdentity with the CertificateIdentityResult, just copy it into the result.
For rpk, the issuers will be empty. The server names are not directly usable. for x509 such names are commonly used as (alt.) subject of the certificate.
The other parameters are mainly useful, if you want to use e.g. ECC secp256r1 and ED25519 both on the server. The server may then be able to chose
the right one for the client according the parameters in the ClientHello.
SumUp:
The API makes it possible, but it may require detailed knowledge about the related RFCs.
|
|
|
Powered by
FUDForum. Page generated in 0.03585 seconds
] 
Search
Help
Register
Login
Home
