-
Notifications
You must be signed in to change notification settings - Fork 116
Policy qualifiers shouldn't be present if the subordinate CA is an affiliate of the entity that controls the Root CA #289
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…filiate of the entity that controls the Root CA
👋 Hi @hablutzel1,
I think that's a reasonable reading but I don't know that the notice level lint you're proposing is going to be helpful overall. I suspect since you can't determine if any given sub-CA is "an Affiliate of the entity that controls the Root CA" programmatically the lint will necessarily create false-positive notices. Does anyone else have an opinion? |
I agree that the interpretation is reasonable but the wording in the BR doesn't specify whether it is "MUST NOT" vs. "SHOULD NOT". Since it's not explicitly stated, it's not clear what the correct behavior should be. Notice level would be appropriate for this type of informational only lint. Also agree that any lint would be very likely to produce false positives. |
It is clear that it will provide false positives for the subordinate CAs under a third party root (which I think that are not the most), but given that this is just a notice, isn't that acceptable?.
It would help to remind root CAs signing their own subordinate CAs to not include policy qualifiers, but it seems that several CAs are doing it anyway. Some random examples:
This is actually a Pass or Notice lint. Regardless of the previous, and even more important, what is the reason for this requirement in the BRs? , do you know?. |
I agree with @cpu here that I don't think that this is going to be helpful overall. Even as a notice, it's going to cause a fair amount of noise. There's just no way for us to know whether the subCA is affiliated. In general, I'd rather be conservative about adding noise since it will cause CAs to just ignore the notices due to warning fatigue. |
@hablutzel1 I don't know, sorry. Perhaps you could submit a "question from the public" to |
It seems like between @zakird, @cardonator and myself the consensus is that this won't be a net win for |
…ng (zmap#298) * backporting asn1, pkix to allow permissive parsing (zmap#284) * forking from golang.org/x/crypto/cryptobyte to allow permissive parsing * Allow permissive asn1 parsing on UTF8, integer and NameConstraints (zmap#287) * Allow permissive asn1 parsing on UTF8, integer and NameConstraints * Allow permissive asn1 parsing on UTF8, integer and NameConstraints, NumericString * Allow permissive parsing: IA5, integer min len (zmap#289) * Fix Name.String() to legacy behavior, permissive parsing asn1.IA5String (zmap#292) * deps: update publicsuffix-go for 2021-05-11T10:35:34 UTC * deps: update publicsuffix-go for 2021-05-13T08:40:11 UTC * deps: update publicsuffix-go for 2021-05-21T08:41:21 UTC * deps: update publicsuffix-go for 2021-05-27T09:03:28 UTC * Allow permissive parsing: IA5, integer min len * Fix Name.String() to legacy behavior Co-authored-by: GitHub <noreply@github.com> * Fix RDNSequence.String() to print user friendly names (zmap#294) * Merge branch master into feature/parse_certs (zmap#296) * deps: update publicsuffix-go for 2021-05-11T10:35:34 UTC * deps: update publicsuffix-go for 2021-05-13T08:40:11 UTC * deps: update publicsuffix-go for 2021-05-21T08:41:21 UTC * deps: update publicsuffix-go for 2021-05-27T09:03:28 UTC * deps: update publicsuffix-go for 2021-06-01T15:03:13 UTC * Fix RDNSequence.String() to print user friendly names * Porting ocsp package from the latest standard lib (zmap#279) Co-authored-by: Zakir Durumeric <zakird@gmail.com> * deps: update publicsuffix-go for 2021-06-07T12:03:41 UTC Co-authored-by: GitHub <noreply@github.com> Co-authored-by: Daniel McCarney <daniel@binaryparadox.net> Co-authored-by: Zakir Durumeric <zakird@gmail.com> Co-authored-by: Benjamin Wireman <ben@censys.io> Co-authored-by: GitHub <noreply@github.com> Co-authored-by: Daniel McCarney <daniel@binaryparadox.net> Co-authored-by: Zakir Durumeric <zakird@gmail.com> Co-authored-by: Jeff Cody <jeff@codyprime.org>
From BRs, "7.1.2.2. Subordinate CA Certificate":
It is indicating that policy qualifiers (e.g. CPS Pointer) shouldn't be present at all if the subordinate CA is affiliated to the root CA, isn't it?. In that case, this PR includes a new linter that would emit a notice when there are any policy qualifiers in subordinate CAs to help the subordinate CA signers to double check if they should be really including these policy qualifiers.
Finally, if this lint is OK to be pulled, let me know to write its corresponding test.