Hi Jeremy. Comments inline... On 14/12/2018 02:23, Jeremy Rowley via dev-security-policy wrote: <snip> > Here’s the breakdown: > > FATAL: x509: RSA modulus is not a positive number > > Bad reading of the BRs. The BRs say the range should be between 2^16+1 and > 2^256-1. The team implementing this thought saw SHOULD and thought it was > optional. They missed the sentence before which says the public exponent MUST > be equal to 3 or more. I’ll file and incident report on this.
No, you've misunderstood the error message. You're talking about the requirements for the public exponent, but this lint issue refers to the RSA modulus. The modulus (n) is the product of two prime numbers (p and q). AIUI, it's not possible for a prime number to be negative, so n=p*q will always be positive. > FATAL: asn1: structure error: integer not minimally-encoded > > I think this one is a false positive? It’s caused by padded zeros which > aren’t expressly prohibited. Want us to revoke these? No, this isn't a false positive. The ASN.1 Distinguished Encoding Rules (DER) expressly prohibit this. Quoting from X.690 12/97: "8.3 Encoding of an integer value ... 8.3.2 If the contents octets of an integer value encoding consist of more than one octet, then the bits of the first octet and bit 8 of the second octet: a) shall not all be ones; and b) shall not all be zero. NOTE – These rules ensure that an integer value is always encoded in the smallest possible number of octets." The public exponent (65537) in https://crt.sh/?asn1=628933973 is encoded as 02 04 00 01 00 01 (02=INTEGER, 04=length in bytes), whereas the only valid encoding is 02 03 01 00 01. > ERROR: The common name field in subscriber certificates must include only > names from the SAN extension > > This one is a false positive Yes, I think so. This must've been due to cached linting results, generated by an old linter version. It's impractical to re-lint every cert known to crt.sh every time a linter is updated. But to facilitate this particular discussion, I've relinted all of the certs issued by https://crt.sh/?caid=1191 for which lint issues had previously been identified. > ERROR: DNSNames must have a valid TLD > > This is a false positive Yes, except for https://crt.sh/?id=845405886&opt=zlint, which has been discussed previously: https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg10727.html https://bugzilla.mozilla.org/show_bug.cgi?id=1500621 <snip> > ERROR: CAs MUST NOT issue subscriber certificates with validity periods > longer than 39 months regardless of circumstance. > > False positive How long is a month? It could be argued that this cert's validity period is 39 months + 12 hours: https://crt.sh/?id=282328562&opt=zlint,x509lint,cablint Thankfully the BRs now define maximum validity periods in terms of days rather than months. <snip> > ERROR: Subject name fields must not contain '.','-',' ' or any other > indication that the field has been omitted > > False positive. The BRs say “All other optional attributes, when present > within the subject field, MUST contain information that has been verified by > the CA. Optional attributes MUST NOT contain metadata such as ‘.’, ‘-‘, and ‘ > ‘ (i.e. space) characters, and/or any other indication that the value is > absent, incomplete, or not applicable.” With the strict wording policy that > seems in effect, organizationalUnit is not “All other optional attributes”. > It’s a defined attribute and thus cannot be “other”. You're right that Subject:organizationalUnitName doesn't fall under "All other optional attributes". However, the second sentence begins "Optional attributes...". The "other" qualifier is not there, and since Subject:organizationalUnitName is an optional attribute, it is in scope for the "MUST NOT contain metadata" requirement. > ERROR: Explicit text has a maximum size of 200 characters > > False positive I think…. Yes, this appears to be a bug in ZLint. The User Notice string in https://crt.sh/?id=289322499&opt=zlint is 169 characters long. It's a BMPString, so each character is encoded in 2 octets. Presumably ZLint is counting the number of bytes instead of the number of characters. Note the x509lint warning "explicitText is not using a UTF8String" though, which stems from RFC5280 forbidding the use of BMPString in this context: "Conforming CAs SHOULD use the UTF8String encoding for explicitText, but MAY use IA5String. Conforming CAs MUST NOT encode explicitText as VisibleString or BMPString." RFC6818 un-forbids it, but AFAICT the BRs don't recognize RFC6818. <snip> -- Rob Stradling Senior Research & Development Scientist Sectigo Limited _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
