Re: Next CA Communication

2017-03-20 Thread Kathleen Wilson via dev-security-policy 
On Monday, March 20, 2017 at 2:43:22 PM UTC-7, Gervase Markham wrote:
> On 20/03/17 15:33, Kathleen Wilson wrote:
> >> * Action 7: some of the BR Compliance bugs relate to CAs which are no
> >> longer trusted, like StartCom. If StartCom does become a trusted CA
> >> again, it will be with new systems which most likely do not have the
> >> same bugs. Should we close the StartCom compliance bugs?
> > 
> > Yes, I think that makes sense.
> 
> OK, I've closed the StartCom and ANSSI bugs.

Thanks!

I also finished updating bugs:
https://wiki.mozilla.org/CA/ca-bugs
https://wiki.mozilla.org/CA_Bug_Triage#CA_Certificate_Issuance_Problems_and_Incidents


> 
> >> * Action 8: Can we provide more structure here, by perhaps putting some
> >> boilerplate text in the answer box or something like that? Or at least
> >> list the sections and actions we expect to have been done?
> > 
> > Changed to checkboxes and a follow-up text field. Please review.
> 
> You've added a box: "All SHA-1 based TLS/SSL certificates chaining up to
> our root certificates included in Mozilla’s CA Certificate Program have
> either expired or been revoked."
> 
> I don't think we _required_ revocation of all publicly-trusted SHA-1
> certs, did we?

removed

> 
> Also, the two about "all... certificates" might need to be changed to
> "Our policy now is that all... certificates".

Updated

> 
> > See action 9 here:
> > https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2
> 
> You now need to remove the second bullet in this action, as it's
> redundant with the reduced scope.
> 

removed

Thanks,
Kathleen

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

Re: Next CA Communication

2017-03-20 Thread Gervase Markham via dev-security-policy 
On 20/03/17 13:07, Peter Bowen wrote:
>> E) SHA-1 and S/MIME
>>
>> Does your CA issue SHA-1 S/MIME certificates? If so, please explain your
>> plans for ceasing to do so, and any self-imposed or external deadlines
>> you are planning to meet. Mozilla plans to make policy in this area in
>> the future, so please explain any facts or constraints which you think
>> might be relevant to our considerations.
> 
> Why is this limited to s/mime?  It would be highly valuable to
> understand if any SHA-1 signatures are being created using keys
> trusted to sign server auth certs.

Presumably you mean outside the scope of the BRs?

Gerv

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

Re: Next CA Communication

2017-03-20 Thread Gervase Markham via dev-security-policy 
On 20/03/17 15:33, Kathleen Wilson wrote:
>> * Action 7: some of the BR Compliance bugs relate to CAs which are no
>> longer trusted, like StartCom. If StartCom does become a trusted CA
>> again, it will be with new systems which most likely do not have the
>> same bugs. Should we close the StartCom compliance bugs?
> 
> Yes, I think that makes sense.

OK, I've closed the StartCom and ANSSI bugs.

>> * Action 8: Can we provide more structure here, by perhaps putting some
>> boilerplate text in the answer box or something like that? Or at least
>> list the sections and actions we expect to have been done?
> 
> Changed to checkboxes and a follow-up text field. Please review.

You've added a box: "All SHA-1 based TLS/SSL certificates chaining up to
our root certificates included in Mozilla’s CA Certificate Program have
either expired or been revoked."

I don't think we _required_ revocation of all publicly-trusted SHA-1
certs, did we?

Also, the two about "all... certificates" might need to be changed to
"Our policy now is that all... certificates".

>> C) CAA
> 
> Added, but please carefully review -- not sure I got it correct. 

Looks good to me.

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

Re: Next CA Communication

2017-03-20 Thread Peter Bowen via dev-security-policy 
On Mon, Mar 20, 2017 at 4:52 PM Rob Stradling 
wrote:

> On 20/03/17 17:07, Peter Bowen via dev-security-policy wrote:
> 
> >> B) Your attention is drawn to the cablint and x509lint tools, which you
> >> may wish to incorporate into your certificate issuance pipeline to get
> >> early warning of circumstances when you are issuing certificates which
> >> do not meet the Baseline Requirements (cablint) or X509 standards
> >> (x509lint).
> >>
> >> https://github.com/kroeckx/x509lint
> >> XXX What's the URL for cablint?
> >
> > https://cabforum.org/pipermail/public/2017-March/010144.html
>
> Hi Peter.  I presume you meant...
>
> https://github.com/awslabs/certlin t



Yes. Not sure how that archive URL got there.

>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Next CA Communication

2017-03-20 Thread Kathleen Wilson via dev-security-policy 
On Monday, March 20, 2017 at 1:37:32 PM UTC-7, Jeremy Rowley wrote:
> Something like: "Does your CA have any third-party Registration Authority
> (RA)s program that the CA relies on to perform the domain validation
> required under Section 3.2.2.4 of the Baseline Requirements."


Updated

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

RE: Next CA Communication

2017-03-20 Thread Jeremy Rowley via dev-security-policy 
I only understand this "independent validation of domain control" because
I'm on the thread. I don't think CAs who aren't actively involved will
understand what it means. DigiCert has an RA. It's DigiCert.  We validate
our certificate orders and submit them to the CA for issuance. I think it
should be clarified that this is referencing a) third-party RAs and b) where
the CA relies on the RA to perform the domain validation function required
under the Baseline Requirements. 

Something like: "Does your CA have any third-party Registration Authority
(RA)s program that the CA relies on to perform the domain validation
required under Section 3.2.2.4 of the Baseline Requirements."

Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Kathleen Wilson via dev-security-policy
Sent: Monday, March 20, 2017 2:29 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Next CA Communication

On Monday, March 20, 2017 at 10:59:41 AM UTC-7, Peter Bowen wrote:
> On Mon, Mar 20, 2017 at 10:43 AM, Jeremy Rowley via
> > [JR] This should be limited to SSL certs IMO. With client certs, 
> > you're going to get a lot more RAs that likely function under the 
> > standard or legal framework defining the certificate type.
> 
> What if the question was scoped to "RAs that can do independent 
> validation of domain control" or some such?  e.g. a classic "Enteprise 
> RA" set up where the CA's in-house RA confirms control of a public 
> suffix and then allows the Enterprise to internally confirm 
> certificate requests under the validated domain should not be counted 
> here.

updated

See action 9 here:
https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicati
onSurveySample?CACommunicationId=a050S00G3K2

___
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: Next CA Communication

2017-03-20 Thread Kathleen Wilson via dev-security-policy 
On Monday, March 20, 2017 at 10:59:41 AM UTC-7, Peter Bowen wrote:
> On Mon, Mar 20, 2017 at 10:43 AM, Jeremy Rowley via
> > [JR] This should be limited to SSL certs IMO. With client certs, you're 
> > going
> > to get a lot more RAs that likely function under the standard or legal
> > framework defining the certificate type.
> 
> What if the question was scoped to "RAs that can do independent
> validation of domain control" or some such?  e.g. a classic "Enteprise
> RA" set up where the CA's in-house RA confirms control of a public
> suffix and then allows the Enterprise to internally confirm
> certificate requests under the validated domain should not be counted
> here.

updated

See action 9 here:
https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2

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

Re: Next CA Communication

2017-03-20 Thread Kathleen Wilson via dev-security-policy 
On Friday, March 17, 2017 at 9:17:07 AM UTC-7, Peter Bowen wrote:
> I would replace this with:
> 
> + Distinguished name and SHA-256 hash of the SubjectPublicKeyInfo of
> each certificate issuer covered by the audit scope
> + Clear indication of which in-scope certificate issuers are Root CAs
> 


Is this OK?
+ Distinguished name (Certificate Subject Field) and SHA1 or SHA256 fingerprint 
of each certificate issuer covered by the audit scope
+ Clear indication of which in-scope certificate issuers are Root CAs

We are looking for human-readable information, so want a name and a fingerprint.

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

Re: Next CA Communication

2017-03-20 Thread Peter Bowen via dev-security-policy 
On Mon, Mar 20, 2017 at 10:43 AM, Jeremy Rowley via
dev-security-policy  wrote:
> A) Does your CA have an RA program, whereby non-Affiliates of your company
> perform aspects of certificate validation on your behalf under contract? If
> so, please tell us about the program, including:
>
> * How many companies are involved
> * Which of those companies do their own domain ownership validation
> * What measures you have in place to ensure this work is done to an
> appropriate standard
> [JR] This should be limited to SSL certs IMO. With client certs, you're going
> to get a lot more RAs that likely function under the standard or legal
> framework defining the certificate type.

What if the question was scoped to "RAs that can do independent
validation of domain control" or some such?  e.g. a classic "Enteprise
RA" set up where the CA's in-house RA confirms control of a public
suffix and then allows the Enterprise to internally confirm
certificate requests under the validated domain should not be counted
here.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Next CA Communication

2017-03-20 Thread Gervase Markham via dev-security-policy 
On 17/03/17 15:30, Gervase Markham wrote:
> The URL for the draft of the next CA Communication is here:
> https://mozilla-mozillacaprogram.cs54.force.com/Communications/CACommunicationSurveySample?CACommunicationId=a050S00G3K2

* Action 1 should say that if in future additional specific methods are
defined by the CAB Forum, then they will be permitted also.

* Clarifying: "so the subsections of version 3.2.2.4 that are marked
"Reserved" in version 1.4.2 of the BRs are still BR-compliant" -> "so
the subsections of section 3.2.2.4 in 1.4.1 that are marked "Reserved"
in version 1.4.2 of the BRs are still BR-compliant under 1.4.2".

* Action 1: Kathleen, I believe you said that 1/1/2016 is the earliest
date the widget will do, but the text asks for 1/1/2015 (if you don't
have the Websites trust bit)?

* Action 2: as the two choices are mutually exclusive, I would expect
radio buttons rather than a checkbox.

* Action 3: "in github" -> "on Github".

* Action 5: policy 2.4 has some of these requirements but not all. I've
filed an issue to add any extra ones.
https://github.com/mozilla/pkipolicy/issues/66

* Action 7: some of the BR Compliance bugs relate to CAs which are no
longer trusted, like StartCom. If StartCom does become a trusted CA
again, it will be with new systems which most likely do not have the
same bugs. Should we close the StartCom compliance bugs?

* Action 7: I have updated these bugs to have a convention of putting
the CA name at the start of the bug summary. This allows sorting "by CA"
if you sort by Summary.

* Action 8: Can we provide more structure here, by perhaps putting some
boilerplate text in the answer box or something like that? Or at least
list the sections and actions we expect to have been done?

I would also like to add the following questions/actions:

A) Does your CA have an RA program, whereby non-Affiliates of your
company perform aspects of certificate validation on your behalf under
contract? If so, please tell us about the program, including:

* How many companies are involved
* Which of those companies do their own domain ownership validation
* What measures you have in place to ensure this work is done to an
appropriate standard

If you do not have an RA program, write "Not Applicable".



B) Your attention is drawn to the cablint and x509lint tools, which you
may wish to incorporate into your certificate issuance pipeline to get
early warning of circumstances when you are issuing certificates which
do not meet the Baseline Requirements (cablint) or X509 standards
(x509lint).

https://github.com/kroeckx/x509lint
XXX What's the URL for cablint?

[ ] I am now aware of these tools

C) CAA

The CAB Forum recently passed ballot 187, which updated the Baseline
Requirements to make CAA (RFC 6844) checking mandatory at time of
certificate issuance in almost all circumstances. Please provide a list
of the domain names which your CA plans to recognise in a CAA record's
issue and issuewild property tags as permitting it to issue. If certain
identifiers only permit under certain circumstances, please explain.



Mozilla plans to make a central list of these identifiers.

D) Problem Reporting Mechanism

Please explain how your CA meets the following requirement from the BRs
section 4.9.3:

“The CA SHALL provide Subscribers, Relying Parties, Application Software
Suppliers, and other third parties with clear instructions for reporting
suspected Private Key Compromise, Certificate misuse, or other types of
fraud, compromise, misuse, inappropriate conduct, or any other matter
related to Certificates. The CA SHALL publicly disclose the instructions
through a readily accessible online means.”

Please detail both the mechanism and the location(s) where you publicly
disclose it. Mozilla plans to make a central list of these mechanisms.
You are encouraged to make an email address at least one of your
provided options.



E) SHA-1 and S/MIME

Does your CA issue SHA-1 S/MIME certificates? If so, please explain your
plans for ceasing to do so, and any self-imposed or external deadlines
you are planning to meet. Mozilla plans to make policy in this area in
the future, so please explain any facts or constraints which you think
might be relevant to our considerations.

If none of your roots have the Email trust bit set, write "Not Applicable".




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