On Sun, Sep 25, 2016 at 5:49 PM Adam Langley <[email protected]> wrote:
> On Sun, Sep 25, 2016 at 2:35 PM, Henrick Hellström <[email protected]> > 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 [email protected] https://www.ietf.org/mailman/listinfo/tls
