On Wed, Apr 24, 2019 at 10:02 AM Ryan Sleevi <r...@sleevi.com> wrote:
> > On Mon, Apr 22, 2019 at 6:20 PM Brian Smith <br...@briansmith.org> wrote: > >> There are three (that I can think of) sources of confusion: >> >> 1. Is there any requirement that the signature algorithm that is used to >> sign a certificate be correlated in any way to the algorithm of the public >> key of the signed certificate? AFAICT, the answer is "no." >> >> 2. What combinations of public key algorithm (RSA vs. ECDSA vs EdDSA), >> Curve (N/A vs. P-256 vs P-384 vs Ed25519), and digest algorithm (SHA-256, >> SHA-384, SHA-512) are allowed? This is quite difficult to get *precisely* >> right in natural language, but easy to get right with a list of encodings. >> >> 3. Given a particular combination of algorithm, curve, and digest >> algorithm, which encodings of that information are acceptable? For example, >> when a a NULL parameter required and when is it optional. Again, this is >> hard to get right in natural language, and again, listing the encodings >> makes this trivial to get exactly right. >> >> Agreed - is someone willing to take on this task? >>> >> >> I could transform what I did with webpki into some text. >> >> However, first I think it would be useful if somebody could check that >> the encodings that webpki expects actually match what certificates in >> Certificate Transparency are doing. For example, does every CA already >> encode a NULL parameter when one is required by RFC 4055 (which is included >> by reference from RFC 5280)? Are there any algorithm combinations in use >> that aren't in webpki's list? This is something I don't have time to >> thoroughly check. >> > > I agree with Brian here, unsurprisingly. Luckily, my colleague, David > Benjamin, had some time to do just what Brian proposes. > > The following pull request - https://github.com/mozilla/pkipolicy/pull/183 - > demonstrates an attempt to resolve those three questions highlighted by > Brian. > > Thank you David and Ryan! This appears to me to be a reasonable improvement to our policy. Brian: could I ask you to review the proposed change? > This does not, however, address the last part of what Brian proposes - > which is examining if, how many, and which CAs would fail to meet these > encoding requirements today, either in their roots, subordinates, or leaf > certificates. > > While I agree that this would be useful information, for the purpose of moving ahead with this policy change would it instead be reasonable to set an effective date and require certificates issued (notBefore) after that date to comply, putting the burden on CAs to verify their implementations rather than relying on someone else to do that work? While this includes RSA-PSS, it's worth noting that mozilla::pkix does not > support these certificates, and also worth noting that the current encoding > scheme is substantially more verbose than desirable. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
