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.
