On Thu, Apr 4, 2019 at 1:50 PM Brian Smith <[email protected]> wrote:
> Ryan Sleevi wrote: > >> Given that CAs have struggled with the relevant encodings, both for the >> signatureAlgorithm and the subjectPublicKeyInfo field, I’m curious if >> you’d >> be open to instead enumerating the allowed (canonical) encodings for both. >> This would address open Mozilla Problematic Practices as well - namely, >> the >> encoding of NULL parameters with respect to certain signature algorithms. >> > > I would be happy with that approach if it makes our requirements clearer - I'm just not convinced that doing so will eliminate the confusion I attempted to describe. I agree with Ryan. It would be much better to list more precisely what > algorithm combinations are allowed, and how exactly they should be encoded. > From my experience in implementing webpki [1], knowing the exact allowed > encodings makes it much easier to write software that deals with > certificates and also makes it easier to validate that certificates conform > to the requirements. > > These kinds of details are things that CAs need to delegate to their > technical staff for enforcement, and IMO it would make more sense to ask a > programmer in this space to draft the requirements, and then have other > programmers verify the requirements are accurate. In particular, it is > hugely inefficient for non-programmers to try to attempt to draft these > technical requirements and then ask programmers and others to check them > because it's unreasonable to expect people who are not programmers to be > able to see which details are important and which aren't. > > Agreed - is someone willing to take on this task? You can find all the encodings of the algorithm identifiers at [2]. > > [1] https://github.com/briansmith/webpki > [2] https://github.com/briansmith/webpki/tree/master/src/data > > Cheers, > Brian > -- > https://briansmith.org/ > > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
