Re: Intermediate common name ambiguous naming
Definitely seems better for this issue, more identifiable to the user and
Firefox already does this for the padlock icon menu.
‐‐‐ Original Message ‐‐‐
On Sunday, 20 December 2020 17:04, Matthew Thompson via dev-security-policy
wrote:
> It's not ideal that Google Chrome now states "The connection to this site is
> using a valid, trusted server certificate issued by R3" (desktop) and "Google
> Chrome verified that R3 issued this website's certificate" (mobile). But that
> seems to be an issue the Chromium project could resolve by relying on "O"
> instead of "CN". Maybe something for you to look into Ryan.
>
> Matt T
>
> On Saturday, 12 December 2020 at 09:00:40 UTC+8, Ryan Sleevi wrote:
>
> > Sure, is there a more specific question I could answer? I'm not really sure
> > how to rephrase that, and CAs seem to understand it. [1]
> > [1] https://www.abetterinternet.org/documents/2020-ISRG-Annual-Report.pdf
> > On Fri, Dec 11, 2020 at 1:43 PM Burton j...@0.me.uk wrote:
> >
> > > Ryan,
> > > Please could you expand a little more on this?
> > > "Ideally, users would most benefit from simply having a random value in
> > > the DN (no details, period) for both roots and intermediates, as this
> > > metadata both can and should be addressed by CCADB"Burton
> > > On Fri, 11 Dec 2020, 16:49 Ryan Sleevi, ry...@sleevi.com wrote:
> > >
> > > > On Fri, Dec 11, 2020 at 11:34 AM Burton j...@0.me.uk wrote:
> > > >
> > > > > The bits of information included in the CN field (company name,
> > > > > version,
> > > > > etc) created intermediate separation from the rest and the additional
> > > > > benefit of these bits of information included in the CN field in an
> > > > > intermediate was a person could locate with some accuracy at first
> > > > > glance
> > > > > the CA the intermediate belongs too and that can help in many
> > > > > different
> > > > > ways.
> > > >
> > > > I don't think the benefits here are meaningful, which is where I think
> > > > we
> > > > disagree, nor do I think the use case you're describing is a good
> > > > trade-off.
> > > > Expecting the company name to be in the CN is, frankly, both
> > > > unreasonable
> > > > and not required. The version is already there ("R3"), so I'm not sure
> > > > why
> > > > you mention it, although it'd be totally valid for a CA to use a random
> > > > value there.
> > > > I don't think "in many different ways" is very useful to articulate the
> > > > harm you see.
> > > >
> > > > > The problem with the Let's Encrypt R3 intermediate is that the CN
> > > > > field
> > > > > is both unique and not unique. It's unique CN in the sense of the
> > > > > name "R3"
> > > > > and also only Let's Encrypt uses that name in an intermediate. It's
> > > > > not an
> > > > > unique CN because it's not random enough and doesn't have any other
> > > > > information to separate the intermediate if another CA decided to
> > > > > issue an
> > > > > intermediate with the same CN name "R3". Also from a first glance
> > > > > prospective it's hard to determine the issuer in this format without
> > > > > looking inside the intermediate subject.
> > > >
> > > > It would seem you're expecting the CN to be a DN. If that's the case, I
> > > > regret to inform you, you're wrong for expecting that and unreasonable
> > > > for
> > > > asking for it :)
> > > > If another CA wants to use the name R3, I see no issues with that: it is
> > > > the Distinguished Name in totality that addresses it, and we've already
> > > > got
> > > > the issue you're concerned about (two CAs use the name "R3") identified
> > > > by
> > > > the O.
> > > >
> > > > > If Let's Encrypt R3 intermediate CN was hypothetically "LE R3" naming
> > > > > that would be enough uniqueness other intermediates, very short
> > > > > naming and
> > > > > from a first glance prospective easier to determine the issuer.
> > > >
> > > > > The main biggest problem point for me is the lack of uniqueness of the
> > > > > intermediate with the "R3" naming on it's own.
> > > >
> > > > Right, there's absolutely nothing wrong with two CAs using the same CN
> > > > for an intermediate, in the same way there's nothing wrong with two CAs
> > > > using the same CN for a leaf certificate (i.e. two CAs issuing
> > > > certificates
> > > > to the same server). For your use case, it's important to use the
> > > > technology correctly: which is to use the DistinguishedName here, at a
> > > > minimum. However, I'm also trying to highlight that using the
> > > > Distinguished
> > > > Name here is itself problematic, and has been for years, so if you're
> > > > changing from "use CN", you should really be "use CCADB" rather than
> > > > "use
> > > > CN".
> > > > Arguments such as "easy, at a glance, in the certificate viewer", which
> > > > I
> > > > can certainly understand is how some have historically looked at
> > > > things, is
> > > > in practice an antiquated idea that doesn't line up with operational
> > > >
Re: Apple OCSP Responder Issues Yesterday (2020-11-12)
I agree, from what I have seen online is that while Apple's OCSP responser was indeed soft-fail, it didn't have any short-term timeout so requests were left lingering. Due to it being soft-fail I've seen numerous posts detailing how to block the OCSP responder address either via DNS or via the terminal (not sure if you can disable revocation checking directly within settings). So this does seem to affect the industry as a whole. ‐‐‐ Original Message ‐‐‐ On Friday, November 13th, 2020 at 21:30, Matthew Hardeman via dev-security-policy wrote: > In as far as that part of Apple's CA hierarchy is publicly trusted and > participates in the Mozilla Root CA program and that there were apparent > performance issues with ocsp.apple.com yesterday, I'm writing to suggest that > I believe there may be cause to expect some transparency regarding recent > Apple OCSP responder performance issues, whether those issues impacted > responses over covered certificates, what failures led to those issues, and > what remediations have been taken. > > I haven't seen any other mention of this and whether it rises as to the level > of an incident as yet. > > I clarify that I do not personally allege that I experienced a timeout or > long delay querying an in-scope certificate, but rather that infrastructure > that seems to be shared with publicly trusted signers had externally > detectable issues related to OCSP performance. > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy signature.asc Description: OpenPGP digital signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: NAVER: Public Discussion of Root Inclusion Request
Minor but it seems like all certificates with a stateOrProvinceName field are misissued. The ST field should probably be the "Gyeonggi-do" as the "Seongnam-si" entered is a city. ‐‐‐ Original Message ‐‐‐ On Friday, 9 October 2020 23:09, Ben Wilson via dev-security-policy wrote: > Dear All, > > This is to announce the beginning of the public discussion phase of the > Mozilla root CA inclusion process, > https://wiki.mozilla.org/CA/Application_Process#Process_Overview, (Steps 4 > through 9). Mozilla is considering approval of NAVER Business Platform > Corp.’s request to include the NAVER Global Root Certification Authority as > a trust anchor with the websites trust bit enabled, as documented in the > following Bugzilla case: > https://bugzilla.mozilla.org/show_bug.cgi?id=1404221. I hereby initiate a > 3-week comment period, after which if no concerns are raised, we will close > the discussion and the request may proceed to the approval phase (Step 10). > > A Summary of Information Gathered and Verified appears here in the CCADB: > > https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=0261 > > *NAVER Global Root Certification Authority, *valid from 8/18/2017 to > 8/18/2037 > > SHA2: 88F438DCF8FFD1FA8F429115FFE5F82AE1E06E0C70C375FAAD717B34A49E7265 > > https://crt.sh/?id=1321953839 > > Root Certificate Download: > > https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=CERTILIST_file_nm=1c3763b33dbf457d8672371567fd1a12.crt_real_file_nm=naverrca1.crt > > CP/CPS: > > Comments 29 (https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c29) > through 42 in Bugzilla contain discussion concerning the CPS and revisions > thereto. > > Current CPS is version 1.4.3: > > https://certificate.naver.com/cmmn/fileDown.do?atch_file_path=POLICY_file_nm=b2daecb6db1846d8aeaf6f41a7aea987.pdf_real_file_nm=NBP > Certification Practice Statement v1.4.3.pdf > > Repository location: https://certificate.naver.com/bbs/initCrtfcJob.do > > BR Self Assessment (Excel file) is located here: > > https://bugzilla.mozilla.org/attachment.cgi?id=9063955 > > Audits: Annual audits are performed by Deloitte according to the > WebTrust Standard and WebTrust Baseline Requirements audit criteria. See > webtrust.org. The last complete audit period for NAVER was from 1 December > 2018 to 30 November 2019 and no issues were found. However, the audit > report was dated 28 April 2020, which was more than three months following > the end of the audit period. The explanation for the delay in obtaining the > audit report was as follows, “NBP had received a notification mail on > updating the audit information from CCADB support in March since the Root > certificate is only included into Microsoft Root Program. According to > instructions on the email, I explained that NBP would submit the audit > update information in April to Microsoft.” The current audit period ends > 30 November 2020. > > *Mis-Issuances * > > According to crt.sh and censys.io, the issuing CA under this root > (NAVER Secure Certification Authority 1) has issued approximately 80 > certificates. I ran the following query for the issuing CA to identify any > mis-issuances: > https://crt.sh/?caid=126361=cablint,zlint,x509lint=2017-08-18, > and during the course of our review, we identified six test certificates > with errors. (Such certificates have either been revoked or have expired). > See: > > https://crt.sh/?id=2132664529=cablint,zlint,x509lint > > https://crt.sh/?id=2102184572=cablint,zlint,x509lint > > https://crt.sh/?id=1478365347=cablint,zlint,x509lint > > https://crt.sh/?id=2149282089=cablint,zlint,x509lint > > https://crt.sh/?id=2149282369=cablint,zlint,x509lint > > https://crt.sh/?id=2282123486=cablint,zlint,x509lint > > The explanation provided ( > https://bugzilla.mozilla.org/show_bug.cgi?id=1404221#c27) was “Regarding > CA/B Forum and X.509 lint tests NBP figured out two(2) certificates which > were not complied with BRs right after issuing them. The domains on SANs of > the certificates were owned and controlled by NBP. They were immediately > revoked according to CA procedures. For ZLint tests, the certificate (CN= > test2-certificate.naver.com) had been issued and became expired in > compliance with CA Browser Forum BRs and RFC 5280. I understand there is a > specific Mozilla policy on Authority Key IDs. NBP already fixed the system > functions. There is no such valid certificate and NBP CA currently issues > certificates fully complied with the Mozilla policy. You can see the new > certificate (CN= test2-certificate.naver.com) was issued without any error > at https://crt.sh/?id=2824319278.” > > I have no further questions or concerns at this time, however I urge anyone > with concerns or questions to raise them by replying to this list under the > subject heading above. > > Again, this email begins a three-week public discussion period, which I’m > scheduling to close on Monday, 2-November-2020. > > Sincerely yours, > > Ben
Clear definition of a "locality"
I sent a problem report to rev...@digicert.com regarding the locality field in: https://crt.sh/?q=12EC8C05667173603367E8F93B7FDCA7EC60F9838EF3B72A4483BAF48DE48F4B Jeremy Rowley replied stating that he believed the locality was correct as there was no clear definition of a locality, can we get a clear definition of this? If these are considered localities then the streetAddress field seems to be obsolete? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
