Re: CA Problem Reporting Mechanisms

[Gervase Markham via dev-security-policy]

On 08/08/17 20:02, Jeremy Rowley wrote:
> +1. CAs should be required to support certificate problem reports
> sent through a specified email address. It simplifies the process a
> lot if CAs use at least one common mechanism.

https://github.com/mozilla/pkipolicy/issues/98

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

Re: CA Problem Reporting Mechanisms

[Jeremy Rowley via dev-security-policy]

+1. CAs should be required to support certificate problem reports sent through 
a specified email address. It simplifies the process a lot if CAs use at least 
one common mechanism.

> On Aug 8, 2017, at 12:22 PM, Jonathan Rudenberg via dev-security-policy 
>  wrote:
> 
> 
>> On Aug 8, 2017, at 10:36, David E. Ross via dev-security-policy 
>>  wrote:
>> 
>> On 8/7/2017 8:09 PM, Jonathan Rudenberg wrote:
>>> 
 On May 17, 2017, at 07:24, Gervase Markham via dev-security-policy 
  wrote:
 
 On 16/05/17 02:26, userwithuid wrote:
> After skimming the responses and checking a few CAs, I'm starting to
> wonder: Wouldn't it be easier to just add another mandatory field to
> the CCADB (e..g. "revocation contact"), requiring $URL or $EMAIL via
> policy and just use that to provide a public list?
 
 Well, such contacts are normally per CA rather than per root. I guess we
 could add it on the CA's entry.
>>> 
>>> I’ve been reporting a fair amount of misissuance this week, and the 
>>> responses to the Problem Reporting question in the April CA communication 
>>> leave a lot to be desired. Several CAs do not have any contact details at 
>>> all, and others require filling forms with captchas.
>>> 
>>> I think it’d be very useful if CAs were required maintain a problem 
>>> reporting email address and keep it current in the CCADB, this requirement 
>>> could go in the Mozilla Root Store policy or the CCADB policy. If they want 
>>> to also maintain other modes of contact, they can but no matter what an 
>>> email address should be required.
>>> 
>>> Jonathan
>>> 
>> 
>> I think that a public point of contact for a certification authority was
>> a requirement under Mozilla's policy.  I cannot find such a requirement
>> now unless the Baseline Requirements, which are included by reference in
>> Mozilla's policy, require it.
> 
> Yes, section 4.9.3 of the Baseline Requirements says:
> 
>> 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.
> 
> However, it does not specify that email is required. I’m proposing that 
> Mozilla require that one of the methods for reporting be email and that the 
> email address be recorded in the CCADB.
> 
> Jonathan
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CA Problem Reporting Mechanisms

[Tim Hollebeek via dev-security-policy]

See BR 1.5.2.  CAs are already required to have contact information in their 
CPS.

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+thollebeek=trustwave@lists.mozilla.org] 
On Behalf Of David E. Ross via dev-security-policy
Sent: Tuesday, August 8, 2017 10:37 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA Problem Reporting Mechanisms

On 8/7/2017 8:09 PM, Jonathan Rudenberg wrote:
> 
>> On May 17, 2017, at 07:24, Gervase Markham via dev-security-policy 
>> <dev-security-policy@lists.mozilla.org> wrote:
>>
>> On 16/05/17 02:26, userwithuid wrote:
>>> After skimming the responses and checking a few CAs, I'm starting to
>>> wonder: Wouldn't it be easier to just add another mandatory field to 
>>> the CCADB (e..g. "revocation contact"), requiring $URL or $EMAIL via 
>>> policy and just use that to provide a public list?
>>
>> Well, such contacts are normally per CA rather than per root. I guess 
>> we could add it on the CA's entry.
> 
> I've been reporting a fair amount of misissuance this week, and the responses 
> to the Problem Reporting question in the April CA communication leave a lot 
> to be desired. Several CAs do not have any contact details at all, and others 
> require filling forms with captchas.
> 
> I think it'd be very useful if CAs were required maintain a problem reporting 
> email address and keep it current in the CCADB, this requirement could go in 
> the Mozilla Root Store policy or the CCADB policy. If they want to also 
> maintain other modes of contact, they can but no matter what an email address 
> should be required.
> 
> Jonathan
> 

I think that a public point of contact for a certification authority was a 
requirement under Mozilla's policy.  I cannot find such a requirement now 
unless the Baseline Requirements, which are included by reference in Mozilla's 
policy, require it.

--
David E. Ross
<http://scanmail.trustwave.com/?c=4062=m8yJ2Wj4I3PpA9lLssqYcKc5sstI-v_FHXaRoVKFig=5=http%3a%2f%2fwww%2erossde%2ecom%2f>

President Trump demands loyalty to himself from Republican members of Congress. 
 I always thought that members of Congress -- House and Senate -- were required 
to be loyal to the people of the United States.  In any case, they all swore an 
oath of office to be loyal to the Constitution.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://scanmail.trustwave.com/?c=4062=m8yJ2Wj4I3PpA9lLssqYcKc5sstI-v_FHXLApAaMgw=5=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA Problem Reporting Mechanisms

[Jonathan Rudenberg via dev-security-policy]

> On Aug 8, 2017, at 10:36, David E. Ross via dev-security-policy 
>  wrote:
> 
> On 8/7/2017 8:09 PM, Jonathan Rudenberg wrote:
>> 
>>> On May 17, 2017, at 07:24, Gervase Markham via dev-security-policy 
>>>  wrote:
>>> 
>>> On 16/05/17 02:26, userwithuid wrote:
 After skimming the responses and checking a few CAs, I'm starting to
 wonder: Wouldn't it be easier to just add another mandatory field to
 the CCADB (e..g. "revocation contact"), requiring $URL or $EMAIL via
 policy and just use that to provide a public list?
>>> 
>>> Well, such contacts are normally per CA rather than per root. I guess we
>>> could add it on the CA's entry.
>> 
>> I’ve been reporting a fair amount of misissuance this week, and the 
>> responses to the Problem Reporting question in the April CA communication 
>> leave a lot to be desired. Several CAs do not have any contact details at 
>> all, and others require filling forms with captchas.
>> 
>> I think it’d be very useful if CAs were required maintain a problem 
>> reporting email address and keep it current in the CCADB, this requirement 
>> could go in the Mozilla Root Store policy or the CCADB policy. If they want 
>> to also maintain other modes of contact, they can but no matter what an 
>> email address should be required.
>> 
>> Jonathan
>> 
> 
> I think that a public point of contact for a certification authority was
> a requirement under Mozilla's policy.  I cannot find such a requirement
> now unless the Baseline Requirements, which are included by reference in
> Mozilla's policy, require it.

Yes, section 4.9.3 of the Baseline Requirements says:

> 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.

However, it does not specify that email is required. I’m proposing that Mozilla 
require that one of the methods for reporting be email and that the email 
address be recorded in the CCADB.

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

Re: CA Problem Reporting Mechanisms

[David E. Ross via dev-security-policy]

On 8/7/2017 8:09 PM, Jonathan Rudenberg wrote:
> 
>> On May 17, 2017, at 07:24, Gervase Markham via dev-security-policy 
>>  wrote:
>>
>> On 16/05/17 02:26, userwithuid wrote:
>>> After skimming the responses and checking a few CAs, I'm starting to
>>> wonder: Wouldn't it be easier to just add another mandatory field to
>>> the CCADB (e..g. "revocation contact"), requiring $URL or $EMAIL via
>>> policy and just use that to provide a public list?
>>
>> Well, such contacts are normally per CA rather than per root. I guess we
>> could add it on the CA's entry.
> 
> I’ve been reporting a fair amount of misissuance this week, and the responses 
> to the Problem Reporting question in the April CA communication leave a lot 
> to be desired. Several CAs do not have any contact details at all, and others 
> require filling forms with captchas.
> 
> I think it’d be very useful if CAs were required maintain a problem reporting 
> email address and keep it current in the CCADB, this requirement could go in 
> the Mozilla Root Store policy or the CCADB policy. If they want to also 
> maintain other modes of contact, they can but no matter what an email address 
> should be required.
> 
> Jonathan
> 

I think that a public point of contact for a certification authority was
a requirement under Mozilla's policy.  I cannot find such a requirement
now unless the Baseline Requirements, which are included by reference in
Mozilla's policy, require it.

-- 
David E. Ross


President Trump demands loyalty to himself from Republican members
of Congress.  I always thought that members of Congress -- House
and Senate -- were required to be loyal to the people of the
United States.  In any case, they all swore an oath of office
to be loyal to the Constitution.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA Problem Reporting Mechanisms

[Jonathan Rudenberg via dev-security-policy]

> On May 17, 2017, at 07:24, Gervase Markham via dev-security-policy 
>  wrote:
> 
> On 16/05/17 02:26, userwithuid wrote:
>> After skimming the responses and checking a few CAs, I'm starting to
>> wonder: Wouldn't it be easier to just add another mandatory field to
>> the CCADB (e..g. "revocation contact"), requiring $URL or $EMAIL via
>> policy and just use that to provide a public list?
> 
> Well, such contacts are normally per CA rather than per root. I guess we
> could add it on the CA's entry.

I’ve been reporting a fair amount of misissuance this week, and the responses 
to the Problem Reporting question in the April CA communication leave a lot to 
be desired. Several CAs do not have any contact details at all, and others 
require filling forms with captchas.

I think it’d be very useful if CAs were required maintain a problem reporting 
email address and keep it current in the CCADB, this requirement could go in 
the Mozilla Root Store policy or the CCADB policy. If they want to also 
maintain other modes of contact, they can but no matter what an email address 
should be required.

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

Re: CA Problem Reporting Mechanisms

[userwithuid via dev-security-policy]

On Wednesday, May 17, 2017 at 11:24:54 AM UTC, Gervase Markham wrote:
> Well, such contacts are normally per CA rather than per root. I guess we
> could add it on the CA's entry.

Tbh, I'm not really familiar with your salesforce setup, I was just using this 
as a stand-in for "place where CA can be made to keep it current". :-)

> Well, I want to make sure that people who want to report e.g. a bad cert
> found in the wild know where to go. This was triggered by an event where
> Microsoft wanted to report something to GoDaddy (IIRC) but using the
> wrong contact.

So the intent was really:

How can an external entity (= not the certificate owner or authorized party) 
report a security issue, abuse scenario or policy violation with regards to 
certificates you issued? Specifically, what contact email address or webpage 
can be used to ensure a timely and competent response?

(plainly: how to reach "tech" or "compliance", not 
sales/marketing/customer-support/general/...)

> > IMHO, a wiki page with manually copied info has a good chance to get
> > stale as CAs change their documents, websites, primary domains, etc.
> 
> It's true, but the other option is "dig in my CP/CPS".

But there could be more "other options":

dig yourself << community collected and maintained info < CA verified community 
info < info CAs are "forced" to maintain, policed by community

So I guess my second choice - after getting CAs to unbundle this specific info 
from their pdfs and maintain it via the CCADB (or wherever else it makes sense) 
- would be to go ahead with the manually created wiki page and make them 
confirm it regularily via CA communications. Then there is still a degree of 
accountability for the correctness.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CA Problem Reporting Mechanisms

[Gervase Markham via dev-security-policy]

On 16/05/17 02:26, userwithuid wrote:
> After skimming the responses and checking a few CAs, I'm starting to
> wonder: Wouldn't it be easier to just add another mandatory field to
> the CCADB (e..g. "revocation contact"), requiring $URL or $EMAIL via
> policy and just use that to provide a public list?

Well, such contacts are normally per CA rather than per root. I guess we
could add it on the CA's entry.

> It seems to me that most revocation related procedures are very
> specific to CA-customers (e.g. log in and use the revoke button) and
> often not even TLS related (e.g. send a document signed with key you
> want to revoke, use the revocation password you got when creating the
> email cert, ...). I think it's not your intention for the wiki page
> to capture that, or is it?

Well, I want to make sure that people who want to report e.g. a bad cert
found in the wild know where to go. This was triggered by an event where
Microsoft wanted to report something to GoDaddy (IIRC) but using the
wrong contact.

> IMHO, a wiki page with manually copied info has a good chance to get
> stale as CAs change their documents, websites, primary domains, etc.

It's true, but the other option is "dig in my CP/CPS".

Also, I had hoped that the question itself would remind CAs that this
information needed to be there, and prompt any for which it wasn't there
to fix it :-)

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

Re: CA Problem Reporting Mechanisms

[userwithuid via dev-security-policy]

After skimming the responses and checking a few CAs, I'm starting to wonder: 
Wouldn't it be easier to just add another mandatory field to the CCADB (e.g. 
"revocation contact"), requiring $URL or $EMAIL via policy and just use that to 
provide a public list?

It seems to me that most revocation related procedures are very specific to 
CA-customers (e.g. log in and use the revoke button) and often not even TLS 
related (e.g. send a document signed with key you want to revoke, use the 
revocation password you got when creating the email cert, ...). I think it's 
not your intention for the wiki page to capture that, or is it?

>From what I can see, for non-customers the "instructions" - if there are any - 
>really seem to amount to: A) Send email with cert info + reason you suspect 
>misuse, we'll check or B) use web form to do the same.

IMHO, a wiki page with manually copied info has a good chance to get stale as 
CAs change their documents, websites, primary domains, etc.

(That being said, trying to use CPS urls from the CCADB [0] I got some 404s and 
some 30* lead nowhere as well. Also some CAs link an outdated version when the 
website has a WAY more recent one, though that might be because of the English 
vs native lang situation. Point is, CCADB entries might also be outdated, but 
at least that will be a policy violation now, right?).

[0] https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CA Problem Reporting Mechanisms

[Gervase Markham via dev-security-policy]

Hi all,

One of the CA Communication questions was about the Problem Reporting
Mechanisms that CAs are supposed to have. The answers are here:
https://mozillacaprogram.secure.force.com/Communications/CACommResponsesOnlyReport?CommunicationId=a05o03WrzBC=Q00028

I would love it if someone would volunteer to turn this into a wiki page
in a more standardized and useful format, looking up the actual
information where people have said "see section X.X of our CPS", and so
on. And they can send me a list of CAs I have to email to remind them
that this is a compulsory requirement so they can't put "Not applicable"
or "We'll figure it out later".

Might anyone have an hour or two to spare, to help in this way? If so,
drop me an email for a more detailed brief.

Thanks :-)

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