Am Dienstag, 14. Januar 2020 16:38:07 UTC+1 schrieb Ryan Sleevi:
> On Tue, Jan 14, 2020 at 5:46 AM ekaratsiolis--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > > 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 ).
> >
> >
> > Hello Ryan,
> >
> > we did not have an issue on the client side, but rather on the server (CA)
> > side. In our CA software we did not encode the NULL parameters but left it
> > empty. Therefore the AlgorithmIdentifier contained only the OID. I believe
> > this is the desired behaviour by the standard, because of the two following
> > statements of RFC 4055:
> >
> > 1. The correct encoding is to omit the parameters field;
> > 2. When the following OIDs (note: SHA-1/2 OIDs follow) are used in an
> > AlgorithmIdentifier the parameters SHOULD be absent, but if the parameters
> > are present, they MUST be NULL.
> >
> > The canonical representation for PSS lists the NULL in the parameters so
> > this is the way we should treat it.
> >
>
> I think this disagreement is exactly why it's necessary to be quite precise
> via policy, and to reduce the complexity for consumers. I don't disagree
> with you that flexibility is desired for new work, but we seem to disagree
> on whether that flexibility is retroactively granted, especially when such
> stuff is codified in implementation.
>
> It should not be necessary, for example, to parse ASN.1 during signature
> verification - doing so leads to all sorts of terrible issues (
> https://www.imperialviolet.org/2014/09/26/pkcs1.html for one affecting
> NSS. )
>
> The ASN.1 module introduces the HashAlgorithm / MaskGenAlgorithm aliases
> for a purpose - despite being AlgorithmIdentifiers, they serve to
> semantically distinguish the type so that the clause you're quoting is not
> meant to apply, because it's id-sha1 within a HashAlgorithm, not id-sha1
> within an AlgorithmIdentifier. I can understand the confusion ("But a
> HashAlgorithm is derived from AlgorithmIdentifier"), but the point was to
> split out the historic use in extant and previous specs and to provide
> clear guidance for new uses of those OIDs for new specs.
>
> You can see this in the subsequent ASN.1 modules related to this (e.g. RFC
> 5912, which keeps SHOULD be present, and thus encoded). While I dislike
> arguing for or against 'authorial intent', especially because spec authors
> are humans who are flawed and make mistakes. Hopefully the intent part
> above of the policy change is clearer. In the extant set of certificates
> surveyed (i.e. those from the CAs trusted by Microsoft, Apple, Google,
> Mozilla, 360), no such certificates demonstrated this issue. So it only
> applies as new certificates go forward, and provides unambiguous certainty
> - beneficial when compared to our disagreement about the spec language :)
>
> It seems the core concern is:
> 1) Does the Policy need to pick just one?
> A) The explicit goal of the policy was to pick exactly one and only one
> encoding
> 2) Which one do we pick?
> A) The choice was based on several factors: existing encoding behaviours
> for several libraries, the alignment with historic specs (for which they
> were unambiguously mandatory), alignment with CAs' expectations along the
> other RSA family of algorithms, alignment with modern specs by changing
> SHOULDs into MUSTs as part of profiling down the Web PKI to a further
> sensible subset (e.g. the SHOULD from RFC 5912)
>
> Hopefully that explains the reasoning behind it, and the objective. My big
> concern would be trying to support two (or, given the permutation, four)
> possible encodings for RSA-PSS. RSA-PSS's approach, at least in the Web
> PKI, is very much an anti-pattern for design, in that its design is
> intended to offer infinite flexibility for PKI designers, while the Web PKI
> very much benefits from a happy, narrow path, with only One True Way.
Hi Ryan,
the uniquely specified encoding is plausible, compatible with the RFC4055 and
narrows down stuff significantly. This will work fine for us and I guess for
other CAs, too.
Best,
Vangelis
PS. A lint to check correctness of the encoding of the PSS parameters could be
a nice addition to the zlint (https://github.com/zmap/zlint) project.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
