> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Henrick Hellström
> Sent: Sunday, September 25, 2016 5:46 PM
> To: Jim Schaad ; 'David Benjamin'
> ; tls@ietf.org
> Subject: Re: [TLS] BoringSSL's TLS test suite
>
> On 201
On 2016-09-26 02:34, Jim Schaad wrote:
No, it appears that I messed this up. (: It should be required and not absent.
OK, but it is strange. There are older implementations that predate RFC
5912 by more than a decade that did omit NULL parameters. I know that
because I encountered them and h
> -Original Message-
> From: Henrick Hellström [mailto:henr...@streamsec.se]
> Sent: Sunday, September 25, 2016 4:42 PM
> To: Jim Schaad ; 'David Benjamin'
> ; tls@ietf.org
> Subject: Re: [TLS] BoringSSL's TLS test suite
>
> On 2016-09-26 01:29, Ji
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 were
> -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 ; Adam Langley
>
> Cc: tls@ietf.org
> Subject: Re: [TLS] BoringSSL's TLS test suite
>
> On
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
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 que
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Henrick Hellström
> Sent: Sunday, September 25, 2016 2:35 PM
> To: David Benjamin ; tls@ietf.org
> Subject: Re: [TLS] BoringSSL's TLS test suite
>
> On 2016-09-25 23:23, David Benjamin
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 not override the PKIX
> > specification when it
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 not override the PKIX
> specification when it comes to X.509 certificates; only for formats such as
> RSA PUBLI
On 2016-09-25 23:23, David Benjamin wrote:
Do you mean in RSA SubjectPublicKeyInfos? For those, such encodings are
not actually standards-compliant. Per RFC 3279, 2.3.1:
The rsaEncryption OID is intended to be used in the algorithm field
of a value of type AlgorithmIdentifier. The paramet
On 2016-09-25 23:19, Adam Langley wrote:
On Sun, Sep 25, 2016 at 2:06 PM, Henrick Hellström wrote:
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 OPTION
On Sun, Sep 25, 2016 at 2:06 PM, Henrick Hellström wrote:
> 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 t
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 jus
Hi folks,
BoringSSL has developed a test harness[1] that consists of a fork of Go’s
crypto/tls package (recently dubbed “BoGo" at the Berlin hackathon) plus a
test runner that allows BoGo to be run against the TLS stack under test.
BoGo can be configured to behave in a number of unexpected ways th
15 matches
Mail list logo
