Re: [TLS] BoringSSL's TLS test suite

On 2016-09-26 02:02, Jim Schaad wrote: OPTIONAL and DEFAULT are not the same things. A DEFAULT value is omitted but not an OPTIONAL value. A single field cannot be both OPTIONAL and DEFAULT. My point was that "DEFAULT" is not the same as "default" either, but let's leave it there. You

Re: [TLS] BoringSSL's TLS test suite

> -Original Message- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Henrick Hellström > Sent: Sunday, September 25, 2016 4:35 PM > To: David Benjamin <david...@chromium.org>; Adam Langley > <a...@imperialviolet.org> > Cc: tls@ietf.org > Subjec

Re: [TLS] BoringSSL's TLS test suite

On 2016-09-26 01:29, Jim Schaad wrote: The ASN.1 module in RFC 5280 does not say anything about if the field is optional for any specific algorithm. The ASN.1 for algorithm identifier is AlgorithmIdentifier ::= SEQUENCE { algorithm OBJECT IDENTIFIER, parameters

Re: [TLS] BoringSSL's TLS test suite

On 2016-09-25 23:55, David Benjamin wrote: I believe we are also correct per spec. My interpretation of these documents is that the general AlgorithmIdentifier structure may or may not include parameters. However, whether a given parameter value or omitting parameters altogether is legal is a

Re: [TLS] BoringSSL's TLS test suite

On Sun, Sep 25, 2016 at 5:49 PM Adam Langley wrote: > On Sun, Sep 25, 2016 at 2:35 PM, Henrick Hellström > wrote: > > Then again, the ASN.1 module in > https://datatracker.ietf.org/doc/rfc5280/ > > says differently. Strictly speaking, RFC 3279 does

Re: [TLS] BoringSSL's TLS test suite

Have you noticed that BoringSSL seems to abort handshakes with an illegal_parameter alert, if the server certificate uses the standard compliant (albeit highly unusual) DER encoding of NULL OPTIONAL as the empty string, instead of the non-standard but ubiquitous 0x05 0x00 encoding? Is this