RE: DigiCert Assured ID Root CA and Global Root CA EV Request

[Jeremy Rowley via dev-security-policy]

* The TERENA SSL CA 3 subordinate has misissued a number of certificates [3], 
most of which are not revoked. 

- We can revoke these. I have no issue remediating them.  I didn’t realize 
these were an ongoing concern. 

 

*  DigiCert’s response in this bug states “We were under the impression from 
previous communications with Mozilla that certain types of errors identified 
did not require certificate revocation. It would help if Mozilla could indicate 
which certificate errors are believed to require revocation. We will then 
review the lists to see which certificates need to be revoked.” I do not 
believe that Mozilla should create such a list, and we have set a precedent for 
requiring revocation for at least some of the errors that are identified - e.g. 
metadata in subject fields [4].

- That’s fine, but the answer still stands as why we didn’t revoke them before. 
Gerv told us we didn’t need to revoke them because they didn’t represent an 
actual security concern. I can go find the email if that helps.


* In addition, DigiCert previously reported that they had addressed the problem 
of metadata in subject fields for certificates issued by the Terena subordinate 
[5].

- Yes. This should be addressed. Unless you are expecting them to be revoked 
now? 



* Linters identify a large number of misissued certificates under the DigiCert 
SHA2 Secure Server CA intermediate [6]. Many of these are false positives (e.g. 
ZLint expects CN and SAN fields to be lowercased), but some are not and of 
those many are not revoked - e.g. [7].


Thanks a ton for the breakdown. We’ll get these taken care of where it’s not a 
false positive. I think there are only 2-3 that are not false positives, with 2 
not previously discussed. 

 

Here’s the breakdown:


   FATAL: x509: RSA modulus is not a positive number 



Bad reading of the BRs. The BRs say the range should be between 2^16+1 and 
2^256-1. The team implementing this thought saw SHOULD and thought it was 
optional. They missed the sentence before which says the public exponent MUST 
be equal to 3 or more. I’ll file and incident report on this.

 

 


   FATAL: asn1: structure error: integer not minimally-encoded 

 


I think this one is a false positive? It’s caused by padded zeros which  aren’t 
expressly prohibited. Want us to revoke these?

 

 


 ERROR: The common name field in subscriber certificates must include only 
names from the SAN extension 

This one is a false positive

 

ERROR: DNSNames must have a valid TLD

This is a false positive

 

ERROR: The 'Organization Name' field of the subject MUST be less than 64 
characters

This is one of the issues mentioned above. We can revoke all of these. We 
didn’t know Mozilla was waiting on that.

 


 

ERROR: CAs MUST NOT issue subscriber certificates with validity periods longer 
than 39 months regardless of circumstance.

False positive

 

 ERROR: The country name field MUST contain the two-letter ISO code for the 
country or XX 

Grr.. I dislike this one (XK was used instead of XX). Although recognized as a 
temporary code for Kosovo, technically XK is not an official ISO code so it 
violates the strict letter of the law. We’ll revoke these.

 

ERROR: Subject name fields must not contain '.','-',' ' or any other indication 
that the field has been omitted 

False positive. The BRs say “All other optional attributes, when present within 
the subject field, MUST contain information that has  been verified by the CA. 
Optional attributes MUST NOT contain metadata such as ‘.’, ‘-‘, and ‘ ‘ (i.e. 
space)  characters, and/or any other indication that the value is absent, 
incomplete, or not applicable.” With the strict wording policy that seems in 
effect, organizationalUnit is not “All other optional attributes”. It’s a 
defined attribute and thus cannot be “other”.

 

ERROR: Explicit text has a maximum size of 200 characters

False positive I think…. 

 

 


ERROR: Subscriber Certificates issued after 1 July 2016 but prior to 1 March 
2018 MUST have a Validity Period no greater than 39 months. 

 


False positive

 

 ERROR: Subscriber Certificate: subject:localityName MUST appear if 
subject:organizationName, subject:givenName, or subject:surname fields are 
present but the subject:stateOrProvinceName field is absent. 

 


Wow. I hadn’t seen this. It’ll be revoked and we’ll look at what happened.

 

 

* CPS section 3.2.2 did not, in my opinion, adequately specify the procedures 
employed to perform email address verification as required by Mozilla policy 
section 2.2(2). The latest update addressed this.
- This is an issue related to the fact there is no policy on s/MIME. We updated 
it with more specificity, of course, but I’d love to see a real s/MIME policy.

 

Thanks Wayne. I can confirm we will revoke all mis-issued certs.

 

 

From: Wayne Thayer  
Sent: Thursday, December 13, 2018 5:34 PM
To: Jeremy Rowley 
Cc: Ryan Sleevi ; mozilla-dev-security-policy 

Subject: Re: DigiCert

Re: DigiCert Assured ID Root CA and Global Root CA EV Request

[Wayne Thayer via dev-security-policy]

My main concern with this request is the misissued certificates identified
by linters that have not been revoked - I have included my comments and
links from the original message below.

It appears that DigiCert is not planning to remediate these certificates -
can a representative from DigiCert confirm that?

If these certificates are not revoked, I feel that it would be consistent
with our treatment of other CAs to deny this request. I would appreciate
everyone's opinion on that, and also if you think that the amount of
misissuance is reason enough to deny this request, even if the misissuance
is remediated.

=
* The TERENA SSL CA 3 subordinate has misissued a number of certificates
[3], most of which are not revoked. DigiCert’s response in this bug states
“We were under the impression from previous communications with Mozilla
that certain types of errors identified did not require certificate
revocation. It would help if Mozilla could indicate which certificate
errors are believed to require revocation. We will then review the lists to
see which certificates need to be revoked.” I do not believe that Mozilla
should create such a list, and we have set a precedent for requiring
revocation for at least some of the errors that are identified - e.g.
metadata in subject fields [4].
* In addition, DigiCert previously reported that they had addressed the
problem of metadata in subject fields for certificates issued by the Terena
subordinate [5].
* Linters identify a large number of misissued certificates under the
DigiCert SHA2 Secure Server CA intermediate [6]. Many of these are false
positives (e.g. ZLint expects CN and SAN fields to be lowercased), but some
are not and of those many are not revoked - e.g. [7].
* CPS section 3.2.2 did not, in my opinion, adequately specify the
procedures employed to perform email address verification as required by
Mozilla policy section 2.2(2). The latest update addressed this.

[3]
https://crt.sh/?caid=1687&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01

> [4] https://crt.sh/?id=629259396&opt=cablint
>
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1397958
[6]
https://crt.sh/?caid=1191&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
[7] https://crt.sh/?id=286404787&opt=zlint
=

On Thu, Nov 29, 2018 at 4:17 PM Wayne Thayer  wrote:

> I would appreciate it if we could move the discussion of exceptions to the
> deadline for revoking certificates containing underscores to a new thread.
>
> As it relates to this request, any failure to meet the revocation deadline
> would trigger the creation of an incident bug. (that is unless we as a
> community decide otherwise)
>
> I am not of the opinion that the existence of such a bug would change the
> outcome of this discussion. If others feel that it might, I am not opposed
> to holding the discussion open. Meanwhile, i'd suggest we stick to
> discussing the current facts of this request.
>
> - Wayne
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA Communication: Underscores in dNSNames

[Wayne Thayer via dev-security-policy]

On Sat, Dec 8, 2018 at 12:50 PM pilgrim2223--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> thanks for the suggestions.
>
> We are exploring the OCSP and CRL checks. It has potential.
>
> Have you determined if these applications perform revocations checks, or
if those checks can be blocked?

>
> As to getting certs from a different root, that wouldn't help us. We have
> no Technical reason to keep underscored certs and are happy to get rid of
> them, it is simply the effort required and the timeline given that are an
> issue.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Underscore characters and DigiCert

[Wayne Thayer via dev-security-policy]

I also don't think removing these roots is a good solution because:

* To Ryan's point, it's too late to actually get them removed on Mozilla's
current release cycle.
* Again echoing Ryan's comments, there are a lot of consumers of NSS and
abruptly yanking these roots to work around the ballot SC12 requirement
could be very disruptive, even if it doesn't affect Firefox. We might not
approve the request, or at least not quickly enough to meet the goal.
* As I understand it, this workaround wouldn't help all DigiCert customers
who are having trouble meeting the SC12 deadline. While the numbers would
be smaller, DigiCert would still be dealing with an incident (I disagree
with Ryan's comments in another thread that each customer for whom
revocation is delayed constitutes a separate incident).

- Wayne

On Thu, Dec 13, 2018 at 4:16 PM Ryan Sleevi  wrote:

> To expand: You would like to request removal and then it be treated as if
> you’re already removed, correct?
>
> I think for the reasons Wayne outlined, that would be detrimental to the
> ecosystem as a whole. For example, the request for removal might actually
> be denied (!!!) because of the outsize impact it could have on Mozilla
> Firefox/NSS users.
>
> 1) Mozilla blocks the roots via OneCRL, disrupting all existing
> whitelisted certificates. I’m sure Apple would be very displeased by this.
> 2) Mozilla removes the roots in a future update. This takes time to
> develop, release, and distribute - and during that time, clients with the
> ongoing trust (including ESR versions) would be impacted. It also suffers
> the Apple problem (for impact), which would need to be addressed.
> 3) Mozilla acknowledges the request but doesn’t take steps to remove -
> this has all the current downsides, but without any expectations of
> DigiCert abiding by the program requirements.
>
> For that reason, the best answer would seem to be that if DigiCert were to
> make that request, Mozilla would deny it, so that DigiCert would be clear
> as to the continued expectation to abide by the program requirements, until
> such a time as a workable solution was identified, reviewed, developed and
> implemented, and shipped.
>
> Of course, that no doubt sounds a bit odd, so if denying wasn’t an option
> - that is, if it had to be treated like a compromised root with an
> emergency update of some form - then it seems the answer should also be to
> treat the organization as one that can’t control their root, and treat it
> like an emergency update.
>
> These are all example responses to your specific request, and a light
> exploration about some of the consequences. I have no doubt that, as a CA,
> it’d be preferable to know exactly what would or could happen in these root
> removal requests. I don’t believe the SHA-1 process for those was at all
> beneficial for the community, and it had seemed like CAs had recognized
> that and would be unlikely to do it again. If we think this is something to
> formalize, then approaches like Microsoft’s - which contractually forbid
> it, add timelines for processing, and set expectations for ongoing audits
> for years after the “removal” in order to protect users, is a better model.
> In the context of Mozilla, which lacks such a contractual lever in its
> policy, I would suggest an approach that treats such requests as:
> 1) Best effort to remove individual roots, with an expectation that audits
> will continue until it is “safe” to stop and all policy obligations met
> 2) If the above is breached/violated, then treat it as removing all of
> that organizations and affiliates roots (that is, treating it like
> organization compromise)
>
> Hopefully, given the reasons above, that seems like an eminently
> reasonable policy position to take. Deliberately introducing issues like
> that merely externalizes the risks, and so there needs to be appropriate
> balances - whether contractual, financial, or political - to offset those
> externalized costs. Similarly, allowing such actions makes the inclusion of
> a root that much more dangerous, and thus gives further incentive to deny
> organizations that have demonstrated such patterns future roots, given the
> risks.
>
> On Thu, Dec 13, 2018 at 5:15 PM Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Can we request removal of these roots now? This seems very similar to the
>> SHA1 situation where CAs requested root removal and then treated the root
>> as
>> private, regardless of the trust in older platforms.
>>
>> -Original Message-
>> From: dev-security-policy 
>> On
>> Behalf Of Wayne Thayer via dev-security-policy
>> Sent: Thursday, December 13, 2018 3:11 PM
>> To: mozilla-dev-security-policy
>> 
>> Subject: Re: Underscore characters and DigiCert
>>
>> There are currently no program requirements for roots that have had their
>> websites trust bit turned off or been removed from NSS, but this is an
>> open
>> area of concern [1]. When a root is disable

Re: Underscore characters and DigiCert

[Ryan Sleevi via dev-security-policy]

To expand: You would like to request removal and then it be treated as if
you’re already removed, correct?

I think for the reasons Wayne outlined, that would be detrimental to the
ecosystem as a whole. For example, the request for removal might actually
be denied (!!!) because of the outsize impact it could have on Mozilla
Firefox/NSS users.

1) Mozilla blocks the roots via OneCRL, disrupting all existing whitelisted
certificates. I’m sure Apple would be very displeased by this.
2) Mozilla removes the roots in a future update. This takes time to
develop, release, and distribute - and during that time, clients with the
ongoing trust (including ESR versions) would be impacted. It also suffers
the Apple problem (for impact), which would need to be addressed.
3) Mozilla acknowledges the request but doesn’t take steps to remove - this
has all the current downsides, but without any expectations of DigiCert
abiding by the program requirements.

For that reason, the best answer would seem to be that if DigiCert were to
make that request, Mozilla would deny it, so that DigiCert would be clear
as to the continued expectation to abide by the program requirements, until
such a time as a workable solution was identified, reviewed, developed and
implemented, and shipped.

Of course, that no doubt sounds a bit odd, so if denying wasn’t an option -
that is, if it had to be treated like a compromised root with an emergency
update of some form - then it seems the answer should also be to treat the
organization as one that can’t control their root, and treat it like an
emergency update.

These are all example responses to your specific request, and a light
exploration about some of the consequences. I have no doubt that, as a CA,
it’d be preferable to know exactly what would or could happen in these root
removal requests. I don’t believe the SHA-1 process for those was at all
beneficial for the community, and it had seemed like CAs had recognized
that and would be unlikely to do it again. If we think this is something to
formalize, then approaches like Microsoft’s - which contractually forbid
it, add timelines for processing, and set expectations for ongoing audits
for years after the “removal” in order to protect users, is a better model.
In the context of Mozilla, which lacks such a contractual lever in its
policy, I would suggest an approach that treats such requests as:
1) Best effort to remove individual roots, with an expectation that audits
will continue until it is “safe” to stop and all policy obligations met
2) If the above is breached/violated, then treat it as removing all of that
organizations and affiliates roots (that is, treating it like organization
compromise)

Hopefully, given the reasons above, that seems like an eminently reasonable
policy position to take. Deliberately introducing issues like that merely
externalizes the risks, and so there needs to be appropriate balances -
whether contractual, financial, or political - to offset those externalized
costs. Similarly, allowing such actions makes the inclusion of a root that
much more dangerous, and thus gives further incentive to deny organizations
that have demonstrated such patterns future roots, given the risks.

On Thu, Dec 13, 2018 at 5:15 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Can we request removal of these roots now? This seems very similar to the
> SHA1 situation where CAs requested root removal and then treated the root
> as
> private, regardless of the trust in older platforms.
>
> -Original Message-
> From: dev-security-policy 
> On
> Behalf Of Wayne Thayer via dev-security-policy
> Sent: Thursday, December 13, 2018 3:11 PM
> To: mozilla-dev-security-policy
> 
> Subject: Re: Underscore characters and DigiCert
>
> There are currently no program requirements for roots that have had their
> websites trust bit turned off or been removed from NSS, but this is an open
> area of concern [1]. When a root is disabled or removed, there is no
> protection for Firefox users who haven't updated to a current version, nor
> for any of the other consumers of our root store until they update.
>
> However, that doesn't apply here. These roots are still in the Mozilla root
> store and trusted for TLS, and some of them will be for quite a while due
> to
> the whitelisted Apple & Google intermediates [2]. It is clear that Mozilla
> policy, and in-turn the BRs, still apply to these roots.
>
> Should DigiCert decide not to revoke certificates containing underscores by
> the 15-Jan deadline in SC12, including those chaining to distrusted
> Symantec
> roots, I plan to treat it as an incident. As with any incident, full
> disclosure is the expectation.
>
> - Wayne
>
> [1] https://github.com/mozilla/pkipolicy/issues/124
> [2] https://wiki.mozilla.org/CA/Additional_Trust_Changes#Symantec
>
> On Wed, Dec 12, 2018 at 5:54 PM Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:

Re: s/MIME certs and authentication

[Pedro Fuentes via dev-security-policy]

(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

[Jeremy Rowley via dev-security-policy]

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: Underscore characters and DigiCert

[Jeremy Rowley via dev-security-policy]

Can we request removal of these roots now? This seems very similar to the
SHA1 situation where CAs requested root removal and then treated the root as
private, regardless of the trust in older platforms. 

-Original Message-
From: dev-security-policy  On
Behalf Of Wayne Thayer via dev-security-policy
Sent: Thursday, December 13, 2018 3:11 PM
To: mozilla-dev-security-policy

Subject: Re: Underscore characters and DigiCert

There are currently no program requirements for roots that have had their
websites trust bit turned off or been removed from NSS, but this is an open
area of concern [1]. When a root is disabled or removed, there is no
protection for Firefox users who haven't updated to a current version, nor
for any of the other consumers of our root store until they update.

However, that doesn't apply here. These roots are still in the Mozilla root
store and trusted for TLS, and some of them will be for quite a while due to
the whitelisted Apple & Google intermediates [2]. It is clear that Mozilla
policy, and in-turn the BRs, still apply to these roots.

Should DigiCert decide not to revoke certificates containing underscores by
the 15-Jan deadline in SC12, including those chaining to distrusted Symantec
roots, I plan to treat it as an incident. As with any incident, full
disclosure is the expectation.

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues/124
[2] https://wiki.mozilla.org/CA/Additional_Trust_Changes#Symantec

On Wed, Dec 12, 2018 at 5:54 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hey all,
>
> We're working towards revoking certs with underscore characters in the 
> domain name, per SC12, but I had a question about legacy Symantec 
> systems and Mozilla. These particular roots are no longer trusted for 
> TLS certs in Google or Mozilla, which means the applicability of the 
> BRs is dubious. The roots are shortly being removed from Microsoft and 
> Apple, although that's more of an FYI rather than something with 
> direct bearing on the Mozilla community. If the roots are no longer 
> trusted for TLS in Mozilla, is there any requirement to revoke the certs
issued under those roots?
>
>
>
> My initial thought is no as this is similar to what Comodo did with 
> their request to remove a SHA1 root (and what DigiCert did with one of 
> the Verizon roots). Note these are still flagged by zlint because they 
> are trusted in older systems. Because the situation is slightly 
> different with the way distrust was technically implemented, I wanted 
> to see if there were any concerns with the community about treating 
> these as private going forward, similar to the SHA1 roots.  Thoughts?
>
>
>
> Jeremy
>
>
___
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: Underscore characters and DigiCert

[Wayne Thayer via dev-security-policy]

There are currently no program requirements for roots that have had their
websites trust bit turned off or been removed from NSS, but this is an open
area of concern [1]. When a root is disabled or removed, there is no
protection for Firefox users who haven't updated to a current version, nor
for any of the other consumers of our root store until they update.

However, that doesn't apply here. These roots are still in the Mozilla root
store and trusted for TLS, and some of them will be for quite a while due
to the whitelisted Apple & Google intermediates [2]. It is clear that
Mozilla policy, and in-turn the BRs, still apply to these roots.

Should DigiCert decide not to revoke certificates containing underscores by
the 15-Jan deadline in SC12, including those chaining to distrusted
Symantec roots, I plan to treat it as an incident. As with any incident,
full disclosure is the expectation.

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues/124
[2] https://wiki.mozilla.org/CA/Additional_Trust_Changes#Symantec

On Wed, Dec 12, 2018 at 5:54 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hey all,
>
> We're working towards revoking certs with underscore characters in the
> domain name, per SC12, but I had a question about legacy Symantec systems
> and Mozilla. These particular roots are no longer trusted for TLS certs in
> Google or Mozilla, which means the applicability of the BRs is dubious. The
> roots are shortly being removed from Microsoft and Apple, although that's
> more of an FYI rather than something with direct bearing on the Mozilla
> community. If the roots are no longer trusted for TLS in Mozilla, is there
> any requirement to revoke the certs issued under those roots?
>
>
>
> My initial thought is no as this is similar to what Comodo did with their
> request to remove a SHA1 root (and what DigiCert did with one of the
> Verizon
> roots). Note these are still flagged by zlint because they are trusted in
> older systems. Because the situation is slightly different with the way
> distrust was technically implemented, I wanted to see if there were any
> concerns with the community about treating these as private going forward,
> similar to the SHA1 roots.  Thoughts?
>
>
>
> Jeremy
>
>
___
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

[Matt Palmer via dev-security-policy]

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

Re: s/MIME certs and authentication

[Wayne Thayer via dev-security-policy]

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

[pedro.wisekey--- via dev-security-policy]

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

AW: s/MIME certs and authentication

[Buschart, Rufus via dev-security-policy]

We do re-verify on every re-issuance and do not re-use verification 
information. But we are probably not the most typical example, as all our 
verification information are coming from HR systems.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany 
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann 
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive 
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, 
Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; 
Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; 
WEEE-Reg.-No. DE 23691322

> -Ursprüngliche Nachricht-
> Von: dev-security-policy  Im 
> Auftrag von Jeremy Rowley via dev-security-policy
> Gesendet: Donnerstag, 13. Dezember 2018 02:00
> An: mozilla-dev-security-policy 
> 
> Betreff: s/MIME certs and authentication
> 
> Now that the Symantec TLS distrust is essentially behind us, we're working on 
> migrating all of the s/MIME certificates to DigiCert
> hierarchies. Once this is complete, the browsers can remove the legacy 
> Symantec roots completely. In my new compliance role, I'm
> looking at how to create a smooth, but compliant, transition process. One 
> major question I had while reviewing some of the systems is
> the frequency of s/MIME cert reverification. Nothing is specified in the 
> policy that I could see. I thought I'd raise the question here to
> see if there's a policy somewhere else or if Mozilla wants to consider an 
> official policy in one of its next updates.
> 
> 
> 
> 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?
> 
> 
> 
> Thanks for the input.
> 
> Jeremy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Maximal validity of the test TLS certificate issued by a private PKI system

[Sándor dr . Szőke via dev-security-policy]

2018. december 13., csütörtök 7:35:32 UTC+1 időpontban Dean Coclin a következőt 
írta:
> My opinion:
> The CA/B Forum Baseline Requirements only apply to certificates which chain 
> to publicly trusted roots. This is made clear in the preamble of the 
> document: 
> 
> This document describes an integrated set of technologies, protocols, 
> identity-proofing, lifecycle management, and auditing requirements that are 
> necessary (but not sufficient) for the issuance and management of 
> Publicly-Trusted Certificates; Certificates that are trusted by virtue of the 
> fact that their corresponding Root Certificate is distributed in 
> widely-available application software.
>  
>  The BRs do not apply to certificate issuance from non publicly trusted 
> hierarchies.
> Dean CoclinCA/B Forum Vice-Chair
>  
>

Dear All,
thank you for your answers.

I confirm the followings:
- Microsec operates Test hierarchies consisting of test root CA-s and test 
intermediate CA-s which are used exclusively for test purposes.
- Microsec has never issued and will never issue any live certificates from 
these test systems.
- the test root CAs has never been and will never be submitted for inclusion in 
the Mozilla root program or in any other root programs
- Microsec never issues test certificates for the purpose of domain validation 
according to the BR 3.2.2.4.9 for life TLS certificates

By keeping these rules Microsec may issue test certificates with validity 
exceeding the 30 days.
___
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

[Bruce via dev-security-policy]

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

Re: Test website monitor

[Rob Stradling via dev-security-policy]

Hi Rufus.  I'm not aware of any root program or CABForum requirement 
that supports your interpretation.

On 13/12/2018 12:26, Rufus Buschart wrote:
> Very nice! Are you sure, that this requirement is only valid for "Root 
> CAs"? I was always under the impression, that such a test web site needs 
> to be hosted for every "Issuing CA that chains up to a publicly trusted 
> Root CA".
> 
> /Rufus
> 
> What we do in life, echoes in eternity.
> ===
> Rufus J.W. Buschart
> Anna-Pirson-Weg 1c
> 91052 Erlangen
> Phone: +49 (0)9131 - 530 15 85
> Mobile: +49 (0)152 - 228 94 134
> Web: http://www.buschart.de
> 
> 
> Am Do., 13. Dez. 2018 um 12:18 Uhr schrieb Rob Stradling 
> mailto:r...@sectigo.com>>:
> 
> Thanks to Kathleen for suggesting/requesting this new crt.sh feature...
> 
> To facilitate compliance checking for the 3 test websites that BR 2.2
> [1] requires for each root certificate, I've created this new report:
> 
> https://crt.sh/test-websites
> 
> Anything in red on this page represents either: a
> misconfigured/non-compliant test website, a bug in my code, or an
> interesting edge case worthy of further discussion.
> 
> Each test website is currently rechecked every 10 minutes.  The code
> for
> the checker application is available at [2].
> 
> 
> [1]
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.9.pdf
> "2.2. PUBLICATION OF INFORMATION
> ...
> The CA SHALL host test Web pages that allow Application Software
> Suppliers to test their software with Subscriber Certificates that
> chain
> up to each publicly trusted Root Certificate. At a minimum, the CA
> SHALL
> host separate Web pages using Subscriber Certificates that are (i)
> valid, (ii) revoked, and (iii) expired."
> 
> [2] https://github.com/crtsh/test_websites_monitor
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> Sectigo Limited
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "crt.sh" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to crtsh+unsubscr...@googlegroups.com
> .
> To post to this group, send an email to cr...@googlegroups.com
> .
> To view this discussion on the web, visit
> 
> https://groups.google.com/d/msgid/crtsh/2615a68e-9626-8d77-86f4-78dd64c04b3d%40sectigo.com.
> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> You received this message because you are subscribed to the Google 
> Groups "crt.sh" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to crtsh+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to cr...@googlegroups.com 
> .
> To view this discussion on the web, visit 
> https://groups.google.com/d/msgid/crtsh/CAFnsKvjnAT6RZohgQNUEi5%3Dzxp-qDGxCi_K5jKOjwpvA%3DPZQAA%40mail.gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
Rob Stradling
Senior Research & Development Scientist
Email: r...@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Test website monitor

[Rob Stradling via dev-security-policy]

Thanks to Kathleen for suggesting/requesting this new crt.sh feature...

To facilitate compliance checking for the 3 test websites that BR 2.2 
[1] requires for each root certificate, I've created this new report:

https://crt.sh/test-websites

Anything in red on this page represents either: a 
misconfigured/non-compliant test website, a bug in my code, or an 
interesting edge case worthy of further discussion.

Each test website is currently rechecked every 10 minutes.  The code for 
the checker application is available at [2].


[1] https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.9.pdf
"2.2. PUBLICATION OF INFORMATION
...
The CA SHALL host test Web pages that allow Application Software 
Suppliers to test their software with Subscriber Certificates that chain 
up to each publicly trusted Root Certificate. At a minimum, the CA SHALL 
host separate Web pages using Subscriber Certificates that are (i) 
valid, (ii) revoked, and (iii) expired."

[2] https://github.com/crtsh/test_websites_monitor

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy