S/MIME certificate Subject

[James R Moir]

I understand Subject information (O, CN, L, C) for an S/MIME certificate must also be validated.

Mozilla policy - 2.2 'Validation Practices' says:

"All information that is supplied by the certificate subscriber MUST be verified by using an independent source of information or an alternative communication channel before it is included in the certificate."

I am able to obtain valid, trusted S/MIME certificate from a CA and request any details in Subject.

I simply use fake name, fake address - no checks are made for ID or identification numbers, or order placed from country in the Subject 'C'.

Email address is verified by simple email check, but all other fake data is signed.

S/MIME is not in transparency logs, so I am unable to check there to see the scale of the problem.

Is this a concern at all?

Jim

Jim

[Matthias Merkel]

We have used this in the past for our domain registrar backend services with the customer name as part of the CN. The CA seems to have only verified the email domain and O field, but never anything else.

This was one of the large CAs, which is generally known for their good compliance work. It is worth noting that they don't sell these certificates via their website publicly, you need to contact them for pricing first. 

This indicates that this is somewhat common practice. Maybe it's worth looking into as I can definitely see this being problematic if a phishing email is signed with a certificate claiming to be Microsoft or something similar. 

Matthias Merkel

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/VqO1FNjgYWNVMWuC5KSzivQZu9SIozSPnaMkKxIcn8MSuEaTCoHoIQaH_wSdP9l3G8k1jh_BW-wttwCMbXYW791DY24WGXjY8yZlWgpIizU%3D%40protonmail.com.

[James R Moir]

My certificate was also from a large CA (Digicert) and yes obtained through a local 'reseller'. It was cheaper to buy for my research, but still concerning that I can enter even joke names and addresses and have that added to a trusted certificate.

If only email is vetted, that should only be added.

I tried other CAs also, but ID or documentation was requested so I did not wish to provide forged documents.

Jim

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

[Ryan Sleevi]

Yeah, I think there's two parts to James' question:

1) Is this permitted by root program policies?

2) Is this permitted by industry standards / widely practiced by industry?

I'll tackle #2 first - the CA/Browser Forum has an S/MIME Certificate Working Group, which is open for anyone to apply as an Interested Party in and participate in the mailing list discussion, simply by  agreeing to abide by the Forum's IPR policy (and code of conduct). That doesn't allow you to dial in to the phone calls, but totally lets you post on the list or GitHub discussions.

Even if you can't join as a participant, you can still subscribe to a read-only view of the list, which is available at https://lists.cabforum.org/mailman/listinfo/smcwg-public , to be aware of the discussions. You can also raise specific questions at ques...@cabforum.org , although certainly, it's easiest if you're able to join as an Interested Party to engage in more interactive feedback and dialog.

To your question about policy, #1, for Mozilla the authoritative answer is obviously going to come from Ben and Kathleen. However, having been around when that language was drafted, the intent was to communicate that such practices were not allowed: that is, the CA must have some validation process in play for this information, and CAs must not simply "do whatever the user says". Obviously, though, while the expectations are arguably clear, CAs may find they have a lot of flexibility to argue for loopholes, and we know CAs tend to make a lot of mistakes if things aren't exactingly spelled out. So, it's messy here, and there's a lot of reliance on folks, such as James, to highlight issues, which Mozilla can then use to address with specific CAs (such as via incident reports) and with the industry (such as via CA communications)

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAKtZuQ5m3YOzhRYsON-UUk-_0TkojK%3DxisKu9JAoMUKa_5_n_A%40mail.gmail.com.

[Jeremy Rowley]

Could you give us more information about the specific reseller? Some of the smime resellers are appointed as RAs for the purpose of verifying identity in email certs. They can’t verify the email address itself nor can they verify identifies for non-email certs. Sounds like an RA isn’t living up to its obligations as we require “an alternate method of communication” to verify the details.

 

Jeremy

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHHLdMBFM5%2B%2BNapchZBRuWoMBpmQ0B9fZQWzJjNsXrh4Ow%40mail.gmail.com.

[James R Moir]

Thanks, Ryan.

I will look about joining the SMIME working-group.

I can not imagine that the result of that working-group would be that users can enter any information and have it blindly included in a trusted certificate.

For Item 1, the Mozilla policy seems clear. I would think root-programs all over would not want to allow random, unchecked data in CN/O/ST/L and be able to 'argue for loopholes'. I find it strange to be a small problem for an S/MIME certificate, but a bad revoke-cert problem if it was an SSL certificate.

Jim

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

[James R Moir]

Thanks, Jeremy.

This was purchased from 'sslmarket.com'.

No checks were made. I chose an address in London, England and a 'joke' name from there also.

No email or phone or document. I think payment was through a local processor where only card number and expiry were requested so they could not have seen my 'real' information there.

What should “an alternate method of communication” mean anyway?
Ask my name in a form then ask again through email or phone?

Other resellers/CAs asked at least for ID. Sure I could make a Photoshop-copy but at least they have then done some checks and care.

It does not give me great trust in Digicert that you would allow certificate reseller this power.

Jim

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

[Matthias Merkel]

With all due respect, our certificates were also from Digicert and while I believe we are a reseller, we certainly are not an RA. We have purchased these directly from DigiCert. The O and E fields have been verified, but the others (especially the CN) have not. 

I do believe this is a slightly different issue tho, as it sounds like Jim/James got a certificate with a fake O field (can you confirm?).

Regarding "Other resellers/CAs asked at least for ID. Sure I could make a Photoshop-copy but at least they have then done some checks and care.", I think that's not something that CAs will ever be able to fully mitigate. 

[Jeremy Rowley]

We are planning on making a change when there are updated requirements from the sMIME working group. For us, the alternative method of communication is usually just an email to the customer placing it. Ras generally verify the cert by using their relationship with the customer – again usually by sending an email to the sign up process. I agree that it’s not really a great process, but I wasn’t going to change it while new requirements are coming from CAB as the current process meets the literal language of the Mozilla policy. One reason we have Stephen Davidson so keen on the smime working group is because we’d like to see better requirements in this area.

[James R Moir]

Hello, Matthias.

Yes - O and CN both contained the fake name (CN had an short version I entered).

C and L were added based on the random data I entered, again not vetted.

I also agree that fake document issue cannot be fully prevented but I do not understand why it would still be 'ok' to take any detail and sign them.

Jim

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

[Jeremy Rowley]

They are verified through “an alternative method of communication”, which means an email confirming the details.  Note that the requirement does not say “prevent all fake O fields”. It says confirm the information using an alternative means of communication. If you send us certs with fake O fields, we’ll happily revoke per the revocation requirements.

 

From: Matthias Merkel <matt...@matthias.zone>
Sent: Thursday, July 1, 2021 10:53 AM
To: Jeremy Rowley <jeremy...@digicert.com>

[James R Moir]

Thanks, Jeremy.

This is interesting. I had no 'relationship' with the 'reseller' and I do not think that simple email to the customer to confirm is enough.
Waiting for a group to complete work when still signing fake information seems like a bad excuse, but I am not a CA. If i was, asking for photograph ID like other CAs do seems an easy way.

Do you have an idea of how many of these S/MIME certificates exist from these RA resellers with unvetted data signed in?

Jim

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

[Jeremy Rowley]

Well, define ‘unvetted’. I don’t think there are a lot without “an alternative email” and none where the email in the cert wasn’t vetted.

 

However, I think you are saying are there are a lot where there aren’t an OV TLS standard applied to the vetting. That’s difficult to say. We generally don’t sell smime retail (that only happens through partners) so we can verify our relationship to the customer before issuing the certs.  That generally involves more rigorous identity vetting as part of the relationship process.  For resellers, we see resellers as the partner, meaning we vet their identity when they sign up and confirm with them that the information is correct (they have to confirm via contract and via submission to the portal). The obligation is then passed down to them (via contract) to confirm organization information in the cert using the “alternative means of communication”. Note we also send an email directly to the email cert hold that confirms this info, which is an “alternative method of communication” by itself.

 

Like I said, I don’t love this process, which is why we have so many people involved in the smime WG.  

[James R Moir]

Hello, Jeremy

I would say 'unvetted' is 'not checked'. I typed a name into a box. Digicert signed it into a S/MIME certificate. I suppose you are saying that another email to ask if I actually meant to type that would be sufficient. I do no agree but I am not a CA and not a root program person.

I think if some CAs ask for identification and one does not, and pointing to loopholes and 'the guideance says' - I am not filled with trust.

(I don’t think there are a lot without “an alternative email”)

How can you be sure? You did not know my certificate was not done this way, how can you be certain all are not, from any 'reseller'?

I do not see more benefit in a discussion here. If you believe that blindly allowing signing of data into a certificate with no checks - that other CAs seem to do - then I suppose being the easiest CA to fool is 'ok'.

Jim

Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/BYAPR14MB2600BC8C4A680BEA3B7BF99B8E009%40BYAPR14MB2600.namprd14.prod.outlook.com.

[Ryan Sleevi]

Jeremy,

Just making sure I understand, and not trying to publicly drag you: It sounds like you're arguing that the requirement should be read as "{independent source of information} or {an alternative communication channel}", not "independent {source of information or an alternative communication channel}", and that because "alternative communication channel" is not restricted in what it can authorize (e.g. that Jane Doe works for ACME Widgets, as verified by ACME Widgets, but that ACME Widgets has been verified by an independent source of information"), this is fine?

I haven't done the full spluenking through the archives of past discussions, so I could very well be wrong here, but I don't think that was the intended result of the current language. That said, I also appreciate that the current language and policies here are pretty under-specified. Looking at how CP/CPS reviews have been performed, and the feedback offered to CAs, it doesn't seem consistent with the expectations, but perhaps you can share where in DigiCert's CP/CPS DigiCert discloses what validation practices they have? That might be the easiest path to understand this (specific) situation, as well as provide an opportunity for James and Matthias to look at other CA's CP/CPSes, to see how they also handle this. Certainly, the core of the WebTrust audit (not-SSL-BR) expects CP/CPS consistency to actual practice, so if there are deviations from what a CA has stated, that would still be an issue/incident, even for S/MIME.

[Jeremy Rowley]

Interesting. I’ve always read it as "{independent source of information} or {an alternative communication channel}", not "independent {source of information or an alternative communication channel}". That could  change things if the word “independent” was supposed to apply to both. 

 

Note that we actually sell four/five (depending on how you want to parse it) five different levels of authentication on sMIME certs. These fall under our Level 1 – rudimentary certs. We have separate systems (where Resellers are not RAs) for Level 1.5+ certs.  For this discussion, I’ll only cite the level 1 sections as these are the certs in question. These levels map to the NIST and FPKI defined levels of verification.

 

The CPS says:

Section 3.2.3: As specified in Section 3.2.2 (no identity verification other than control of the email address listed in the Certificate).

 

If you want to say these are “Enterprise” client certs then it says: “Through information derived from an ongoing business relationship with the applicant organization”, which is what resellers would fall under.

 

The other levels increase in complexity with Level 4 requiring a biometric.

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHFrrgi8CgR%2B%3Dv3Md4H9zbHND5tArpxJ%3D-PMmJ0dPmDWXA%40mail.gmail.com.

[Matthias Merkel]

I'm getting this message when I try to order one of them via CertCentral as our pre-validation has expired, which seems to conflict with the statement that no identity verification would be done on those certificates. Am I confusing the certificate type or does that mean that you need to have some organization verified - even if it's a different one than what's in the certificate? To be clear, I think that it'd be a good thing if it was in fact verified, but then that should be reflected in the CPS as well.

Is identity verification perhaps done for direct purchases, but not via certain resellers? 

[Jeremy Rowley]

There are org verified certs, which is why I mentioned we have several different levels of email certificates. A large part of the discussion will depend on the particular email cert type. I assumed we were discussing only the Level 1 certs, which maps to Federal Rudimentary levels of authentication.  These different levels of verification are reflected in the CPS. For example, org validation similar to OV is required for enterprise class client certs. The policy OID in the cert identifies the level of verification completed.  Personal Level 1, which is what resellers offer, are generally non-verified except via the alternative method of communication required and an email verification.

 

Jeremy

[Ryan Sleevi]

On Thu, Jul 1, 2021 at 2:11 PM Jeremy Rowley <jeremy...@digicert.com> wrote:

Interesting. I’ve always read it as "{independent source of information} or {an alternative communication channel}", not "independent {source of information or an alternative communication channel}". That could  change things if the word “independent” was supposed to apply to both. 

Well, I was mostly just trying to highlight the parsing ambiguities and make sure I understood which way you were parsing :)

The current language (in 2.2) goes back to Mozilla Policy 1.0 - https://wiki.mozilla.org/CA:CertificatePolicyV1.0 - which was from Frank and Gerv ( https://bugzilla.mozilla.org/show_bug.cgi?id=233453 ). Frank explained some of the philosophy with the language in https://web.archive.org/web/20060118061733/http://www.hecker.org/mozilla/cert-policy-approved (unfortunately, www.hecker.org links no longer work), along with the related post archive from (~2006) that explained the iterations https://web.archive.org/web/20060202105952/http://hecker.org/ and a more expansive musing of the CA<->Identity expectations in https://web.archive.org/web/20060202105952/http://www.hecker.org/mozilla/business-of-cas

In the policy, there have been related issues raised around what the subject values should be vetted to. https://github.com/mozilla/pkipolicy/issues/200 (still open) and https://github.com/mozilla/pkipolicy/issues/114 (tackled in 2.6) are the most relevant 

I mention all of this because while I think DigiCert's conclusion is less than ideal, it's also rather understandable: at present, there's no (standard, interoperable) assurance whatsoever of any identity asserted in e-mail, short of the e-mail address, full stop. Mozilla does impose revocation requirements c.f. Section 6.2 of their policy ( https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#62-smime ), and that requires consistency with the CP/CPS (#7) and if "any of the information appearing in the certificate is not accurate" (#8), but I do think it's a valid (if unfortunate) question about whether the lack of rules re: other DN fields means that they are fundamentally accurate (because they are no rules) or if they're inaccurate (because users would reasonably be misled)

As Frank's original policy makes clear, the idea was that these practices and disclosures would be reviewed when onboarding CAs, or (as later Mozilla Policies came about), if the CA changes the policy. Mozilla, and the Mozilla Community, would evaluate whether or not a CAs' stated procedures (such as "we don't validate these fields") matched the intent/user needs, and if not, either deny addition or remove inclusion. Unfortunately, we know that the ideal (of careful, thorough evaluation) hasn't always held up - especially as CAs increasingly rely on audits rather than browser evaluation, and thus, the S/MIME WG work now on providing slightly-more-interoperable approaches to validation (although, unfortunately, still wildly subjective/variable between CAs).

This is the very long-winded way of saying that "While I don't believe this is the intended result, but I don't believe this is presently explicitly prohibited", at least by Mozilla Policy.

Google's GMail, on the other hand, has a slightly more rigorous policy for CAs, as shown in https://support.google.com/a/answer/7300887?hl=en#zippy=%2Cend-entity-certificate

Any Subject Relative Distinguished Names other than email address must be rigorously validated before issuance, using a publicly documented and audited procedure.  Refer to Section 3.2.3 “Authentication of Individual Identity” of the CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates, version 1.3.2 or greater for an acceptable procedure.

While "rigorously validated" might be seen as a bit subjective ("But we sent the Applicant _three_ emails, that's how rigorous we are!"), the example provided of an acceptable procedure makes it somewhat clearer that it doesn't pass the sniff test. 

That said, I (really) can't speak for GMail, other than noting the practice would appear to be a violation of their stated expectations.

[Matthias Merkel]

Thanks, that clears up a lot of the confusion for me.

I think there is some concern in having certificates with a validated O attribute and others with an unvalidated one - I doubt many people will be looking at the OID when checking a certificate and this could cause the assumption that the attribute is always validated, but that seems to be solely my opinion, not actual violation of policy.

Based on your previous emails it seems like you have a similar view on this and are waiting for discussions to complete in the CABF so that seems like a good step forward.

[Stephen Davidson]

I’ll take the opportunity to follow up on Ryan’s introduction to the CA/Browser Forum’s S/MIME Certificate Working Group.

 

https://cabforum.org/working-groups/smime-certificate-wg/

 

The SMCWG is working on draft S/MIME Baseline Requirements that will address:

-  Verification of control over email addresses
-  Key management and certificate lifecycle
-  Certificate profiles for S/MIME certificates and Issuing CA certificates
-  CA operational practices, physical/logical security, etc.

 

In addition, the S/MIME Baseline Requirements will also address identity validation for natural persons and legal entities in the context of S/MIME certificates. 

 

Membership of the SMCWG includes Certificate Issuers, Certificate Consumers (like mail clients), Interested Parties and Associate Members (such as audit and standards entities).  Membership information is provided in the link above.  We welcome those with an interest in S/MIME.  The SMCWG’s activities may also be followed at https://lists.cabforum.org/mailman/listinfo/smcwg-public

 

The SMCWG is working on several profiles ranging from “legacy” to “strict” with the goal of documenting reasonable practices for S/MIME issuance and bringing them into an auditable framework.  In part, the current “legacy” flexibility is required due to other uses cases (such as document signing) that may currently overlap the emailProtection EKU (see more here on that topic).

 

The draft profiles address different user Subject types, including mailbox only, organization, individual, and sponsored (which incorporates Enterprise RAs, where Org and domain information used in the Subject is fixed by the CA, but that Org’s RA can validate certain other information about the holders of individual certificates, typically employees).  Where possible the S/MIME Baseline Requirements will leverage the verification procedures defined in other CABF or industry standards.

 

Regards, Stephen

Chair of the CABF S/MIME Certificate Working Group

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAKtZuQ6-r5Zsadh5zJ4oqgofBr_f4nrW1LAFr2Vy3goFogUV-Q%40mail.gmail.com.