Ensure AIA URLs point to public paths

[cardonator]

As part of the SMIME work, I discovered at least one example of a cert that was issued using an outdated OCSP URL that would have been valid prior to the SMIME BRs. The rules around the AIA paths are not super strict but they are similar for both TLS and SMIME requirements, which read:

This extension MAY be present. If present, it MUST NOT be marked critical, and it MUST contain the
HTTP URL of the CA’s CRL service.

For publicly trusted certificates that are present in CT logs, these URLs are required to point to a resolvable location and shouldn't contain internal names. However, that requirement is not strictly codified in the requirements but is implied by what the resource is intended to point to. This lint intends to check and warn for this condition that may not be an actual problem, but probably is.

Note: I don't believe the Legacy lint is quite right here. The rule for Legacy reads

When provided, at least one accessMethod SHALL have the URI scheme HTTP. Other schemes (LDAP, FTP, ...) MAY be present.

The current lint tries to parse the url and make sure the DNS name has a valid TLD. Should I instead try to validate the scheme of the field before parsing in that lint only?

I also combined the Strict and Multipurpose lints into one as they have the same requirements.

Feedback welcome and desired!

[cardonator]

@christopher-henderson this is ready for review. I can't add you as a reviewer myself.

[christopher-henderson]

Thank you for the lints! Looks like a pretty straight forward change.

The current lint tries to parse the url and make sure the DNS name has a valid TLD. Should I instead try to validate the scheme of the field before parsing in that lint only?

I think we can let the URL parser do its thing as it will parse out the scheme for us. If there is no scheme, then that is a a problem in-and-of-itself that the parser will report to us (that is, other schemes are allowed however I doubt that not any scheme attached is okay).

[christopher-henderson]

...at least one accessMethod SHALL have the URI scheme HTTP

I reckon that we can also enforce this clause a bit more closely by checking up on the parse scheme

atLeastOneHttp := false
...
...
if purl.Scheme == "http" {
   atLeastOneHttp = true
}
...
...
if !atLeastOneHttp {
    return &lint.LintResult{Status: lint.Error}
}

[cardonator]

I implemented my take on this one, but I became unsure about it so if you can take a look that would be helpful. Gist is, in the requirement is mentions that at least one accessMethod MUST be http, however I believe it applies independently to the OCSPServers and IssuingCAs. If you think I'm being overly aggressive here, let me know.

[christopher-henderson]

hrmmm I think that my only thought is that this would also require that there be a minimum of one at least OCSP and at least one CRL (that is, if the loop never enters then atLeastOnHttp will be false).

Regardless, if there is such a requirement (at least one OCSP and at least one CRL) then it should be a separate lint (trying to encode all surrounding facts into each lint is how they commonly end up in deadlock).

So I guess we could just check the empty condition before failing out.

	if !atLeastOneHttp && len(c.OCSPServer) != 0 {
		return &lint.LintResult{Status: lint.Error, Details: "at least one accessMethod MUST have the URI scheme HTTP"}
	}

[cardonator]

Okay, I agree and made that change. Do you assume that the same change is not needed for the IssuingCertificateURL list?

[christopher-henderson]

If you extend this small change to CRLs as well then I think we'd be gtg on these!

[cardonator]

done

[cardonator]

Thanks for the review @christopher-henderson I had one question above but otherwise should be ready to re-review. 👍

e: I confirmed internally that I shouldn't have allowed https.