I confirm Peter's comment and evaluation to be correct. Specifically that Telia hasn't used any third party RAs except in the mentioned client certificate cases. And that all other RA functions were operated internally by the Telia group so that all internal RA functions were covered under the WebTrust audit. In Enterprise RA cases it was technically constrained that each could only enroll SMIME certificates under pre-validated domains belonging to them. External RA case was outside of Mozilla context based on EKU values on subCA (and end-entity) level.
torstai 6. tammikuuta 2022 klo 20.56.32 UTC+2 [email protected] kirjoitti: > On Thu, Jan 6, 2022 at 8:00 AM Ryan Sleevi <[email protected]> wrote: > > > > > > > > On Thu, Jan 6, 2022 at 1:18 AM Moudrick M. Dadashov <[email protected]> > wrote: > >> > >> You asked if my comment was about Delegated Third Parties - sorry, no, > I had in mind the CA [1] and its RAs [] as defined in BRs. > > > > > > I'm not sure I understand this. An RA is a DTP. > > I think this is where some of the confusion is coming from. Not all > RAs are DTPs. In one way of describing PKI structure (or > participants), every certificate request first goes to a RA. The RA > validates the information, for example validates control of the > requested domains, then requests the CA to issue the certificate. The > RA and CA functions may be operated by the same entity, have the same > governance, and be part of the same audit. In this case the RA is not > a DTP, rather it is just a function of what in Mozilla terminology is > the "CA". > > From my reading of this thread, there are two kinds of RAs for Telia > CA. The first are RA functions operated by the Telia group. These RA > functions are covered under the WebTrust audit. The people operating > the RA functions are employed by various companies, but ultimately > Telia Company AB is stating that they have governance and management > oversight of these RA functions. The second are Enterprise RAs which > are only used for client certificates. From earlier in the thread, > "Telia Class 3 client certificates (which are outside of Mozilla > context) are using external RA." > > I'm hoping Telia reps can confirm that my understanding is correct. > > >> Audit scope > >> > >> "If my above understanding is correct, then I’m not fully sure your > argument here is correct. It’s certainly true that the RAs, which are DTPs, > need to be audited, but that doesn’t necessarily propagate to the scope of > the parent." > >> > >> My comment was about Pekka's argument, which is quite typical to Telia > Company AB and its affiliates, that their corporate ownership relationship > is directly apllicable to the CA operations, I believe this is > fundamentally wrong. > > > > > > I'm sorry, I'm still not sure I think I understand the substance of your > argument here, and it does seem like you're ascribing a particular malice > to Telia that appears to be unsubstantiated, at least at present. > > > >> > >> The CA has a single audit report and I’m OK with that, but, as I quoted > earlier, the audit report says: > >> > >> "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." > > > > > > Correct, this part is difficult to square with Pekka's remarks that they > were all part of the same audit scope, as the report does not appear to > substantiate this. That is, the WebTrust Illustrative Guidance provides > examples on how to disclose if no external RAs are involved, and that this > seems to highlight a disconnect that bears some clarification, at the > minimum. > > I agree. It would be helpful to clarify what functions any external > RA does for any certificate that falls within the Mozilla policy > (which includes at least server and e-mail end-entity certificates). > > Thanks, > Peter > -- 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/7c1d5082-cfce-45ae-aa9c-7be6e618d07bn%40mozilla.org.
