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. 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 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
