Hi Pekka, Obviuosly your assurance below is on behalf of one of the PKI participant - Telia Finland Oyj.
It would be nice if the other PKI participant - Telia Company AB makes similiar public commitment. Thanks, M.D. On Thu, Jan 20, 2022, 09:30 [email protected] < [email protected]> wrote: > Thanks Ben, > > It has always been clear to Telia that all participants and certificates > in Mozilla scope has to be included into audits and results are disclosed. > Telia will next improve the formulation of the texts in both CPSs (before > June 2022) and audit reports (June 2022). We negotiate the better > formulations together with our auditors and management. We'll also follow > the discussion in listed Github link if there will come some instructions > what is the recommended way to document this in corporate case when several > legal units are involved but operationally CA is just one entity and there > are two (several) internal RAs operated by different legal entities of the > same corporate. > > torstai 20. tammikuuta 2022 klo 7.16.40 UTC+2 [email protected] > kirjoitti: > >> All, >> >> Over the past few weeks, we have discussed here Telia Finland Oyj’s >> request in more depth. The discussion has mainly focused on Telia >> Finland Oyj’s parent company, Telia Company AB, and whether any >> unaffiliated third-party entities might be involved in providing RA >> services. >> >> As Moudrick Dadashov rightly noted, the management assertion that >> accompanied the WebTrust audit report stated, “Telia Company AB (Telia) >> operates the Certificate Authority (CA) services as listed in Appendix A, >> and provides the following services: Subscriber registration, Certificate >> renewal, Certificate rekey, Certificate issuance, Certificate distribution, >> Certificate revocation, Certificate validation, Subscriber key generation >> and management. The management of Telia is responsible for establishing and >> maintaining effective control over its CA operations….” >> >> KPMG’s audit report likewise addressed Telia Company AB management and >> stated, “Telia makes use of external registration authorities for >> subscriber registration activities, as disclosed in Telia's business >> practices. Our procedures did not extend to the controls exercised by these >> external registration authorities.” >> >> Telia has stated that its CA resources were clearly identified by the >> auditors as located in Finland and Sweden and that the full CA organization >> and system had been audited annually in both countries and in both >> companies. Auditors received details on the persons involved with the Telia >> CA and the “audit has been focused on those persons and their legal >> entities and how they implement Telia CA.” It also responded that the >> audit scope in the audit reports included the legal entity Telia Company >> AB, because it was the main company, but also included affiliated legal >> entities practically participating in the Telia CA processes. >> >> Moudrick has made the point that the two organizations (Telia Company AB >> and Telia Finland Oyj) are separate legal entities. He said it was unclear >> which legal entity was the CA. He has argued that some of the materials >> provided (e.g. the audit documents) were on behalf of Telia Company AB, >> while the applicant is Telia Finland Oyj, and that these are two different, >> independent entities. He argued that "legal ownership" has nothing to do >> with the CA operations -- that Telia Company AB only controls shares of >> another legal entity (Telia Finland Oyj), which has nothing to do with CA >> operations. Moudrick has argued that the audit reports should have been >> issued to Telia Finland Oyj, which should be the only ‘main company’, but >> that “[a]ccording to the audit report … Telia Company AB is the CA.” >> >> Representatives from Telia have stated clearly and consistently that the >> applicant and CA operator is Telia Finland Oyj. The CA certificate >> identifies “Telia Finland Oyj” as the Organization. Section 1.3.1 of >> the CP/CPS for Telia Server Certificates (v.4.4) states, "The CA operating >> in compliance with this CPS is Telia CA. The legal entity responsible of >> Telia CA is Finnish company “Telia Finland Oyj” (BusinessID 1475607-9). >> Telia Finland Oyj is part of Swedish company “Telia Company AB” (BusinessID >> 5561034249)." To avoid future confusion, Telia has offered to “ask >> [its] auditors to add all three company names in the future audit reports >> if it makes audit results clearer.” I’d ask Telia to also improve its >> CP/CPS to provide more detail on the involvement of Telia Company AB in the >> management of the CA and any other subsidiaries’ provision of operational >> services. >> >> Wikipedia and other information sources provide some information on the >> organizational and financial relationships among Telia Company AB and its >> subsidiaries, but not enough information is available on management >> structure and operations of the conglomerate. KPMG, in addressing its >> opinion to the management of Telia Company AB, implied that it had >> determined that Telia Company AB had some degree of control over CA >> operations. This is where the CP/CPS could be improved. >> >> As noted by Ryan Sleevi, Peter Bowen, and Dimitris Zacharopoulos, PKI >> participant roles need to be adequately disclosed and any Delegated Third >> Party RAs need to be disclosed and audited. There is a need for greater >> transparency and specificity. Ryan and Peter both felt that more >> explanation was needed concerning RA functions--“it would be helpful to >> clarify what functions any external RA does for any certificate that falls >> within the Mozilla policy.” Dimitris also stated that “it needs to be >> clearly (and explicitly?) stated that this external RA does not perform RA >> functions related to Certificates for TLS and email.” Pekka Lahtiharju from >> Telia responded that Telia hasn't used any third party RAs except in the >> mentioned client certificate cases – that the external RA does not perform >> RA functions related to Certificates for TLS and email. >> >> Basically, Moudrick has also asked for greater transparency and >> specificity, which is in line with what Mozilla wants. Moudrick also >> cited MRSP section 8, that “trust is not transferrable”. Without getting >> into an interpretation of what that means for CAs operated by >> conglomerates, I agree with these points - it is important to know who is >> responsible, and I agree with Moudrick’s position that “If the CA >> operations rely on other party's (e.g. owner's, affiliate's etc.) material >> or human resources, you need to disclose those shared resources.” Peter >> Bowen noted, “If Mozilla wants to have all the legal entities involved >> listed in the audit report, that is something that should be included in >> the Mozilla policy.” As a result of this, I have filed an issue in >> Github for these issues to be explored and worked on further in the future >> development of the Mozilla Root Store Policy. See >> https://github.com/mozilla/pkipolicy/issues/237 >> >> Based on all of the discussions back and forth, it appears that there is >> some common management under the umbrella of Telia Company AB, but that is >> no reason to withhold the approval of the inclusion of the root CA operated >> by Telia Finland Oyj, which has ownership and control of the CA certificate >> and keys. I believe the question of whether unaffiliated third-party >> entities might be involved in providing RA services has been adequately >> answered. I urge Telia to add more detail, relative to these public >> discussions, the next time it updates its CP/CPS. >> >> Thus, I'm going to ask Kathleen to proceed and approve the request to >> include the Telia Root CA v2 in the Mozilla/NSS root store. >> >> Thanks, >> >> Ben >> >> On Fri, Jan 14, 2022 at 5:13 AM [email protected] < >> [email protected]> wrote: >> >>> Right now audit reports aren't directly stating that "no external RAs >>> are used for any validation activity associated with TLS or email >>> certificates" but this is how it is and indirectly this should be clear >>> because of the mentioned statements in CPS chapters 1.3.2. I hope it is >>> enough now that we instruct auditors to add clearer statement into the next >>> audit report; next audit round is soon starting and results come in June >>> 2022. >>> >>> perjantai 14. tammikuuta 2022 klo 13.55.21 UTC+2 [email protected] >>> kirjoitti: >>> >>>> >>>> >>>> On 14/1/2022 11:22 π.μ., [email protected] wrote: >>>> >>>> Hi Dimitris, >>>> >>>> I wonder why Telia should provide audit report to Mozilla about the >>>> only external RA Telia CA is using when this external RA is using subCA >>>> that is out of scope of Mozilla based on its EKU values. This external RA >>>> is producing only client certificates for signature purposes. >>>> >>>> >>>> Hello Pekkam >>>> >>>> If they are out of scope, then it makes sense not to disclose such >>>> audit reports to Mozilla and other Root Programs that are only interested >>>> in "websites" and "email" certificates. However, it needs to be clearly >>>> (and explicitly?) stated that this external RA does not perform RA >>>> functions related to Certificates for TLS and email. In any case, this is >>>> not a very popular condition because external RAs typically validate >>>> identities that can be used for all certificate types, including TLS >>>> (OV/IV/EV) and email certificates that include identity. However, it is >>>> perfectly fine to scope these external RAs out for TLS and email >>>> certificates if you choose to do so. >>>> >>>> >>>> >>>> Both provided audit reports WTCA and WTBR state that they cover Telia >>>> CA operations in Finland and Sweden and only WTCA report has remark about >>>> External RA in this format (WTBR report doesn't have this): >>>> >>>> "Telia makes use of external registration authorities for subscriber >>>> registration activities as disclosed in Telia's business practices. Our >>>> procedures did not extend to the controls excercised by these external >>>> registration authorities." >>>> >>>> This text above refers to Telia Client CPS that has disclosed that the >>>> only case in addition to Enterprise RA when Telia is using External RA is >>>> related to Telia Class 3 client certificates and all SMIME related >>>> validation is done only by Telia CA itself. E.g. Client CPS 1.3.2: "Telia >>>> CA employs two RAs: Internal RA and External RA. Telia will not delegate >>>> domain validation to be performed by a third-party. The CA itself verifies >>>> email domain ownership or verifies that End-entity controls the email >>>> account." Chapter 1.3.2.2 defines Telia's only External RA to be restricted >>>> only to Class 3 certificates outside of Mozilla context. Note also that >>>> Server CPS states clearly that within TLS validation no External RAs are >>>> used: 1.3.2: "All RA functions in this CPS are performed internally by >>>> Telia. Telia will not delegate domain validation to be performed by a >>>> third-party." >>>> >>>> >>>> Thank you for the clarifications. Please note that the statement for >>>> "not delegate domain validation to be performed by a third-party" does not >>>> apply to the identity validation function. This means that Telia CA could >>>> perform the Domain Validation part and delegate the Identity Validation >>>> part ("subscriber registration activities" in your WTCA audit report) to >>>> another entity (external RA) that would need to be audited. If your >>>> statement is that no external RAs are used for any validation activity >>>> *associated >>>> with TLS or email certificates*, then I believe this addresses the >>>> audit concerns related to this application. >>>> >>>> It is not for me to decide whether this needs to be explicitly stated >>>> in audit reports or not. However, the fact that the "external RA" is >>>> mentioned only in the WTCA and not in the WTBR report, might implicitly >>>> state that there are no external RAs involved in the TLS certificate >>>> issuance process, but does it apply to the email certificate issuance? To >>>> the best of my knowledge, email certificate issuance is covered by the WTCA >>>> audit report and TLS is covered by the WTCA+WTBR. This could mean that >>>> "External RAs" might be used in the validation process (email or identity) >>>> for S/MIME certificates which are in scope of the Mozilla Root Program. >>>> >>>> As a side note, I believe it would greatly help the community if WT >>>> experts could provide some guidance how Relying Parties should interpret >>>> WTCA and WTBR reports. Should a RP read a WTBR report as a stand-alone >>>> report or in combination with the WTCA? >>>> >>>> >>>> Best regards, >>>> Dimitris. >>>> >>>> >>>> >>>> >>>> perjantai 14. tammikuuta 2022 klo 9.59.22 UTC+2 [email protected] >>>> kirjoitti: >>>> >>>>> >>>>> Sorry for chiming in late, I was monitoring this discussion and >>>>> thought of adding a comment about the completeness of audit reports. >>>>> >>>>> In my understanding, when Mozilla or any other Root Program is >>>>> evaluating audit reports (Point-in-Time or Period-of-Time), they must >>>>> confirm that all entities/functions that should be audited, are included >>>>> in >>>>> the submitted audit reports. >>>>> >>>>> It is acceptable to submit multiple audit reports when multiple legal >>>>> entities fulfill different CA functions, but at the end of the day all >>>>> functions that need to be audited must be accounted for. >>>>> >>>>> If the CA is company A and they have an external RA which is company >>>>> B, then one of the following is acceptable: >>>>> >>>>> a) Company A presents an audit report that contains its own CA >>>>> operations AND the operations of company B, which means that the auditor >>>>> of >>>>> company A has engaged into independently evaluating the RA operations of >>>>> company B >>>>> >>>>> b) Company A presents an audit report that contains its own CA >>>>> operations and states that it did not evaluate operations of external RA >>>>> of >>>>> company B, and there is a separate external audit report of company B >>>>> which >>>>> independently evaluates the RA operations of company B. Together, these >>>>> two >>>>> audit reports prove that all audited functions have been performed and >>>>> nothing is missing. >>>>> >>>>> If I understand one of Moudrick's concerns (obviously he has plenty of >>>>> concerns but I only focus on the audit completeness), the audit report >>>>> submitted by Telia does not include an opinion on "external RAs" which >>>>> means that we are missing an audit report about these external RAs. AFAIK, >>>>> external RAs are not exempt and must be audited by a qualified (external) >>>>> auditor. Unless I am missing something, I believe that only Enterprise RAs >>>>> can exist without external audits. >>>>> >>>>> Ryan, Peter, do you agree with the last comment? >>>>> >>>>> >>>>> Thanks, >>>>> Dimitris. >>>>> >>>>> >>>>> PS: I was trying to find the right message in the various existing >>>>> threads to reply to but it was too many messages to process, so apologies >>>>> for starting a new thread. >>>>> >>>>> >>>>> On 1/12/2021 5:15 μ.μ., Ben Wilson wrote: >>>>> >>>>> 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) for Telia’s inclusion request for the Telia Root CA v2 >>>>> ( >>>>> https://crt.sh/?id=1199641739). >>>>> >>>>> Mozilla is considering approving Telia’s request to add the root as a >>>>> trust anchor with the websites and email trust bits as documented in >>>>> Bugzilla >>>>> #1664161 <https://bugzilla.mozilla.org/show_bug.cgi?id=1664161> and CCADB >>>>> Case #660 >>>>> <https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000660>. >>>>> >>>>> >>>>> This email begins the 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). >>>>> >>>>> *Summary* >>>>> >>>>> This CA certificate for Telia Root CA v2 is valid from 29-Nov-2018 to >>>>> 29-Nov-2043. >>>>> >>>>> *SHA2 Certificate Hash:* >>>>> >>>>> 242B69742FCB1E5B2ABF98898B94572187544E5B4D9911786573621F6A74B82C >>>>> >>>>> *Root Certificate Downloads:* >>>>> >>>>> https://support.trust.telia.com/repository/teliarootcav2_selfsigned.cer >>>>> >>>>> https://support.trust.telia.com/repository/teliarootcav2_selfsigned.pem >>>>> >>>>> >>>>> *CP/CPS:* Effective October 14, 2021, the current CPS for the Telia >>>>> Root CA v2 may be downloaded here: >>>>> >>>>> https://cps.trust.telia.com/Telia_Server_Certificate_CPS_v4.4.pdf >>>>> (v.4.4). >>>>> >>>>> Repository location: https://cps.trust.telia.com/ >>>>> >>>>> >>>>> *Test Websites:* >>>>> >>>>> Valid - https://juolukka.cover.telia.fi:10603/ >>>>> >>>>> Revoked - https://juolukka.cover.telia.fi:10604/ >>>>> >>>>> Expired - https://juolukka.cover.telia.fi:10605/ >>>>> >>>>> >>>>> >>>>> *BR Self Assessment* (PDF) is located here: >>>>> https://support.trust.telia.com/download/CA/Telia_CA_BR_Self_Assessment.pdf >>>>> >>>>> *Audits:* Annual audits are performed by KPMG. The most recent >>>>> audits were completed for the period ending March 31, 2021, according to >>>>> WebTrust audit criteria. The standard WebTrust audit (in accordance with >>>>> v.2.2.1) contained no adverse findings. The WebTrust Baseline >>>>> Requirements audit (in accordance with v.2.4.1) was qualified based on the >>>>> fact that the Telia Root CA v1 certificate <https://crt.sh/?id=989582> >>>>> did not include subject:countryName. (The Telia Root CA v2 contains a >>>>> subject:countryName of “FI”.) >>>>> >>>>> Attachment B to the WebTrust Baseline Requirements audit report listed >>>>> eight (8) Bugzilla bugs for incidents open during the 2020-2021 audit >>>>> period, which are now resolved as fixed. They were as follows: >>>>> >>>>> *Link to Bugzilla Bug* >>>>> >>>>> *Matter description* >>>>> >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1614311 >>>>> >>>>> Two CA certificates not listed in 2020 WebTrust audit report >>>>> >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1612332 >>>>> >>>>> Ambiguity on KeyUsage with ECC public key >>>>> >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1551372 >>>>> >>>>> One Telia certificate containing a stateOrProvinceName of “Some-State” >>>>> >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1649683 >>>>> >>>>> Two Telia’s pre-2012 rootCA certificates aren’t fully compliant with >>>>> Baseline Requirements >>>>> >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1637854 >>>>> >>>>> AIA CA Issuer field pointing to PEM-encoded certificate >>>>> >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1674536 >>>>> >>>>> Certificates with RSA keys where modulus is not divisible by 8 >>>>> >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1565270 >>>>> >>>>> Subject field automatic check in CA system >>>>> >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1689589 >>>>> >>>>> Disallowed curve (P-521) in leaf certificate >>>>> >>>>> >>>>> >>>>> Recent, open bugs/incidents are the following: >>>>> >>>>> *Link to Bugzilla Bug* >>>>> >>>>> *Matter description* >>>>> >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1738207 >>>>> >>>>> Issued three precertificates with non-NIST EC curve >>>>> >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1736020 >>>>> >>>>> Invalid email contact address was used for few domains >>>>> >>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1737808 >>>>> >>>>> Delayed revocation of 5 EE certificates in connection to id=1736020 >>>>> >>>>> >>>>> >>>>> I have no further questions or concerns about this inclusion request, >>>>> however I urge anyone with concerns or questions to raise them on this >>>>> list >>>>> by replying directly in this discussion thread. Likewise, a representative >>>>> of Telia must promptly respond directly in the discussion thread to all >>>>> questions that are posted. >>>>> >>>>> Again, this email begins a three-week public discussion period, which >>>>> I’m scheduling to close on December 22, 2021. >>>>> >>>>> Sincerely yours, >>>>> >>>>> Ben Wilson >>>>> >>>>> Mozilla Root Program >>>>> >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "[email protected]" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZZj87QS3jL7R_32JEnfPZeU4hBNBJ%2BGHWU_pUdqF%3Dbbg%40mail.gmail.com >>>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZZj87QS3jL7R_32JEnfPZeU4hBNBJ%2BGHWU_pUdqF%3Dbbg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> >>>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "[email protected]" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> >> To view this discussion on the web visit >>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ed9f3f6b-ada4-439a-8ce1-d650297d1953n%40mozilla.org >>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/ed9f3f6b-ada4-439a-8ce1-d650297d1953n%40mozilla.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b2f1143c-906a-4fcd-bddd-0f5513cae4aen%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/b2f1143c-906a-4fcd-bddd-0f5513cae4aen%40mozilla.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAMMZRrxXAWo%3D4nF0AQ%2BYXdtRnwnASJ279fYKx%3DyupSQsC8htvA%40mail.gmail.com.
