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 were listed as a co-author on RTC 5912, so maybe you could clarify whether the declaration of pk-rsa should still be considered to be correct: pk-rsa PUBLIC-KEY ::= { IDENTIFIER rsaEncryption KEY RSAPublicKey PARAMS TYPE NULL ARE absent -- Private key format not in this module -- CERT-KEY-USAGE {digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyCertSign, cRLSign} } ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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 > Subject: 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 question for the > > particular algorithm. It's not overriding but plugging into the general > framework. > > THe ITU-T X.690 standard for DER might require some close reading to interpret, > and this is obviously a topic for debate. I would presume that the use of > "default" in lower caps in section 11.5, refers to both the DEFAULT and the > OPTIONAL keyword: 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. Jim > >11.5 Set and sequence components with default value >The encoding of a set value or sequence value shall not include an >encoding for any component value which is equal to its default value. > > After all, this is the only interpretation that is consistent with the description in > section 12.5 of DER as unambiguous. > > Since NULL is always empty, it should be omitted when OPTIONAL, given the > above interpretation. But is it optional? The 1988 syntax did not feature > information objects and classes, hence the use of the ANY keyword. > > Luckily the ASN.1 modules were updated in RFC 5912 to modern ASN.1 syntax. > There you have these declarations: > > -- SIGNATURE-ALGORITHM > -- > -- Describes the basic properties of a signature algorithm > -- > -- - contains the OID identifying the signature algorithm > -- - contains a type definition for the value structure of > -- the signature; if absent, implies that no ASN.1 > -- encoding is performed on the value > -- - if present, contains the type for the algorithm > -- parameters; if absent, implies no parameters > -- - parameter presence requirement > -- - The set of hash algorithms used with this > -- signature algorithm > -- - the set of public key algorithms for this > -- signature algorithm > -- - contains the object describing how the S/MIME > -- capabilities are presented. > -- > -- Example: > -- sig-RSA-PSS SIGNATURE-ALGORITHM ::= { > -- IDENTIFIER id-RSASSA-PSS > -- PARAMS TYPE RSASSA-PSS-params ARE required > -- HASHES { mda-sha1 | mda-md5, ... } > -- PUBLIC-KEYS { pk-rsa | pk-rsa-pss } > -- } > > > SIGNATURE-ALGORITHM ::= CLASS { > OBJECT IDENTIFIER UNIQUE, >OPTIONAL, > OPTIONAL, >ParamOptions DEFAULT absent, > DIGEST-ALGORITHM OPTIONAL, > PUBLIC-KEY OPTIONAL, >SMIME-CAPS OPTIONAL > } WITH SYNTAX { > IDENTIFIER > [VALUE ] > [PARAMS [TYPE ] ARE ] > [HASHES ] > [PUBLIC-KEYS ] > > AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::= > SEQUENCE { > algorithm ALGORITHM-TYPE.({AlgorithmSet}), > parameters ALGORITHM-TYPE. > ({AlgorithmSet}{@algorithm}) OPTIONAL > } > > pk-rsa PUBLIC-KEY ::= { > IDENTIFIER rsaEncryption > KEY RSAPublicKey > PARAMS TYPE NULL ARE absent > -- Private key format not in this module -- > CERT-KEY-USAGE {digitalSignature, nonRepudiation, > keyEncipherment, dataEncipherment, keyCertSign, cRLSign} > } > > Hence, the correct encoding is for NULL to be absent. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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 ANY DEFINED BY algorithm OPTIONAL This very explicitly says that the value (and hence presence) of the parameters fields is strictly defined by the algorithm identifier. The algorithm identifiers for RSA with the SHA2 algorithms explicitly say they are required. RFC 5912 shows that this is required with the way it defines the same information sa-sha256WithRSAEncryption SIGNATURE-ALGORITHM ::= { IDENTIFIER sha256WithRSAEncryption PARAMS TYPE NULL ARE required HASHES { mda-sha256 } PUBLIC-KEYS { pk-rsa } SMIME-CAPS { IDENTIFIED BY sha256WithRSAEncryption } } You can see that the parameters are required and not optional. Thanks, you are absolutely correct about this, and this crucial for getting PKCS #1 v1.5 signatures right (since the algorithm identifier encoding is part of the data to be signed), but at the same time, NULL should be absent from the RSA public key: pk-rsa PUBLIC-KEY ::= { IDENTIFIER rsaEncryption KEY RSAPublicKey PARAMS TYPE NULL ARE absent -- Private key format not in this module -- CERT-KEY-USAGE {digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyCertSign, cRLSign} } and this is definitely not common practice. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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 question for the particular algorithm. It's not overriding but plugging into the general framework. THe ITU-T X.690 standard for DER might require some close reading to interpret, and this is obviously a topic for debate. I would presume that the use of "default" in lower caps in section 11.5, refers to both the DEFAULT and the OPTIONAL keyword: 11.5 Set and sequence components with default value The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to its default value. After all, this is the only interpretation that is consistent with the description in section 12.5 of DER as unambiguous. Since NULL is always empty, it should be omitted when OPTIONAL, given the above interpretation. But is it optional? The 1988 syntax did not feature information objects and classes, hence the use of the ANY keyword. Luckily the ASN.1 modules were updated in RFC 5912 to modern ASN.1 syntax. There you have these declarations: -- SIGNATURE-ALGORITHM -- -- Describes the basic properties of a signature algorithm -- -- - contains the OID identifying the signature algorithm -- - contains a type definition for the value structure of -- the signature; if absent, implies that no ASN.1 -- encoding is performed on the value -- - if present, contains the type for the algorithm -- parameters; if absent, implies no parameters -- - parameter presence requirement -- - The set of hash algorithms used with this -- signature algorithm -- - the set of public key algorithms for this -- signature algorithm -- - contains the object describing how the S/MIME -- capabilities are presented. -- -- Example: -- sig-RSA-PSS SIGNATURE-ALGORITHM ::= { -- IDENTIFIER id-RSASSA-PSS -- PARAMS TYPE RSASSA-PSS-params ARE required -- HASHES { mda-sha1 | mda-md5, ... } -- PUBLIC-KEYS { pk-rsa | pk-rsa-pss } -- } SIGNATURE-ALGORITHM ::= CLASS { OBJECT IDENTIFIER UNIQUE, OPTIONAL, OPTIONAL, ParamOptions DEFAULT absent, DIGEST-ALGORITHM OPTIONAL, PUBLIC-KEY OPTIONAL, SMIME-CAPS OPTIONAL } WITH SYNTAX { IDENTIFIER [VALUE ] [PARAMS [TYPE ] ARE ] [HASHES ] [PUBLIC-KEYS ] AlgorithmIdentifier{ALGORITHM-TYPE, ALGORITHM-TYPE:AlgorithmSet} ::= SEQUENCE { algorithm ALGORITHM-TYPE.({AlgorithmSet}), parameters ALGORITHM-TYPE. ({AlgorithmSet}{@algorithm}) OPTIONAL } pk-rsa PUBLIC-KEY ::= { IDENTIFIER rsaEncryption KEY RSAPublicKey PARAMS TYPE NULL ARE absent -- Private key format not in this module -- CERT-KEY-USAGE {digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyCertSign, cRLSign} } Hence, the correct encoding is for NULL to be absent. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] BoringSSL's TLS test suite
On Sun, Sep 25, 2016 at 5:49 PM Adam Langleywrote: > 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 PUBLIC KEY that rely solely on the ASN.1 module in RFC 3279. > > To answer your original question then, this is intentional. > > While there are certainly differences of opinion about the > applicability of Postel's law in this space, in practical terms > requiring a NULL in this location empirically has very good > compatibility and we don't like adding flexibility without good > reason. > 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 question for the particular algorithm. It's not overriding but plugging into the general framework. Specifications for individual algorithm OIDs say what to put in the parameters field: For id-rsaEncryption, RFC 3279 (previously cited) says it is not optional and the only legal value is NULL. https://tools.ietf.org/html/rfc3279#section-2.3.1 For id-RSASSAS-PSS, RFC 4055 says the parameters are not optional and specifies the structure. https://tools.ietf.org/html/rfc4055#section-3.1 For id-ecPublicKey, RFC 5480 says something similar and gives the structure. https://tools.ietf.org/html/rfc5480#section-2.1.1 For id-dsa, RFC 3279 says they are actually optional. (Although this was a pretty bad idea since it's used in this bizarre parameter inheritance thing...) https://tools.ietf.org/html/rfc3279#section-2.3.2 None of these can be talking about standalone structures like RSAPublicKey. Those structures usually don't even include AlgorithmIdentifiers (no need when you already know the key type) and are usually specified in other documents like RFC 3447. David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
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 just a regression bug in BoringSSL, or is it an intentional restriction of the TLS protocol that should be propagated to other implementations as well? On 2016-08-16 20:08, David Benjamin wrote: 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 that violate the TLS standard, thus enabling the testing of many scenarios that would be otherwise difficult to obtain with a standard stack. We (David Benjamin and Eric Rescorla) have been getting it to work with NSS and wanted to let others know in case they might find it useful. This system was initially designed to work with BoringSSL, but in principle can be used with any stack. The portability is still a little rough, and we'll likely make changes as we get more experience here, but it has already been used to test NSS[2] and OpenSSL[3]. We've written up some notes at [4]. The test suite should be fairly extensive for DTLS and TLS 1.2 (giving around 75% line coverage in BoringSSL’s TLS code at last count). It tests TLS 1.3 as well, though those tests are still in progress. They track BoringSSL’s in-progress TLS 1.3 implementation. David and Eric [1] https://boringssl.googlesource.com/boringssl/+/master/ssl/test/ [2] https://hg.mozilla.org/projects/nss/file/tip/external_tests/nss_bogo_shim [3] https://github.com/google/openssl-tests [4] https://boringssl.googlesource.com/boringssl/+/master/ssl/test/PORTING.md ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls