Your comment is  again full of inaccurate claims and accusations without 
any evidence. Again: SK ID Solutions is not an affiliate of Telia Company 
AB (check annual report that is listing affiliates). Telia CA has nothing 
to do with them. This conversation is about Telia CA Root application to 
Mozilla and your unclear SK/Eidas/QS comments are not related to this at 
all. I wonder how long this kind of hostile discussion is tolerated by 
Mozilla.

-"High Risk": Telia Company AB is by no means any "high risk" applicant. 
Telia CA has been a normal Root CA already more than 15 years without any 
security related issues in any of annual audit results. All BR rules have 
been followed during that time. Only minor technical deviations have ever 
been identified. Recently Telia also joined to CAB Forum work also.

-"Semi-government company": Telia Company is a normal private company. 
Check https://www.teliacompany.com/en: Founded in 1853. The share is listed 
at Nasdaq Stockholm and Nasdaq Helsinki. Approximately 490,000 
shareholders. 20,800 employees. Net sales SEK 89,191 million.

-"The problem here is that the CA resources need to be clearly identified 
and audited": 
CA Resources have been clearly identified above to be located in Finnish 
"Telia Finland Oyj" and in Swedish "Cygate AB". The full CA organization 
and system has been audited annually in both countries and in both 
companies. Auditors have got exact person details who belong to Telia CA 
and audit has been focused on those persons and their legal entities and 
how they implement Telia CA.

-"the discussion is about CA operations not ownership"
I agree. Auditors have audited all related CA operations annually based on 
publicly disclosed Telia CP/CPS.

-"the subject of audit should be a legal entity, not a country"
Audit scope in audit reports has been legal entity "Telia Company AB 
(Telia)" that is the main company. This audit scope covers both mentioned 
affiliate legal entities practically participating into Telia CA processes.

-"CA/Browser Forum Baseline Requirements Audit Report 2021 (15 pages). In 
this report there is no reference to Telia Finland Oyj."
In audit reports there is reference to main company "Telia Company AB" 
because auditors kept it as better because Telia CA functions are carried 
by both affiliates: "Telia Finland Oyj" and "Cygate AB". We can ask 
auditors to add all three company names in the future audit reports if it 
makes audit results clearer.

-"Telia Public Response to Audit 2021, In this single page document no 
reference to Telia Company AB or Telia Finland Oyj."
Incorrect, footer has identification of entity that created this response 
which is: Telia Finland Oyj

-"Mozilla policy requires clear indication of which audit criteria were 
checked (or not checked) at each location" - as you don’t have a CP and the 
relevant parts are not identified in the CP/CPS, its unclear what criteria 
you are talking about."
I don't understand. We have CP (combined CP/CPS) that identifies the legal 
entities. I think the used audit criteria and locations (Finland and 
Sweden) are clearly stated in the audit reports. Both locations were using 
the same criteria. For WTCA criteria it is clearly written there "...in 
accordance with the WebTrust Principles and Criteria for Certificate 
Authorities v2.2.1." and for WTBR is using "...in accordance with the 
WebTrust Principles and Criteria for Certificate Authorities - SSL Baseline 
with Network Security v2.4.1."  





  


maanantai 3. tammikuuta 2022 klo 18.38.08 UTC+2 [email protected] kirjoitti:

> 1. RE "*recent eIDAS & GDPR misimplementation chaos started*"
>
>
> 1.1 *misimplementation* means an *instance* of applying *something* 
> incorrectly
>
> 1.1.1 *instance* means a data object that Telia's affiliates - SK ID 
> Solutions (formerly *AS Sertifitseerimeskeskus*)  together with its RA - 
> Omnitel (legal name - *AB Telia Lietuva*) have been issuing to the public 
> as "qualified certificate" (QS).
>
> 1.1.2 *something* means "Qualified certificate" - a complex data 
> structure that was initially defined in directive 1999/93/EC. For clarity, 
> the QS in 1.1.1 (which is incompatible with the directive) is called 
> surrogate QS.
>
> 1.1.3 Worth mentioning also evaluation of legality of surrogate QS by:
>
> a) the Data Protection Authority (legal name Valstybinė duomenų apsaugos 
> inspekcija - VDAI) ordered Omnitel to stop issuing surrogate QSs. This 
> order is still ignored (how and why can be discussed separately);
>
> b) the Supreme administrative court which ruled that surrogate QS violates 
> the Data protection law (an implementation of directive 95/46/EC, now 
> regulation 2016/679 - GDPR). This is also ignored (how and why can be 
> discussed separately).
> See case translation here: 
> https://journals.sas.ac.uk/deeslr/article/download/2142/2072/
>
> 1.1.4 based on the above, *misimplementation* of directive 1999/93/EC 
> means incorrect application of Article 2 (10) (and Article 8 and Annex I). 
> For technical details see the surrogate QC profiles here: 
> https://www.skidsolutions.eu/en/repository/CPS/
>
> 1.1.5 the regulation 910/2014 (eIDAS) *enhances and expands the acquis** of  
> Directive 1999/93/EB* - its *transitional measure* (Article 51 (2)) 
> provision the conditions for the recognition of QSs (issued according to 
> directive 1999/93/EC) as *qualified electronic signature certificates* 
> (QESC) under eIDAS.
>
> 1.1.6 the fact that SK ID Solutions together with its unaudited RA - *AB 
> Telia Lietuva*:
>
> a) within transitional period issued surrogate QSs only, means incorrect 
> application of eIDAS Article 51;
>
> b) after transitional period have been issuing surrogate QSs only, means 
> incorrect application of eIDAS Article 28 (1) - (3).
>
> 1.1.7 based on the above, *misimplementation* of eIDAS means incorrect 
> application of Article 5, 28 (1) - (2) and 51 (2).
>
>
> 1.2 *chaos* means complete *confusion* and *disorder*
>
> 1.2.1 when surrogate QCs are accepted as QESCs, it is *confusion*.
>
> 1.2.2 eIDAS has at least three directly applicable mechanisms to prevent 
> issuing surrogate QCs, but none of them worked as expected (*disorder*):
>
> a) TSP audit by CAB - surrogate QCs were accepted;
>
> b) TSP "qualified service" assessment by the Supervisory body - surrogate 
> QCs were accepted;
>
> c) Trust list management by the Scheme operator under the Commission 
> implementing decision 2015/1505 - surrogate QCs were accepted.
>
> 2. RE "*This sounds like you're specifically referring to actions taken 
> by Telia Company AB*"
>
> Correct. Telia Company AB is the driving force of an ”organized group”, 
> where
>
> a) The Swedish government creates "favorable conditions" in the countries 
> of Telia Company AB's business operation (at least easy access to local 
> governments is guaranteed);
>
> b) The Telia Company AB management partners with local governments so that 
> the doors of relevant institutions (agencies) are open to its local 
> affiliate  (remember "What's good for General Motors is good for the 
> country"?)
>
> https://m.facebook.com/story.php?story_fbid=10156465065383408&id=96251623407&m_entstream_source=video_home&player_suborigin=entry_point&player_format=permalink
>
> c) The Telia Company AB affiliate develops "special relationship" with 
> the  institutions so that at least supervision of its business is 
> completely "switched off", this includes lobbying any desired legislation 
> (surrogate QC is "locally legitimazed" despite of competing with other 
> national laws and EU directives and regulations.
>
> I must apologize for this schematic/simplified response covering 20+ years 
> of Telia Company AB's business practices in Baltics.
>
> If you google "Telia + corruption", almost all information will be about 
> Telia Company AB's (formerly TeliaSonera AB) "achievements" in teleco 
> markets, this is partly because of:
>
> - its huge propaganda machine on mass media and social networks;
>
> - private embassy in Brussels, e. g. see 
> https://www.linkedin.com/posts/skaitmeninio-sertifikavimo-centras_why-we-have-the-eidas-gdpr-misimplementation-activity-6747690541766504448-iYsc
>
> - naturally invisible/hard to understand trust services.
>
> Please let me know if you need more info or have any questions - the 
> information above is backed by publicly acessible evidence material from 
> official sources.
>
> Thanks,
> M.D.
>
> Sent from my Galaxy
>
>
> -------- Original message --------
> From: Moudrick Dadashov <[email protected]> 
> Date: 12/30/21 17:34 (GMT+02:00) 
> To: [email protected] 
> Cc: "[email protected]" <[email protected]>, "
> [email protected]" <[email protected]>, "[email protected]" <
> [email protected]> 
> Subject: Re: FW: RE: Public Discussion: Inclusion of Telia Root CA v2 
>
> Sure, Ryan, allow me 2-3 days as I’m fully booked by my grandchildren :)
>
> Thanks,
> M.D.
>
>
> On Thu, Dec 30, 2021, 06:00 Ryan Sleevi <[email protected]> wrote:
>
>>
>>
>> On Wed, Dec 29, 2021 at 9:33 AM Moudrick M. Dadashov <[email protected]> 
>> wrote:
>>
>>>
>>> If approved, this request will create a precedent of ”do like Telia” - a 
>>> practice that is widely used by Telia Company AB and its affiliates in the 
>>> trust services markets under eIDAS. That’s how the recent eIDAS & GDPR 
>>> misimplementation chaos started.
>>>
>>> I suggest this request be approved after the conversion of corporate 
>>> relationships into clearly identified, disclosed and audited specific PKI 
>>> participant roles.
>>>
>>
>> Moudrick,
>>
>> For those following, could you share more precise details (e.g. 
>> references to news articles or other discussions) about the "recent eIDAS & 
>> GDPR misimplementation chaos started"? This sounds like you're specifically 
>> referring to actions taken by Telia Company AB, and perhaps some more 
>> context/references would help understand your concern. 
>>
> -- 
> 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/CAMMZRrw30kcstFoUBKZBKtcDC_YYqkAr8BPBobdz44%3D9NwsnjQ%40mail.gmail.com
>  
> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAMMZRrw30kcstFoUBKZBKtcDC_YYqkAr8BPBobdz44%3D9NwsnjQ%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/ae0dda7a-3cc5-481e-9a56-3c1af92b8990n%40mozilla.org.

Reply via email to