On Fri, Dec 20, 2019 at 6:16 AM Evangelos Karatsiolis via dev-security-policy <[email protected]> wrote:
> Dear all, > > I have a question about an issue regarding the new Mozilla Root Store > Policy. Would it be possible to help me? The question regards the > encoding of the parameters of the hash algorithm used in PSS. > > The policy states that the parameters of the hash algorithm must be > explicitly encoded as Null, e.g. for SHA384: > > "The encoded AlgorithmIdentifier MUST match the following hex-encoded > bytes: > > 304106092a864886f70d01010a3034a00f300d0609608648016503040202 > 0500a11c301a06092a864886f70d010108300d0609608648016503040202 > 0500a203020130" > > or > > "The AlgorithmIdentifier structures describing the hash functions in the > hashAlgorithm field and in the maskGenAlgorithm's parameter MUST > themselves include an explicit NULL in the parameter field, as specified > by RFC 4055, Section 6" > > However, https://tools.ietf.org/html/rfc4055#section-2.1 > states that > > "All implementations MUST accept both NULL and absent parameters as > legal and equivalent encodings." > > I believe that for PSS this policy is restrictive and propagates a > behaviour that is deprecated. (See on same Section:) > > "The correct encoding is to omit the parameters field;" > > CAs that conform to this statement, would not be compatible with the new > root policy. > > Also here https://tools.ietf.org/html/rfc4055#section-6: > > " -- When the following OIDs are used in an AlgorithmIdentifier the > -- parameters SHOULD be absent, but if the parameters are present, > -- they MUST be NULL." > > another hint is given that absent parameters is the desired behaviour. > > Would it be possible to take both encodings into account? The intent with this proposal was to explicitly select a canonical encoding, and the one chosen aligns with the historic (and, in the case of the ASN.1, the compiled) module specification However, it's important to note to not conflate sha1Identifier (which explicitly MUST be NULL) with id-sha1 (for which parameters are optional, but if present, MUST be NULL). In that same Section 2.1, it's noted: To be clear, the following algorithm identifiers are used when a NULL parameter MUST be present: Which aligns with this usage. > As far as I > can tell both encodings are correct and should be enlisted. Otherwise > conforming CAs that issue certificates with absent parameters for hash > in PSS (which seems to be the desired behaviour) would not be compatible. > The canonical usage is the explicit NULL, but other __new__ uses in an AlgorithmIdentifier (i.e. that don't use the HashAlgorithm or MaskGenAlgorithm types) can and should declare it as optional. Put differently, if something specifies/allows {id-sha1}, the parameters are optional (and if present, MUST be NULL), while specifying sha1Identifier as the AlgorithmIdentifier in the spec means algorithms MUST be present and MUST be NULL. Is there a situation where this causes issues? I'm aware that the PXE boot environment's TLS verifier did not implement the "must allow either", but I'm not aware of any other reported issues from the explicit inclusion. It does mean a potential of additional bytes (for the TLV for the NULL), but this also aligns with spec and implementation, and, perhaps importantly in practice even if not for spec purity grounds, aligns with the treatment afforded the RSA PKCS#1v1.5 algorithms ( sha224WithRSAEncryption through sha512WithRSAEncryption ). _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
