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 longe
> 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 cont
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
> 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 threa
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 error
> 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 the
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
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
> >
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.
>
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
> multi
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" format
11 matches
Mail list logo
