refactor of SMIME aia contains

[mtgag]

the effective date of this lint has been updated and in checkApplies a check to see whether the extension is present has been added.

Also, another proposal would be to break this lint into two lints. One that is checking whether the scheme is HTTP and produces either error or pass and a second lint that is checking the internal names and produces either warn or pass. I believe that most lints try to focus on one aspect and not to lint many aspects in one lint. I would be willing to contribute on this.

Best,

Vangelis

[cardonator]

Separating the scheme check to a separate lint does seem appropriate. There are several lints for AIA checking that have a similar structure so we will want to make sure they all have consistent behavior.

[mtgag]

I did not find any text in the SMIME CABF Specifications which deals with internal names in AIA/OCSP. I propose to remove this part in the lint and the smime package and if this is a requirement from another specification, implement it as a new lint in the corresponding package. This proposal is implemented in commit https://github.com/zmap/zlint/pull/777/commits/a1eee503e9c2219408699bab3ed8cb98b015032a

[cardonator]

I'll disagree with that one. I don't think a requirement is spelled out in any of the BRs, however the ocsp has to be publicly accessible as does the aia. Is there a use case you're thinking of where an internal name would or should be allowed? Pinging @CBonnell for visibility.

[CBonnell]

I agree with @cardonator. While the S/MIME BRs do not explicitly state that the URIs contained within the CRLDP and AIA extensions must be publicly accessible, the language cannot reasonably be interpreted as allowing the inclusion of such internal domain names.

If one reads the current language in the SMBRs as permitting internal domain names in CRLDP and AIA extensions, then one would also interpret the SMBRs as allowing the issuance of publicly trusted S/MIME certificates that have no publicly available revocation information.

More generally, the inclusion of such internal domain names is of no use (and actively harmful due to connection attempts that will inevitably fail) in the common case, as the referenced resources cannot be accessed by most Relying Parties.

[mtgag]

The motivation to remove the check about internal names was to keep different aspects of lints separated and left the removed part to future work.

Commit https://github.com/zmap/zlint/pull/777/commits/2a6b8870db1235774d8b869f960955a7299cdc90 tries to address the issues discussed in this PR. On the one hand two distinct lints exist to keep a narrow focus on each lint, and on the other hand the check for internal names is extended to all SMIME certificates. I hope that the current proposal and implementation reflects the discussion.

[timfromdigicert]

A future browser alignment ballot might help here, as it is my opinion is that a non-public OCSP or CRL server for public S/MIME would violate Mozilla policy:

"CA operators MUST NOT issue certificates that have:

[...]; or cRLDistributionPoints or OCSP authorityInfoAccess extensions for which no operational CRL or OCSP service exists."

In the context of Mozilla policy for public S/MIME, I would interpret "operational" to include "publicly accessible". Because PUBLIC S/MIME.

And this is all just another data point showing that the correct reading of the S/MIME BRs includes the common implicit assumption that CRL and OCSP servers need to be publicly available and operating in a manner generally consistent with how CRL and OCSP servers are generally accepted to operate.

[cardonator]

Great, this LGTM now. @christopher-henderson do you want to take a look?

[christopher-henderson]

Thank you @cardonator, @mtgag, and @CBonnell for the thorough policy discussion - it always helps a ton.