Re: [openssl-users] Shutdown details

On 8/13/2018 11:25 AM, Viktor Dukhovni wrote: >> On Aug 13, 2018, at 2:13 PM, Jordan Brown >> wrote: >> >> I'm curious: how did this ever work for HTTPS, where for a POST request you >> have to see the end of the request body before you can (in general) send the >> response? > This is no

Re: [openssl-users] Shutdown details

> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf > Of Viktor Dukhovni > > HTTP has a "Content-Length:" header or alternatively supports Chunked > transfers. For HTTP/1.1, RFC 2616 also allows the message body length to be determined by the use of the self-delimiting

Re: [openssl-users] Shutdown details

I don't mind upwinding it. These different reactions and input only help me design my things better. Very pleased with the discussion so far. Den mån 13 aug. 2018 20:26Viktor Dukhovni skrev: > > > > On Aug 13, 2018, at 2:13 PM, Jordan Brown > wrote: > > > > I'm curious: how did this ever work

Re: [openssl-users] Shutdown details

> On Aug 13, 2018, at 2:13 PM, Jordan Brown > wrote: > > I'm curious: how did this ever work for HTTPS, where for a POST request you > have to see the end of the request body before you can (in general) send the > response? This is no longer OpenSSL-specific. Best to wind down this

Re: [openssl-users] Shutdown details

On 8/12/2018 12:59 PM, Viktor Dukhovni wrote: > Which is a change from previously required behaviour: > >https://tools.ietf.org/html/rfc8446#section-6.1 > >Each party MUST send a "close_notify" alert before closing its write >side of the connection, unless it has already sent some

Re: [openssl-users] Possible bug in 1.1.1-pre8 with NSTs and PSK in initial ClientHello handshake

> On Aug 13, 2018, at 1:00 PM, Henderson, Karl via openssl-users > wrote: > > According to RFC8446, Section C.4 “Servers SHOULD issue new tickets with > every connection”. > > Yet, in file ssl/statem/extensions_srvr.c, method tls_parse_ctos_psk, > s->ext.ticket_expected = 0, preventing

[openssl-users] Possible bug in 1.1.1-pre8 with NSTs and PSK in initial ClientHello handshake

According to RFC8446, Section C.4 “Servers SHOULD issue new tickets with every connection”. Yet, in file ssl/statem/extensions_srvr.c, method tls_parse_ctos_psk, s->ext.ticket_expected = 0, preventing the NST from being sent. This appears to be a bug – or am I missing something? Thanks, Karl

Re: [openssl-users] rsaOAEP OID in X509 certificate

On Thursday, 9 August 2018 22:01:25 CEST Viktor Dukhovni wrote: > > On Aug 9, 2018, at 3:21 PM, Stephane van Hardeveld > > wrote: > > > > The certificate is signed with PSS. However, I try to indicate that the > > public key enclosed IN the certificate should be used with the OAEP > > padding >

Re: [openssl-users] Shutdown details

On 12/08/18 20:59, Viktor Dukhovni wrote: > > >> On Aug 12, 2018, at 2:49 PM, Kurt Roeckx wrote: >> >> TLS 1.3 makes it explicit that after you've send a close_notify, >> the peer is still allowed to send data, so you can still read >> data. It only closes the connection in one direction. >

Re: [openssl-users] Multi client DTLS server on OpenSSL 1.1.x broken?

Please could you raise this as a github issue? I'll try and take a look at it (although it may be a while since my current focus is on the 1.1.1 release). Matt On 11/08/18 16:22, Richard Weinberger wrote: > Hi! > > I have a hard time figuring how to write a DTLS UDP server that supports >

Re: [openssl-users] EDDSA key format

On 10/08/18 23:43, Felipe Gasper wrote: > Hi all, > > Do EDDSA keys serialize to any format other than SPKI (public) and > PKCS8 (private)? > > I ask because RSA and ECC both have “native” formats as well as SPKI > and PKCS8. > > Thanks! > No, there are no "native"