Hi Gianfrancesco, I don't have any expertise of the actual protocol, but do have an opinion on the PHP surface design. I apologise if the below feels too much like bikeshedding...
On 24 June 2026 12:45:05 BST, Gianfrancesco Aurecchia <[email protected]> wrote: > Should the constructor also accept > OpenSSLCertificate/OpenSSLAsymmetricKey > objects in addition to PEM? I would say *instead of* a string. Accepting a string means the constructor has to document the expected format, produce appropriate parse errors, etc; accepting an object reduces that to a standard type check. And if the user already has an object, serialising it and then reparsing it is duplicated effort. In general, I would prefer a design which used "real" types throughout instead of strings and ints, except where performance is critical: > public const int HANDSHAKE_ERROR = -1; > public const int HANDSHAKE_CONTINUE = 0; > public const int HANDSHAKE_FINISHED = 1; These should be cases on an enum; probably unbacked, unless there's some reason applications need to work with these integer codes. > public function getFingerprint(?string $digestAlgo = null): string Perhaps the supported algorithms could be an enum as well, backed by string. > public function feed(string $datagram): int {} > public function pull(): ?string {} If $datagram has to be in a specific format, would a lightweight DtlsDatagram object be useful? Again, it would delegate the parsing/validation to a specific factory, and give flexibility for extra ways of creating or reusing material without going via strings and revalidating. > public function read(): string|false {} > public function exportKeys(string $label, int $length): >string|false {} If the false case here is an expected condition, like EOF, "?string" might be better. If it's just a signal for unexpected errors, throwing an exception would be better. Hopefully someone with more knowledge of the problem space can comment more on the core idea. Thanks, Rowan Tommins [IMSoP]
