sbernard31
commented
1 year ago Some thoughts about this :
Current Design:
Currently we have 1 class called Identity with these attributes :
public class Identity {
InetSocketAddress peerAddress;
String pskIdentity;
PublicKey rawPublicKey;
String x509CommonName;
OscoreIdentity oscoreIdentity;
...
}This idea of that class was to identified a Foreign Peer (Client or Server)
Current Drawbacks :
But there is maybe several issues with this design :
1) we see just above that's not alway a good idea to consider peerAddress as part of identity.
2) Adding new kind of identity means create new fields in the only 1 existing class ...
Some Concepts :
Here some similar concept in Java :
- https://docs.oracle.com/javase/7/docs/technotes/guides/security/jgss/tutorials/glossary.html
- https://stackoverflow.com/a/5025140/5088764
I'm not sure we should reuse those classes but we should maybe create a new class hierarchy to separate foreign peer and identity concepts ? About naming I don't know ?
- For Foreign Peer : Peer, LwM2mPeer ?
- For Identity : Identity LwM2mIdentity ?
Proposed Design :
I guess classes could looks like
public interface Peer {
Identity getIdentity()
}
public class IpPeer implements Peer { // This class is to anticipate Non-IP protocol
InetSocketAddress getSocketAddress()
Identity getIdentity()
}
public interface Identity {
String getKeyIdentifier() // TODO I don't know if we really need this.
String toString();
boolean equals(Object obj)
int hashCode();
}
public class SocketIdentity implements Identity {
InetSocketAddress getSocketAddress();
}
public class PskIdentity implements Identity {
String getIdentity();
}
public class RpkIdentity implements Identity {
PublicKey getPublicKey();
}
public class X509Identity implements Identity {
String getX509CommonName(); // when we will go futher we will probably see that current design is too limited.
}
public class OscoreIdentity implements Identity {
byte[] getRecipientId();
}OSCORE + TLS case :
Now there is one problem with this design ... OSCORE can be used togeter with (D)TLS protocol. So to support that either :
- we go with 1 Peer could have several Identities.
- OR we create and an OscoreOverTlsIdentity which looks like this
public class OscoreOverTlsIdentity implements Identity {
OscoreIdentity getOscoreIdentity();
Identity getTlsIdentity(); // we can create a TlsIdentity interface.
}@JaroslawLegierski, @jvermillard, @rikard-sics if you have any opinions / ideas about this, do not hesitate to share.
JaroslawLegierski
At #1421, we discover that we have maybe an issue with current
Identityclass/concept in Leshan.(from : https://github.com/eclipse/leshan/issues/1421#issuecomment-1473511816)
This issue aims to talk about a new design.
This will probably lead to some Redis Serialization break again :grimacing: (See https://github.com/eclipse/leshan/issues/1417)