On Sunday, February 24, 2019 at 8:05:10 PM UTC-5, Scott Rea wrote: > G’day Corey, > > In respect to the previously issued constrained intermediates – can you > clarify where in RFC5280 Section 4.2.1.10 that the prohibition against a > leading period is specified for the name constraints? > I see in the RFC the specific sentence: “When the constraint begins with a > period, it MAY be expanded with one or more labels.” This appears to > contradict your assertion that leading period constraints violate 5280… > > During the period that these intermediates were deployed, the browsers and > platforms dependent on these performed path processing exactly as expected > with this configuration. > > Can you please illuminate the passage in the RFC where you feel a leading > period in a permitted subtree e.g. (“.ae”) as was used in the identified > intermediate certificates, is a violation?? > > Regards, > > > -- > > Scott Rea > > On 2/25/19, 12:50 AM, "dev-security-policy on behalf of Corey Bonnell via > dev-security-policy" <dev-security-policy-boun...@lists.mozilla.org on behalf > of dev-security-policy@lists.mozilla.org> wrote: > > Furthermore, two of the intermediates issued to DarkMatter which chain to > QuoVadis/Digicert roots violate RFC 5280, section 4.2.1.10 > (https://tools.ietf.org/html/rfc5280#section-4.2.1.10). Specifically, the > dNSName in the nameConstraints extension's permittedSubtrees field contains a > leading period (".ae"), which violates the hostname syntax specified in > section 4.2.1.10. Therefore, these two intermediate certificates > (https://crt.sh/?id=23432430&opt=cablint, > https://crt.sh/?id=19415522&opt=cablint) are also mis-issued under the > Baseline Requirements. > > I have sent a Certificate Problem Report to Digicert to notify them of > these findings, as these intermediates and DarkMatter-issued certificates > chain to roots under their control. > > > > > Scott Rea | Senior Vice President - Trust Services > Tel: +971 2 417 1417 | Mob: +971 52 847 5093 > scott....@darkmatter.ae > > The information transmitted, including attachments, is intended only for the > person(s) or entity to which it is addressed and may contain confidential > and/or privileged material. Any review, retransmission, dissemination or > other use of, or taking of any action in reliance upon this information by > persons or entities other than the intended recipient is prohibited. If you > received this in error, please contact the sender and destroy any copies of > this information.
Hi Scott, The verbiage from RFC 5280, section 4.2.1.10 that you quoted is in regard to URI GeneralNames, as the paragraph starts with "For URIs...". The relevant paragraph in section 4.2.1.10 that specifies the required syntax of dNSNames in nameConstraints and explains why the two intermediates are non-compliant is as follows: "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." As you can see, there is no provision for encoding a leading period in dNSNames. Several certificate linters detect this particular problem, which you can see demonstrated in the two links I provided to the two intermediates' crt.sh entries. Thanks, Corey _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
