Re: s/MIME certs and authentication
(Same Pedro as before...it was another account) > > There's nothing that specifies the cert must be issued after the verifying > control or that issuance can't be part of the verification process. Although > this seems backwards, I still think it's compliant with the Mozilla policy. > Well.. According to Mozilla 2.2-1: "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." For me this means that for initial issuance the verification must occur before issuing the certificate, so the mail interaction must be previous to that. My sentence above was about renewals... where I think that it's reasonable to consider that the email was already validated and that the getting the renewal by accessing a mail is providing enough assurance. We could do otherwise, so issuance occurs after the user read the email and clicks a link or whatever, but I don't think it really makes a difference in terms of controlling the risk of giving a certificate to the wrong person, as you said "either you have access to the email or you don't". Cheers! ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: s/MIME certs and authentication
This is one of the reasons I wanted to raise the issue. Issuing the cert and delivering to the email seems like a pretty common way to verify email certs (either you have access to the email or you don't), but this is backwards from TLS. Is this particular process a violation of the Mozilla policy? Mozilla policy, Section 2.2 #2: "For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder's behalf. The CA's CP/CPS must clearly specify the procedure(s) that the CA employs to perform this verification." There's nothing that specifies the cert must be issued after the verifying control or that issuance can't be part of the verification process. Although this seems backwards, I still think it's compliant with the Mozilla policy. -Original Message- From: dev-security-policy On Behalf Of Matt Palmer via dev-security-policy Sent: Thursday, December 13, 2018 2:39 PM To: dev-security-policy@lists.mozilla.org Subject: Re: s/MIME certs and authentication On Thu, Dec 13, 2018 at 09:50:21AM -0800, pedro.wisekey--- via dev-security-policy wrote: > For S/MIME capability itself, we are required to ensure that "the > entity submitting the request controls the email account associated > with the email address referenced in the certificate", so by merely > making the process to require the user to access his email account to, > for example, download the renewed certificate it seems to be enough, > as any other method like a bounce-back message could probably get to the same result. That seems rather backwards. You're issuing the certificate and *then* validating control of the e-mail address. I doubt that issuing a TLS server certificate and then performing domain control validation would be considered acceptable, and I don't imagine there's enough of a difference in S/MIME certificates to make it acceptable for those, either. - Matt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: s/MIME certs and authentication
On Thu, Dec 13, 2018 at 10:53 AM pedro.wisekey--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Maybe we should set clear grounds on what is verified and how, not only in > the frequency. > > I agree and think that creating piecemeal requirements is a bad idea. The CAB Forum is working on forming an S/MIME working group to develop baseline requirements, but that will take a long time. Do others think it would be a good idea to create a set of interim Mozilla requirements for S/MIME validation? For S/MIME capability itself, we are required to ensure that "the entity > submitting the request controls the email account associated with the email > address referenced in the certificate", so by merely making the process to > require the user to access his email account to, for example, download the > renewed certificate it seems to be enough, as any other method like a > bounce-back message could probably get to the same result. > > This is an interesting idea, and it leads to a question I have about Symantec's legacy processes: In cases where the control of the email address was only validated at first issuance, was there some rationale for never revalidating? Also, how was the initial validation performed? But if we talk in general about Personal Certificates and the certificate > contains the full name and other identity attributes like the organization > name, it's far more complex and right now totally unregulated, and the CA > is expected to apply some controls to ensure that any of these attributes > remain correct over time... So some criteria will need to be set at some > point. > > Mozilla policy is only concerned with TLS and S/MIME. And of course, most of us we provide MPKI services to companies that manage > certificates for the employees using an email address of the domains owned > by the company, so we should be able to rely on their HR processes to > ensure that a person bearing a corporate email address is actually an > active employee, without needing to enforce additional checks on our side. > > In other words, the CA only needs to verify that the MPKI Subscriber controls the domain name. So not an easy topic you Raised, Jeremy... > > Best, > Pedro > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: s/MIME certs and authentication
Maybe we should set clear grounds on what is verified and how, not only in the frequency. For S/MIME capability itself, we are required to ensure that "the entity submitting the request controls the email account associated with the email address referenced in the certificate", so by merely making the process to require the user to access his email account to, for example, download the renewed certificate it seems to be enough, as any other method like a bounce-back message could probably get to the same result. But if we talk in general about Personal Certificates and the certificate contains the full name and other identity attributes like the organization name, it's far more complex and right now totally unregulated, and the CA is expected to apply some controls to ensure that any of these attributes remain correct over time... So some criteria will need to be set at some point. And of course, most of us we provide MPKI services to companies that manage certificates for the employees using an email address of the domains owned by the company, so we should be able to rely on their HR processes to ensure that a person bearing a corporate email address is actually an active employee, without needing to enforce additional checks on our side. So not an easy topic you Raised, Jeremy... Best, Pedro ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: s/MIME certs and authentication
On Wednesday, December 12, 2018 at 7:59:46 PM UTC-5, Jeremy Rowley wrote: > Some systems look like they verify the email address/domain name at issuance > and then never again for the same account. Other systems verify the email > address and domain every 825 days. The last set verifies the email address > each time a certificate is issued. I think each are equally compliant, but > the set-it-and-forget it method doesn't seem in the spirit of ensuring > control over the email address. Is there guidance on how often this > reverification should occur? We have implemented the 825-day rule from the SSL BRs to re-verify information for an S/MIME certificate. This rule is applied to the information in the subject DN and the email address/domain. As such, we have also implemented the 825-day reuse rule. This also allows the use of the same information for different certificate types. Bruce. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
