> -----Original Message-----
> From: TLS [mailto:[email protected]] On Behalf Of Henrick Hellström
> Sent: Sunday, September 25, 2016 2:35 PM
> To: David Benjamin <[email protected]>; [email protected]
> Subject: Re: [TLS] BoringSSL's TLS test suite
>
> 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 parameters field MUST
> > have ASN.1 type NULL for this algorithm identifier.
> >
> > https://tools.ietf.org/html/rfc3279#section-2.3.1
>
> 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.
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.
Jim
>
>
> > There are other contexts where (due to historical mistakes) specs
> > declared both are acceptable, but amazingly not RSA SPKIs. BoringSSL
> > has enforced it for quite some time now, so it seems this part of the
> > specification matches reality. If I recall, mozilla::pkix enforces
> > this as well?
>
> Actually no, just tested Chrome v53 and Firefox v49 for the Windows
platform.
> Only Chrome fails when connecting to a server that presents a server
certificate
> with the NULL parameters omitted from the DER encoding.
>
> _______________________________________________
> TLS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
