[Servercert-wg] Question on BR 3.2.2.6

[Ryan Sleevi]

Thanks for mentioning, Clint.

It sounds like this is related to https://www.rfc-editor.org/errata/eid5997 and
the many varying interpretations of the section in the absence of an
explicitly worded syntax requirement.

You can find some past discussion from DigiCert at
https://bugzilla.mozilla.org/show_bug.cgi?id=1456655#c4 , and hopefully
that Errata captures some of the history. The thread isn't yet mirrored to
the IETF PKIX mailarchive, but presumably, that's where discussion of the
errata will happen. The change that Tim referenced in cablint was
https://github.com/awslabs/certlint/commit/b9c32490494d566f973f7d3b6e3bec92df331b2e#diff-5c84709d56bd30d404ff8f817a7987e4
,
which matches the discussion in that Errata.

Of course, as the Errata mentions, Apple isn't alone in 'allowing'
(parsing) the '.', but it seems that it definitely has incompatible
processing syntax, and from a face-value reading of the RFC, not permitted.

On Thu, Feb 27, 2020 at 6:32 PM Clint Wilson <clintw at apple.com> wrote:

> Hi all,
>
> Our interpretation of this is that a Name Constraint dNSName which
> contains a preceding ‘.’ *requires *one or more additional labels to
> match the name constraint, while a Name Constraint dNSName which contains
> no preceding ‘.’ allows zero or more labels.
> For example, if a CA with a name constraint of “.example.com” issued a
> cert for “example.com”, valuation would fail, while a cert issued for “
> www.example.com” would pass.
> If a CA with a name constraint of “example.com” issued a cert for “
> example.com”, valuation would pass, alongside a cert issued for “
> www.example.com” passing too.
>
> Thanks,
> -Clint
>
> On Feb 27, 2020, at 11:35 AM, Ryan Sleevi via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
>
>
> On Thu, Feb 27, 2020 at 2:18 PM Corey Bonnell via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
>> It’s a PKI footgun for sure, but here’s the relevant paragraph from
>> 4.2.1.10:
>>
>>
>>
>> “DNS name restrictions are expressed as host.example.com.  Any DNS
>>
>>    name that can be constructed by simply adding zero or more labels to
>>
>>    the left-hand side of the name satisfies the name constraint.  For
>>
>>    example, www.host.example.com would satisfy the constraint but
>>
>>    host1.example.com would not.”
>>
>>
>>
>> A dNSName permittedSubtree value of “gov.XX” wouldn’t allow “nogov.XX”,
>> as the matching is done by appending zero or labels to the dNSName and not
>> a simple string concatenation. In other words, “gov.XX” and “www.gov.XX”
>> are permitted, but “nogov.XX” is not.
>>
>>
>>
>> As for the ACM documentation you provided, I don’t think it’s
>> RFC-compliant given the paragraph above. Here’s an example (long-expired)
>> subCA that contains incorrectly encoded nameConstraints (due to the leading
>> period) and cablint complains:
>> https://crt.sh/?id=2929505&opt=cablint,zlint. Interestingly, zlint does
>> not flag this error.
>>
>
> Thanks for pointing that out, Corey. I filed
> https://github.com/zmap/zlint/issues/413 for this, because as you note,
> it is malformed.
> <image003.png>_______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200227/e8a0df54/attachment.html>