search

zmap / zlint

X.509 Certificate Linter focused on Web PKI standards and requirements.
https://zmap.io
Apache License 2.0
347 stars 106 forks source link

Lint for nameConstraints for dNSName and iPAddress #413

Open sleevi opened 4 years ago

sleevi commented 4 years ago

Presently, there are not lints on the well-formedness of the dNSName and iPAddress nameConstraints. There are lints for other name types, such as https://github.com/zmap/zlint/blob/fd40f579253ea1ebfb18a585ab5cd8e7dcde61aa/v2/lints/rfc/lint_name_constraint_on_edi_party_name.go or https://github.com/zmap/zlint/blob/fd40f579253ea1ebfb18a585ab5cd8e7dcde61aa/v2/lints/rfc/lint_name_constraint_on_x400.go , but none for dNSName or iPAddress.

Broadly, many of the dNSName checks applied to the SAN would also apply to the nameConstraints.

For example, see this discussion in the CA/B Forum, which pointed out that https://github.com/awslabs/certlint correctly detects the malformed name constraint on https://crt.sh/?sha256=A56C1BD2C47FFC701023FAD8F65CBE794946B779475848DCA30760A06DD72FD9 but ZLint does not

sleevi commented 4 years ago

Erp, I missed the similarity to cabforum/servercert#136 due to also mentioning iPAddresses here.

I'm ok duping them, or keeping this separate to also lint the well-formedness of IP addresses.

rolandshoemaker commented 4 years ago

Looks like zmap/zcrypto/x509 is already enforcing IP constraint validity during parsing.

Stdlib crypto/x509 does its own DNS name validity check, but disagrees that leading periods are invalid. See https://github.com/golang/go/issues/16347 for discussion of why this was allowed in stdlib.

sleevi commented 4 years ago

@rolandshoemaker Thanks for pointing out the iPAddress. While that makes sure that the base value is parsable, I was thinking about other checks, such as making sure it's not an internal IP address. I filed https://github.com/cabforum/documents/issues/160 so that these requirements could be made more explicit, where they are presently implicit.

That said, the Golang change seems to be about compatibility with existing misissuance, while given ZLint's concern on correctness, seems not to be too compelling. That said, I filed https://www.rfc-editor.org/errata/eid5997 to try and clarify.

christopher-henderson commented 3 years ago

@sleevi while digging into this I found your filing at https://github.com/cabforum/definitions/issues/1 which brings up...

The existence of the "or" clause leaves it ambiguous...

Which screams of the same confusions brought up in https://github.com/zmap/zlint/issues/553 last month.

I may be a bit green WRT to what RFCs are out there, but I'm beginning to wonder if an RFC 2119 type document for boolean expressions in plain English prose would be a good idea. Because English is...painful.