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.
