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*
*Matterdescription***
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*
*Matterdescription***
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/62a438d9-7cca-d2c2-31e2-02035531600f%40it.auth.gr.
