> Wanted: more
> ciphers, support for user certificates, support for certificate
> verification. ECDSA! ECDHE!"
client certs, client side DHE and ECDHE already done in 9front, just
take it :)
--
cinap
On 2 July 2015 at 17:44, Skip Tavakkolian
wrote:
> isn't it settled that keeping of secrets and exchange thereof are the
> domain of factotum?
I hope so.
isn't it settled that keeping of secrets and exchange thereof are the
domain of factotum?
On Thu, Jul 2, 2015 at 6:14 AM, Charles Forsyth
wrote:
> I hadn't looked at the "bounties" page recently. It includes
>
> "improve the tls(3) device $10 - The TLS device implements the record
> layer proto
> I think that I'd avoid putting the negotiation and certificate stuff (as
> such) in the kernel device.
Speaking as an amateur, I'd be tempted to investigate pushing the Plan
9 paradigm further and see how hard it would be to fragment the kernel
into asymmetric portions. To be more specific, som
I hadn't looked at the "bounties" page recently. It includes
"improve the tls(3) device $10 - The TLS device implements the record layer
protocols of Transport Layer Security version 1.0 and Secure Sockets Layer
version 3.0. It does not implement the handshake protocols, which are
responsible for
On 2 July 2015 at 13:30, Anthony Sorace wrote:
> The p9sk1 *model* is great, and it'd be a real shame to drop it.
There always seems to be trouble setting it up, which suggests that the
documentation people typically first see might need revising
(or better pointers if it exists but people don'
Personally, I think two separate things are called for.
1) A straight-forward update to use AES
2) Some public key system.
The p9sk1 *model* is great, and it'd be a real shame to drop it. Doing the
upgrade and teaching should be easy, although there's tedious work in telling
all the things to s
I think just replacing des keys with AES is not worth it. there is so little
data that des is quite secure (imho).
replacing p9sk1 with pki is much more useful. rus posted to 9fans about wanting
to do this so a terminal could cache tickets to speed auth when the auth server
is remote - I cannot
