RE: CAA Certificate Problem Report

[Nick Lamb via dev-security-policy]

I'm struggling to get my head around what you're asking for. I think you're 
seriously asking if there's a way to skip all the actual security of DNSSEC and 
get a secure answer anyway?

No. The answer is "No". If you're comfortable with answers that might be lies, 
you can skip DNSSEC entirely. Otherwise you need to use DNSSEC to get either a 
signed, true answer, or signed proof there is no signed answer for the question 
you had (in which case you might choose to accept whatever answer you do get 
knowing it might not be true but at least you tried), or an error.

Relying on an answer that might be a lie to tell you whether the answers you're 
getting might be lies is pointless. Literally futile.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Jonathan Rudenberg via dev-security-policy]

> On Sep 11, 2017, at 18:30, Ryan Sleevi via dev-security-policy 
>  wrote:
> 
> On Mon, Sep 11, 2017 at 3:09 PM Jonathan Rudenberg via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> 
>>> On Sep 11, 2017, at 17:41, Ryan Sleevi via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>> 
>>> That seems like very poor logic and justification.
>>> 
>>> Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for
>>> literally years now, perhaps it's worth asking why CAs are only now
>>> discovering issues. That is, is the only reason we're discovering issues
>>> because CAs waited for the last possible moment? If so, why.
>> 
>> I think the BR clause that brings DNSSEC in is poorly drafted.
> 
> 
> Why?

As written, it’s not clear what the point is, as I describe below. If the 
intent was to require DNSSEC validation, it should say that clearly.

>> Additionally, it may be a stretch to say that DNSSEC in the context of CAA
>> has been discussed extensively.
> 
> 
> I'm not sure I understand why you feel some special discussion is or was
> necessary, given the discussion that occurred in IETF on this. That is, are
> you asserting that these issues - such as CAs not even checking CAA - are
> because of the ballot language?

I’m only talking about the DNSSEC-related issues here, I’m not aware of any CAs 
that are not or were not checking CAA due to DNSSEC.

Some CAs have interpreted this clause to not require DNSSEC validation when 
doing CAA queries, do you believe that interpretation is valid?

My interpretation is that DNSSEC validation is required to the point to the 
domain’s zone (but not to the CAA record set itself) if a CA wants to treat a 
record lookup failure as permission to issue. If the goal is to address the 
relevant security considerations in RFC 6844 with DNSSEC, this appears to leave 
a pretty gaping hole where a CA could:

1) not implement DNSSEC at all, and treat lookup failures as issuance-blocking 
errors; or
2) implement enough DNSSEC to decide if a zone has a “validation chain” without 
ever validating the CAA queries themselves

Thus, the clause as I interpret it only prevents a specific attack that drops 
CAA query answers and doesn't provide any authenticity or integrity guarantees. 
Instead of dropping an answer, an attacker could just replace the answer with 
one that they want.

> I’m not familiar with relevant discussions that are not indexed by Google,
>> but when I researched this I only found a few exchanges about this specific
>> requirement on the public mailing list.
> 
> 
> This was discussed at nearly every single F2F since late 2013/early 2014.
> The DNSSEC discussion was very much part of the IETF discussions.
> 
> What discussions do you feel should have happened, but didn’t?

So far I’ve been working of the interpretation above, and so I’ve been trying 
to understand why DNSSEC is brought in while not addressing any meaningful 
security considerations.

>>> I think arguments that suggest that failing to do the right thing makes
>> it
>>> OK to do the wrong thing are the worst arguments to make :)
>> 
>> My argument is not that it’s okay to do the wrong thing. Instead, I think
>> it’s worth evaluating the DNSSEC requirement to decide whether it should
>> continue to be defined as "the right thing” in the BRs. I did not see any
>> such analysis on cabfpub.
> 
> 
> I'm surprised to even see the suggestion that it isn't. Do you feel the
> security considerations are insufficiently documented in the CAA RFC? Do
> you feel it's not sufficiently obvious the risks of not using DNSSEC?

The security considerations are clear, and if properly implemented, DNSSEC 
would help there. These security considerations also apply to all online domain 
validation methods, and DNSSEC isn’t required there, so I’m not yet convinced 
by this argument.

What isn’t clear is whether DNSSEC should be deployed at all. There have been 
many large outages caused by DNSSEC[0], the tooling is horrible, weak crypto is 
rampant throughout the system, and the specification is extraordinarily 
complex. The footgun potential is greater than HPKP in scale, and the end 
result is something that even if deployed widely won’t even protect the average 
user from spoofed DNS answers on open WiFi. So, no, I’m not convinced that it’s 
the right thing.

Jonathan

[0] https://ianix.com/pub/dnssec-outages.html

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

Re: CAA Certificate Problem Report

[Ryan Sleevi via dev-security-policy]

On Mon, Sep 11, 2017 at 3:09 PM Jonathan Rudenberg via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> > On Sep 11, 2017, at 17:41, Ryan Sleevi via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > That seems like very poor logic and justification.
> >
> > Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for
> > literally years now, perhaps it's worth asking why CAs are only now
> > discovering issues. That is, is the only reason we're discovering issues
> > because CAs waited for the last possible moment? If so, why.
>
> I think the BR clause that brings DNSSEC in is poorly drafted.


Why?

It seems like the intent may be to require full DNSSEC validation for CAA
> lookups, but that’s not what it says. I don’t think the issues under
> discussion have anything to do with the last moment. There appear to be
> significant differences in understanding, which were not discussed publicly
> until now. The ideal path here would have been for CAs to consult with the
> community about the interpretation and implementation details of this
> clause well before it came into force.


I'm not sure I would agreee with that, because it is completely
unmeasurable, and every CA being "compliant" with such a requirement would
still have resulted in the same outcome.

>
> Additionally, it may be a stretch to say that DNSSEC in the context of CAA
> has been discussed extensively.


I'm not sure I understand why you feel some special discussion is or was
necessary, given the discussion that occurred in IETF on this. That is, are
you asserting that these issues - such as CAs not even checking CAA - are
because of the ballot language?

I’m not familiar with relevant discussions that are not indexed by Google,
> but when I researched this I only found a few exchanges about this specific
> requirement on the public mailing list.


This was discussed at nearly every single F2F since late 2013/early 2014.
The DNSSEC discussion was very much part of the IETF discussions.

What discussions do you feel should have happened, but didn't?

>
> > I think arguments that suggest that failing to do the right thing makes
> it
> > OK to do the wrong thing are the worst arguments to make :)
>
> My argument is not that it’s okay to do the wrong thing. Instead, I think
> it’s worth evaluating the DNSSEC requirement to decide whether it should
> continue to be defined as "the right thing” in the BRs. I did not see any
> such analysis on cabfpub.


I'm surprised to even see the suggestion that it isn't. Do you feel the
security considerations are insufficiently documented in the CAA RFC? Do
you feel it's not sufficiently obvious the risks of not using DNSSEC?

This feels very knee-jerk, but I may be misunderstanding part of your
argument. Perhaps you could do a small write-up of why you feel things are
problematic, since the original argument - which seems to be "some CAs had
trouble" - is not at all compelling given the facts and the years of
discussion that lead up to this ballot.

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

Re: CAA Certificate Problem Report

[Jonathan Rudenberg via dev-security-policy]

> On Sep 11, 2017, at 17:41, Ryan Sleevi via dev-security-policy 
>  wrote:
> 
> That seems like very poor logic and justification.
> 
> Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for
> literally years now, perhaps it's worth asking why CAs are only now
> discovering issues. That is, is the only reason we're discovering issues
> because CAs waited for the last possible moment? If so, why.

I think the BR clause that brings DNSSEC in is poorly drafted. It seems like 
the intent may be to require full DNSSEC validation for CAA lookups, but that’s 
not what it says. I don’t think the issues under discussion have anything to do 
with the last moment. There appear to be significant differences in 
understanding, which were not discussed publicly until now. The ideal path here 
would have been for CAs to consult with the community about the interpretation 
and implementation details of this clause well before it came into force.

Additionally, it may be a stretch to say that DNSSEC in the context of CAA has 
been discussed extensively. I’m not familiar with relevant discussions that are 
not indexed by Google, but when I researched this I only found a few exchanges 
about this specific requirement on the public mailing list.

https://cabforum.org/pipermail/public/2016-November/008831.html
https://cabforum.org/pipermail/public/2017-February/009732.html

> I think arguments that suggest that failing to do the right thing makes it
> OK to do the wrong thing are the worst arguments to make :)

My argument is not that it’s okay to do the wrong thing. Instead, I think it’s 
worth evaluating the DNSSEC requirement to decide whether it should continue to 
be defined as "the right thing” in the BRs. I did not see any such analysis on 
cabfpub.

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

RE: CAA Certificate Problem Report

[Jeremy Rowley via dev-security-policy]

Well, we are checking CAA and DNSSEC per our implementation. Looks great on our 
side and against our tests.  Some individuals disagree though.

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Monday, September 11, 2017 3:42 PM
To: Jeremy Rowley ; Jonathan Rudenberg 

Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CAA Certificate Problem Report

 

That seems like very poor logic and justification.

 

Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for 
literally years now, perhaps it's worth asking why CAs are only now discovering 
issues. That is, is the only reason we're discovering issues because CAs waited 
for the last possible moment? If so, why.

 

Because they didn't write test suites? If not, why not? If so, what were they?

 

I think arguments that suggest that failing to do the right thing makes it OK 
to do the wrong thing are the worst arguments to make :)

 

On Mon, Sep 11, 2017 at 2:28 PM Jeremy Rowley via dev-security-policy 
 > wrote:

I would support that.  I can't recall why it's in there.

-Original Message-
From: Jonathan Rudenberg [mailto:jonat...@titanous.com 
 ]
Sent: Monday, September 11, 2017 3:19 PM
To: Jeremy Rowley  >
Cc: mozilla-dev-security-pol...@lists.mozilla.org 
 
Subject: Re: CAA Certificate Problem Report


> On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy 
>   > wrote:
>
> For a little more context, the idea is that we can speed up the CAA check for 
> all customers while working with those who have DNSSEC to make sure they 
> aren't killing performance.  If there's a way to group them easily into 
> buckets (timeout + quick does DNSSEC exist check), working on improving the 
> experience for that particular set of customers is easier. That bucket can 
> then be improved later.

Given the disaster that DNSSEC+CAA has been over the past few days for multiple 
CAs and the fact that it’s optional in the CAA RFC, what do you think about 
proposing a ballot to remove the DNSSEC requirement from the BRs entirely?

Jonathan
___
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: CAA Certificate Problem Report

[Ryan Sleevi via dev-security-policy]

That seems like very poor logic and justification.

Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for
literally years now, perhaps it's worth asking why CAs are only now
discovering issues. That is, is the only reason we're discovering issues
because CAs waited for the last possible moment? If so, why.

Because they didn't write test suites? If not, why not? If so, what were
they?

I think arguments that suggest that failing to do the right thing makes it
OK to do the wrong thing are the worst arguments to make :)

On Mon, Sep 11, 2017 at 2:28 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I would support that.  I can't recall why it's in there.
>
> -Original Message-
> From: Jonathan Rudenberg [mailto:jonat...@titanous.com]
> Sent: Monday, September 11, 2017 3:19 PM
> To: Jeremy Rowley 
> Cc: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: CAA Certificate Problem Report
>
>
> > On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> > For a little more context, the idea is that we can speed up the CAA
> check for all customers while working with those who have DNSSEC to make
> sure they aren't killing performance.  If there's a way to group them
> easily into buckets (timeout + quick does DNSSEC exist check), working on
> improving the experience for that particular set of customers is easier.
> That bucket can then be improved later.
>
> Given the disaster that DNSSEC+CAA has been over the past few days for
> multiple CAs and the fact that it’s optional in the CAA RFC, what do you
> think about proposing a ballot to remove the DNSSEC requirement from the
> BRs entirely?
>
> 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: CAA Certificate Problem Report

[Jeremy Rowley via dev-security-policy]

I would support that.  I can't recall why it's in there.

-Original Message-
From: Jonathan Rudenberg [mailto:jonat...@titanous.com] 
Sent: Monday, September 11, 2017 3:19 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CAA Certificate Problem Report


> On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy 
>  wrote:
> 
> For a little more context, the idea is that we can speed up the CAA check for 
> all customers while working with those who have DNSSEC to make sure they 
> aren't killing performance.  If there's a way to group them easily into 
> buckets (timeout + quick does DNSSEC exist check), working on improving the 
> experience for that particular set of customers is easier. That bucket can 
> then be improved later.

Given the disaster that DNSSEC+CAA has been over the past few days for multiple 
CAs and the fact that it’s optional in the CAA RFC, what do you think about 
proposing a ballot to remove the DNSSEC requirement from the BRs entirely?

Jonathan


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: CAA Certificate Problem Report

[Jonathan Rudenberg via dev-security-policy]

> On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy 
>  wrote:
> 
> For a little more context, the idea is that we can speed up the CAA check for 
> all customers while working with those who have DNSSEC to make sure they 
> aren't killing performance.  If there's a way to group them easily into 
> buckets (timeout + quick does DNSSEC exist check), working on improving the 
> experience for that particular set of customers is easier. That bucket can 
> then be improved later.

Given the disaster that DNSSEC+CAA has been over the past few days for multiple 
CAs and the fact that it’s optional in the CAA RFC, what do you think about 
proposing a ballot to remove the DNSSEC requirement from the BRs entirely?

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

RE: CAA Certificate Problem Report

[Jeremy Rowley via dev-security-policy]

For a little more context, the idea is that we can speed up the CAA check for 
all customers while working with those who have DNSSEC to make sure they aren't 
killing performance.  If there's a way to group them easily into buckets 
(timeout + quick does DNSSEC exist check), working on improving the experience 
for that particular set of customers is easier. That bucket can then be 
improved later.

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Monday, September 11, 2017 2:56 PM
To: Nick Lamb ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: CAA Certificate Problem Report

I think that's the opposite of what I'm saying.  CAs don't need to do DNSSEC 
provided 1) they don't want to issue certs where DNSSEC is implemented and 2) 
the CAA record check times out, and 3) there is a way to check if DNSSEC is 
present without doing the entire chain validation. #3 is what I'm not sure of.  

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, September 11, 2017 2:52 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CAA Certificate Problem Report

On Monday, 11 September 2017 18:33:24 UTC+1, Jeremy Rowley  wrote:
> That's the entire corpus of information related to DNSSEC in the BRs. Under 4 
> and 5, we successfully returned a DNS record. The lookup didn’t fail so the 
> sentence "the domain's zone does not have a DNSSEC validation chain to the 
> ICANN root" doesn't apply.  There is no need to check the DNSSEC validation 
> chain in this case.

Mmm. So your belief is that you're not actually required to do DNSSEC here at 
all? If Honest Achmed is asked to issue for example.com, he can do a plain (non 
DNSSEC) lookup, receive a spoofed "0 answers" for CAA on example.com, and issue 
on that basis, never needing to investigate whether example.com has DNSSEC 
enabled (it does), let alone whether the CAA response was properly signed ?

I guess if that's the common interpretation of this document at least it'd be 
good to understand which CAs are vulnerable in this way. Of course, even if you 
know this it's pointless to exclude them using CAA, they'll accept a spoofed 
answer...
___
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: CAA Certificate Problem Report

[Jeremy Rowley via dev-security-policy]

I think that's the opposite of what I'm saying.  CAs don't need to do DNSSEC 
provided 1) they don't want to issue certs where DNSSEC is implemented and 2) 
the CAA record check times out, and 3) there is a way to check if DNSSEC is 
present without doing the entire chain validation. #3 is what I'm not sure of.  

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Nick Lamb via dev-security-policy
Sent: Monday, September 11, 2017 2:52 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CAA Certificate Problem Report

On Monday, 11 September 2017 18:33:24 UTC+1, Jeremy Rowley  wrote:
> That's the entire corpus of information related to DNSSEC in the BRs. Under 4 
> and 5, we successfully returned a DNS record. The lookup didn’t fail so the 
> sentence "the domain's zone does not have a DNSSEC validation chain to the 
> ICANN root" doesn't apply.  There is no need to check the DNSSEC validation 
> chain in this case.

Mmm. So your belief is that you're not actually required to do DNSSEC here at 
all? If Honest Achmed is asked to issue for example.com, he can do a plain (non 
DNSSEC) lookup, receive a spoofed "0 answers" for CAA on example.com, and issue 
on that basis, never needing to investigate whether example.com has DNSSEC 
enabled (it does), let alone whether the CAA response was properly signed ?

I guess if that's the common interpretation of this document at least it'd be 
good to understand which CAs are vulnerable in this way. Of course, even if you 
know this it's pointless to exclude them using CAA, they'll accept a spoofed 
answer...
___
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: CAA Certificate Problem Report

[Nick Lamb via dev-security-policy]

On Monday, 11 September 2017 18:33:24 UTC+1, Jeremy Rowley  wrote:
> That's the entire corpus of information related to DNSSEC in the BRs. Under 4 
> and 5, we successfully returned a DNS record. The lookup didn’t fail so the 
> sentence "the domain's zone does not have a DNSSEC validation chain to the 
> ICANN root" doesn't apply.  There is no need to check the DNSSEC validation 
> chain in this case.

Mmm. So your belief is that you're not actually required to do DNSSEC here at 
all? If Honest Achmed is asked to issue for example.com, he can do a plain (non 
DNSSEC) lookup, receive a spoofed "0 answers" for CAA on example.com, and issue 
on that basis, never needing to investigate whether example.com has DNSSEC 
enabled (it does), let alone whether the CAA response was properly signed ?

I guess if that's the common interpretation of this document at least it'd be 
good to understand which CAs are vulnerable in this way. Of course, even if you 
know this it's pointless to exclude them using CAA, they'll accept a spoofed 
answer...
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CAA Certificate Problem Report

[Jeremy Rowley via dev-security-policy]

Not saying we implemented DNSSEC checking correctly, but I don't think the 
requirements are as clear as you present them.

The BRs state that:
" CAs are permitted to treat a record lookup failure as permission to issue if:
•  the failure is outside the CA's infrastructure;  
•  the lookup has been retried at least once; and   
• the domain's zone does not have a DNSSEC validation chain to the ICANN root."

That's the entire corpus of information related to DNSSEC in the BRs. Under 4 
and 5, we successfully returned a DNS record. The lookup didn’t fail so the 
sentence "the domain's zone does not have a DNSSEC validation chain to the 
ICANN root" doesn't apply.  There is no need to check the DNSSEC validation 
chain in this case.

For 3 and 6:
RFC 4033:
1) Is not referenced in the BRs
2) Does not define domain's zone
3) Does not reference a "validation chain" (but does define authentication 
chain as you noted) 
4) Does not mention an ICANN root
5) Is only a footnote in RFC 6844

Although most of these are straight forward without being defined, the 
culmination of semi-loose specifications makes for one very loose specification 
at the CAB Forum level, especially where programs like drill apparently did 
DNSSEC checking wrong. 

Of course, we would like to properly check DNSSEC (or at least check it more 
properly) so I'm interested to hear your opinion on whether this works as a fix:
1) Checking the entire DNSSEC chain was incredibly slow, causing the certs to 
take 10 sec plus to issue.  We figured checking RRSIG removed this delay by 
simply checking whether DNSSEC exists. If DNSSEC exists and we failed to return 
a DNS record, we'll just block the cert. 
2) Instead of checking the DNSSEC chain, could we simply check the DNSKEY RR at 
the parent? If the DNS RRSet exists at the parent, we will simply refuse the 
cert issuance.  This way we avoid the super long issuance times while still 
respecting DNSSEC requirements.

Thanks a ton for the discussion on this.
Jeremy


-Original Message-
From: Andrew Ayer [mailto:a...@andrewayer.name] 
Sent: Saturday, September 9, 2017 1:01 PM
To: Jonathan Rudenberg 
Cc: Jonathan Rudenberg via dev-security-policy 
; Peter Bowen ; 
mozilla-dev-security-pol...@lists.mozilla.org; Jeremy Rowley 

Subject: Re: CAA Certificate Problem Report

On Sat, 9 Sep 2017 06:57:39 -0400
Jonathan Rudenberg via dev-security-policy 
 wrote:

> 
> > On Sep 9, 2017, at 06:19, Peter Bowen via dev-security-policy 
> >  wrote:
> > 
> > In all three of these cases, the "domain's zone does not have a 
> > DNSSEC validation chain to the ICANN root" -- I requested SOA, 
> > DNSKEY, NS, and CAA records types for each zone and in no case did I 
> > get a response that had a valid DNSSEC chain to the ICANN root.
> 
> This comes down to what exactly “does not have a valid DNSSEC chain”
> means.

As I explained in my reply to Peter, it's not "valid DNSSEC chain", but rather 
a "validation chain", which is defined by RFC4033, albeit under the synonymous 
term "authentication chain".

> I had assumed that given the reference to DNSSEC in the BRs that the 
> relevant DNSSEC RFCs were incorporated by reference via RFC 6844 and 
> that DNSSEC validation is required. However, this is not entirely the 
> case, using DNSSEC for CAA lookups is only RECOMMENDED in section 4.1 
> and explicitly “not required.” Which means this is all pretty 
> pointless. The existence or non-existence of DNSSEC records doesn’t 
> matter if there is no requirement to use them.

The BRs could arguably be interpreted to not require DNSSEC validation during 
lookups, although as I explained in my reply to Jeremy I do not find this to be 
a very compelling interpretation.

However, it is not at all ambiguous that a request must be denied if the lookup 
fails for non-DNSSEC reasons, if there is DNSSEC validation chain to the ICANN 
root.  Given the reference to RFC4033 from RFC6844 in the definition of DNSSEC, 
CAs should be able to figure out what this means. Therefore, the blackhole and 
refused certs are unquestionably misissuances, if not also missing and expired.

Regards,
Andrew


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: Certificate with Debian weak key issued by Let's Encrypt

[Alex Gaynor via dev-security-policy]

I'd like to push a bit harder on searching for more systemic remediations.
"We forgot to get around to revoking it" is a pretty common element of CAs'
post-mortems, I think it'd be good for us to dig deeper.

For example, does Let's Encrypt have a runbook that gets used on
misissuance reports? Is one the steps creating a persistent tracking item
(e.g. a bug/ticket/issue) to revoke as required?

I created https://misissued.com/ to assist the mdsp community in tracking
these types of issues. It doesn't have any auth, so obviously anyone can
put whatever garbage they want in (please don't though :-)), but if someone
would find exposing data on a per-CA basis, or as JSON, or something else
useful, I'd be more than happy to.

These are just some off the cuff thoughts, but IMO "human error" should be
a root cause of last resort.

Alex

On Mon, Sep 11, 2017 at 11:08 AM, josh--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This was simple human error. There isn't a programmatic fix.
>
> Our team is planning to scan our database for weak keys again early this
> week. In any case, any weak key certs issued prior to our July 20 fix will
> expire in at most 37 days.
>
> On Monday, September 11, 2017 at 8:24:49 AM UTC-5, Alex Gaynor wrote:
> > Hi Josh,
> >
> > Does Let's Encrypt plan to implement any systematic or programmatic fixes
> > to ensure certificates are promptly revoked in the future?
> >
> > Did you perform a scan of all your issued certificates to see if any
> others
> > were effected?
> >
> > Alex
> >
> > On Sat, Sep 9, 2017 at 8:14 PM, josh--- via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > Thank you for bringing this oversight to our attention. The
> certificate in
> > > question has been revoked.
> > >
> > > The original incident report from July 16 was accidentally considered
> > > closed on the basis of a fix for our infrastructure without actually
> > > revoking the certificate that led to the report.
> > >
> > > Reading the recorded conversation, it seems we got overly focused on
> fix
> > > for our infrastructure and lost sight of the fact that the certificate
> > > itself needed to be revoked. I imagine our guard was let down a bit by
> the
> > > fact that the cert was issued specifically to test us, it wasn't a
> weak key
> > > "in the wild."
> > >
> > > Let’s Encrypt has checked for some forms of weak keys since we
> launched,
> > > and we added additional checks that would have caught this on July 20,
> > > 2017. We were already in the process of developing and deploying the
> > > additional checks before we received the original report from Hanno.
> > >
> > > On Saturday, September 9, 2017 at 2:22:07 PM UTC-5, Hanno Böck wrote:
> > > > Hi,
> > > >
> > > > A while ago I tested how some CAs would react to certificate requests
> > > > with debian weak keys.
> > > >
> > > > I was able to get a certificate from Let's Encrypt with a debian weak
> > > > key. Here is it:
> > > > https://crt.sh/?id=173588030
> > > >
> > > > I reported this to Let's Encrypt. They told me that they are aware
> they
> > > > weren't checking debian weak keys, but they were in the process of
> > > > deploying a check:
> > > > https://github.com/letsencrypt/boulder/pull/2765
> > > >
> > > > I don't know if this is active by now, but I assume so.
> > > >
> > > > Maybe notable: The certificate hasn't been revoked, despite me
> > > > reporting it. However I haven't explicitely asked for revocation
> (and I
> > > > could revoke it myself, given that I have the private key).
> > > >
> > > >
> > > > I have also tried to get a cert with a debian weak key from the
> > > > free trial offerings from Comodo and Symantec. Both rejected the
> > > > request.
> > > >
> > > > --
> > > > Hanno Böck
> > > > https://hboeck.de/
> > > >
> > > > mail/jabber: ha...@hboeck.de
> > > > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
> > >
> > > ___
> > > 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAA Certificate Problem Report

[Gervase Markham via dev-security-policy]

On 09/09/17 10:21, Jeremy Rowley wrote:
> Certificate 1 contains a single DNS identifier for
> big.basic.caatestsuite.com  .  This DNS
> name has a CAA resource record set that is too large to fit within a single
> DNS UDP packet, but small enough to fit within a DNS TCP packet.  The only
> CAA record containing an issue property is:
> 
> big.basic.caatestsuite.com  . IN
> CAA 0 issue "caatestsuite.com  "
> 
> Therefore, only caatestsuite.com   is allowed to
> issue for this identifier.

>From the discussion so far, I'd say that this one is clearly a
misissuance, and needs treating as one. (I see this as a clever vuln,
not as CA implementation incompetence.)

The jury is still out on the CNAME and DNSSEC-based reports.

Gerv

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

Re: Certificate with Debian weak key issued by Let's Encrypt

[josh--- via dev-security-policy]

This was simple human error. There isn't a programmatic fix.

Our team is planning to scan our database for weak keys again early this week. 
In any case, any weak key certs issued prior to our July 20 fix will expire in 
at most 37 days.

On Monday, September 11, 2017 at 8:24:49 AM UTC-5, Alex Gaynor wrote:
> Hi Josh,
> 
> Does Let's Encrypt plan to implement any systematic or programmatic fixes
> to ensure certificates are promptly revoked in the future?
> 
> Did you perform a scan of all your issued certificates to see if any others
> were effected?
> 
> Alex
> 
> On Sat, Sep 9, 2017 at 8:14 PM, josh--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > Thank you for bringing this oversight to our attention. The certificate in
> > question has been revoked.
> >
> > The original incident report from July 16 was accidentally considered
> > closed on the basis of a fix for our infrastructure without actually
> > revoking the certificate that led to the report.
> >
> > Reading the recorded conversation, it seems we got overly focused on fix
> > for our infrastructure and lost sight of the fact that the certificate
> > itself needed to be revoked. I imagine our guard was let down a bit by the
> > fact that the cert was issued specifically to test us, it wasn't a weak key
> > "in the wild."
> >
> > Let’s Encrypt has checked for some forms of weak keys since we launched,
> > and we added additional checks that would have caught this on July 20,
> > 2017. We were already in the process of developing and deploying the
> > additional checks before we received the original report from Hanno.
> >
> > On Saturday, September 9, 2017 at 2:22:07 PM UTC-5, Hanno Böck wrote:
> > > Hi,
> > >
> > > A while ago I tested how some CAs would react to certificate requests
> > > with debian weak keys.
> > >
> > > I was able to get a certificate from Let's Encrypt with a debian weak
> > > key. Here is it:
> > > https://crt.sh/?id=173588030
> > >
> > > I reported this to Let's Encrypt. They told me that they are aware they
> > > weren't checking debian weak keys, but they were in the process of
> > > deploying a check:
> > > https://github.com/letsencrypt/boulder/pull/2765
> > >
> > > I don't know if this is active by now, but I assume so.
> > >
> > > Maybe notable: The certificate hasn't been revoked, despite me
> > > reporting it. However I haven't explicitely asked for revocation (and I
> > > could revoke it myself, given that I have the private key).
> > >
> > >
> > > I have also tried to get a cert with a debian weak key from the
> > > free trial offerings from Comodo and Symantec. Both rejected the
> > > request.
> > >
> > > --
> > > Hanno Böck
> > > https://hboeck.de/
> > >
> > > mail/jabber: ha...@hboeck.de
> > > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
> >
> > ___
> > 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: Lack of CAA checking at Comodo

[Rob Stradling via dev-security-policy]

Hi Hanno.  Thanks for reporting this to us.  We acknowledge the problem, 
and as I mentioned at [1], we took steps to address it this morning.


We will follow-up with an incident report ASAP.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1398545#c3

On 11/09/17 15:18, Hanno Böck via dev-security-policy wrote:

Hi,

On saturday I was able to receive a certificate from comodo depsite the
subdomain having a CAA record only allowing Let's Encrypt as the CA.
Here's the cert:
https://crt.sh/?id=207082245

I have by now heard from multiple other people that confirmed the same.
Seems right now Comodo isn't checking CAA at all. There's also a bug in
the Mozilla bug tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=1398545

I was originally informed about the lack of CAA checking at Comodo by
Michael Kliewe from the mail provider mail.de. However that was before
CAA became mandatory. But even back then the Comodo webpage claimed that
Comodo would check CAA since at least 12 months:
https://support.comodo.com/index.php?/Knowledgebase/Article/View/1204/1/caa-record---certification-authority-authorization

I have covered this also today in a news article for Golem.de [1]


[1]
https://www.golem.de/news/tls-zertifikate-zertifizierungsstellen-muessen-caa-records-pruefen-1709-129981.html
google translate:
https://translate.google.de/translate?sl=de=en=y=_t=de=UTF-8==url=https%3A%2F%2Fwww.golem.de%2Fnews%2Ftls-zertifikate-zertifizierungsstellen-muessen-caa-records-pruefen-1709-129981.html



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

Lack of CAA checking at Comodo

[Hanno Böck via dev-security-policy]

Hi,

On saturday I was able to receive a certificate from comodo depsite the
subdomain having a CAA record only allowing Let's Encrypt as the CA.
Here's the cert:
https://crt.sh/?id=207082245

I have by now heard from multiple other people that confirmed the same.
Seems right now Comodo isn't checking CAA at all. There's also a bug in
the Mozilla bug tracker:
https://bugzilla.mozilla.org/show_bug.cgi?id=1398545

I was originally informed about the lack of CAA checking at Comodo by
Michael Kliewe from the mail provider mail.de. However that was before
CAA became mandatory. But even back then the Comodo webpage claimed that
Comodo would check CAA since at least 12 months:
https://support.comodo.com/index.php?/Knowledgebase/Article/View/1204/1/caa-record---certification-authority-authorization

I have covered this also today in a news article for Golem.de [1]


[1]
https://www.golem.de/news/tls-zertifikate-zertifizierungsstellen-muessen-caa-records-pruefen-1709-129981.html
google translate:
https://translate.google.de/translate?sl=de=en=y=_t=de=UTF-8==url=https%3A%2F%2Fwww.golem.de%2Fnews%2Ftls-zertifikate-zertifizierungsstellen-muessen-caa-records-pruefen-1709-129981.html

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: StartCom cross-signs disclosed by Certinomis

[Inigo Barreira via dev-security-policy]

Hi Gerv,

Those updates are referred basically to the format of the report in which
Franck asked to include specific information such as the serial number,
names, etc. according to your instructions. The report itself has not been
changed (that´s forbidden).

Regarding the qualifications or findings, the majority of them were fixed at
that time as the auditors explain in the section "other questions". There
were only 2 pending, the BCP and the TSA, which have been finished and do
not affect to the validation processes.
I can provide responses to all those findings, as I did to the auditors,
with evidences. 

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Gervase Markham via dev-security-policy
Sent: lunes, 11 de septiembre de 2017 13:27
To: Franck Leroy ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom cross-signs disclosed by Certinomis

Hi Franck,

On 03/08/17 08:59, Franck Leroy wrote:
> On end of June the audit report form PwC was available but with still some
minor issues. I asked StartCom to correct them.
> 
> On July 14th the audit report and the policy were updated and published on
StartCom website.

The audit reports on StartCom's website
 are dated at the end of June, and have
significant qualifications. E.g.:
https://www.startcomca.com/pwc-webtrust-ca-2017.pdf

What updates to the audit reports were made on July 14th?

Do you consider these audit reports sufficient to say the StartCom has
passed these audits, despite the qualifications therein?

Gerv

___
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: CAs not compliant with CAA CP/CPS requirement

[info--- via dev-security-policy]

El viernes, 8 de septiembre de 2017, 21:25:20 (UTC+2), Andrew Ayer  escribió:
> The BRs state:
> 
> "Effective as of 8 September 2017, section 4.2 of a CA's Certificate
> Policy and/or Certification Practice Statement (section 4.1 for CAs
> still conforming to RFC 2527) SHALL state the CA's policy or practice
> on processing CAA Records for Fully Qualified Domain Names; that policy
> shall be consistent with these Requirements. It shall clearly specify
> the set of Issuer Domain Names that the CA recognises in CAA 'issue' or
> 'issuewild' records as permitting it to issue. The CA SHALL log all
> actions taken, if any, consistent with its processing practice."
> 
> Since it is now 8 September 2017, I decided to spot check the CP/CPSes
> of some CAs.
> 
> At time of writing, the latest published CP/CPSes of the following CAs
> are not compliant with the above provision of the BRs:
> 
> Amazon (https://www.amazontrust.com/repository/) - Does not check CAA
> 
> Comodo (https://www.comodo.com/about/comodo-agreements.php) - Does not
> specify issuer domain names
> 
> DigiCert (https://www.digicert.com/legal-repository/) - Does not
> specify issuer domain names, and processing is not compliant with BRs
> ("If a CAA record exists that does not list DigiCert as an authorized
> CA, DigiCert verifies that the applicant has authorized issuance,
> despite the CAA record.")
> 
> Google Trust Services (https://pki.goog/) - Does not check CAA
> 
> Identrust (https://secure.identrust.com/certificates/policy/ts/) -
> Does not check CAA
> 
> Izenpe
> (http://www.izenpe.eus/s15-content/en/contenidos/informacion/descarga_certificados/es_url/index.shtml)
> - Does not specify issuer domain names
> 
> PROCERT (https://www.procert.net.ve/eng/ca.html) - No mention of CAA
> 
> Symantec / GeoTrust (https://www.geotrust.com/resources/repository/legal/)
> - Does not specify issuer domain names
> 
> Trustis (https://www.trustis.com/pki/trustis-ssl/standard/index.htm) -
> No mention of CAA
> 
> Visa (http://www.visa.com/pki/) - Does not check CAA
> 
> 
> These CAs have compliant CP/CPSes:
> 
> Entrust
> 
> GlobalSign
> 
> GoDaddy
> 
> Let's Encrypt
> 
> QuoVadis
> 
> Trustwave
> 
> 
> It would be nice to hear confirmation from the non-compliant CAs that they
> really are checking CAA as required, and if so, why they overlooked the
> requirement to update their CP/CPS.
> 
> Regards,
> Andrew

Izenpe has approbed and published the last version of CP, especifing the 
issuer domain name.
Best regards
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: CAs not compliant with CAA CP/CPS requirement

[Jeremy Rowley via dev-security-policy]

Let me pull the data and share it with you. For some reason we saw a few sub 
domains right before the 8th. We added *.digicerts.com at the last minute until 
we had time to figure out why. I suspect it's being caused by documentation or 
a partner telling the customers the wrong thing. Once we track down the source, 
we can drop the wildcard.

> On Sep 11, 2017, at 5:09 AM, Gervase Markham  wrote:
> 
> Hi Ben and Jeremy,
> 
>> On 09/09/17 01:25, Ben Wilson wrote:
>> Those are typos.  See section 4.2.1 of our CPS posted here:
>> https://www.digicert.com/wp-content/uploads/2017/09/DigiCert_CPS_v412.pdf 
> 
> This reads:
> 
> "The Certification Authority CAA identifying domains for CAs within
> DigiCert’s operational control are “digicert.com”, “digicert.ne.jp”,
> "cybertrust.ne.jp”, and any domain containing those identifying domains
> as suffixes (e.g. *.digicert.com)."
> 
> This latter part, while not perhaps being against the letter of the RFC,
> is somewhat unhelpful for people who want to write software working with
> CAA, because they now can't just load it with a per-CA list of valid
> domain names, but have to post-process and stem the value in this case.
> Are you certain you need that provision?
> 
> Gerv
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom cross-signs disclosed by Certinomis

[Gervase Markham via dev-security-policy]

Hi Franck,

On 03/08/17 08:59, Franck Leroy wrote:
> On end of June the audit report form PwC was available but with still some 
> minor issues. I asked StartCom to correct them.
> 
> On July 14th the audit report and the policy were updated and published on 
> StartCom website.

The audit reports on StartCom's website
 are dated at the end of June, and
have significant qualifications. E.g.:
https://www.startcomca.com/pwc-webtrust-ca-2017.pdf

What updates to the audit reports were made on July 14th?

Do you consider these audit reports sufficient to say the StartCom has
passed these audits, despite the qualifications therein?

Gerv

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

Re: CAs not compliant with CAA CP/CPS requirement

[Gervase Markham via dev-security-policy]

Hi Ben and Jeremy,

On 09/09/17 01:25, Ben Wilson wrote:
> Those are typos.  See section 4.2.1 of our CPS posted here:
> https://www.digicert.com/wp-content/uploads/2017/09/DigiCert_CPS_v412.pdf 

This reads:

"The Certification Authority CAA identifying domains for CAs within
DigiCert’s operational control are “digicert.com”, “digicert.ne.jp”,
"cybertrust.ne.jp”, and any domain containing those identifying domains
as suffixes (e.g. *.digicert.com)."

This latter part, while not perhaps being against the letter of the RFC,
is somewhat unhelpful for people who want to write software working with
CAA, because they now can't just load it with a per-CA list of valid
domain names, but have to post-process and stem the value in this case.
Are you certain you need that provision?

Gerv

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

Re: PROCERT issues

[Gervase Markham via dev-security-policy]

Hi Alejandro,

Thank you for this initial response. It is, however, far less detailed
than we would like to see. In the email I sent to you letting you know
that we were looking at PROCERT, I wrote:

"You may wish to review a similar issue list we created for Symantec:
https://wiki.mozilla.org/CA:Symantec_Issues
in order to see how such a wiki page might develop in the future. For
example, we would expect most or all issues on your list to soon carry a
"PROCERT Response" section. Good responses will be more than "yes, we
have revoked the certificate" or even "we have revoked, and updated our
software". We want to know how each problem occurred in the first place,
and why it was not detected until now by PROCERT's existing systems for
quality control. This wiki page:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance
gives best practices in responding to incidents and writing reports,
which may prove useful in formulating your responses."

It seems you have chosen not to follow this advice, as many of your
responses consist solely of an assertion that you have revoked and
replaced the problematic certificates. So, because there is no root
cause analysis, we have no assurance at all that the issue will not
occur again.

Even beyond that major concern, I think there are some of these issues
where you have not entirely understood the problem.

On 08/09/17 20:09, PSC Procert wrote:
> Issue E: Issuance of 1024-bit Certificate (December 2016)
> Procert:
> 
> Based on internals test and validation, we contacting the client, we asking 
> for a new CSR and proceed to revoke and reissue the certificate in 2048, 
> supporting into the installation process. We completed those actions in this 
> point.

Your cut-and-paste answer is inapplicable in this case, because the
"client" was PROCERT itself - the certificate in question was an OCSP
responder cert.

> Issue L: helloburgershack.com (June - July 2017)
> 
> Procert:
> 
> Based on internals test and validation, we contacting the client, we asking 
> for a new CSR and proceed to revoke and reissue the certificate, supporting 
> into the installation process. This client provides a production window after 
> the next Tuesday in order to proceed with the revoke and the reissue of the 
> certificate. Pending action.

What was sought here was an explanation of why it took five attempts to
issue this certificate, and even the last version had problems.

> Issue M: CPS not in RFC 3647 or RFC 2527 Format (2011 - August 2017)
> 
> Procert:
> 
> After a validation process, we modify the RFC number in our documentation. We 
> complete this point.

I think you misunderstand. The issue here is not that some RFC number in
the document is wrong, but that your document is not arranged according
to the layout given in RFC3647. To fix this would require completely
rearranging the document. Are you saying that you have already completed
this? If so, can we see a copy of the updated document?

> Issue O: OCSP Servers Return "Good" for Non-Existent Certificates (Unknown - 
> August 2017)

> Now we stay contacting Microsoft in order to obtain and adequate procedure or 
> batch. In paralleled we work in our own OCSP software. 

I suggest that writing and deploying your own OCSP software is unlikely
to be a route towards speedy conformance with all applicable
regulations. If you are unable to get Microsoft's software to function,
I would suggest approaching another vendor. But perhaps another CA has
the Microsoft software working, and could help out? You may want to ask
on the CAB Forum list.

> Issue P: Use of SHA-1 To Sign OCSP Responses (Unknown - August 2017)
> 
> Procert:
> 
> We check the standard, the OCSP certificate is SHA 256, the answer in this 
> case is an observation. We work to check and validate the adjust to SHA 256 
> in the OCSP answer. This situation does not contravene any standard.

No, but it does contradict your assertions in your responses to two
previous Mozilla CA Communications.

> Issue Q: CRL Distribution Points Using HTTPS (August 2012 - August 2017)
> 
> Procert:
> 
> Please validate the certificate issuance. This certificate is not issued by 
> PSC PROCERT

You are quite right - my apologies. It's from a different part of the
Venezuelan Goverment's hierarchy. I was sent a large list of
certificates with this problem but a few others I've sampled also seem
to be from other parts. I will look into this and see if I can find an
example issued by PROCERT; if not, I will strike this issue.

> Issue S: Non-Random Serial Numbers (September 2016 - August 2017)
> 
> Procert:
> 
> We check the observation. Procert technical staff applied the observation and 
> fix the system in this particular point.

Please can you explain the method of construction used for the most
recent serial numbers, e.g. the one on https://crt.sh/?id=207894453?

> Issue X: High Percentage of Revocations (August 2017) 
> 
> Procert:
> 
> Staff takes actions considering the observations 

Re: Incident Certificate signed with SHA1 Violation BR 7.3.1

[Gervase Markham via dev-security-policy]

Hi Connie,

On 06/09/17 20:38, cornelia.enk...@gmail.com wrote:
> SwissSign has identified the following incident:
> two Certificate signed with SHA1: Violation BR 7.3.1

Thank you for this report. There have been a couple of reasonable
follow-up questions here in the m.d.s.p. group; could you please answer
them?

> 6)
> The additional functionality introduced in January 2017 had a weak point. 
> This vulnerability was only found because of the detailed error analysis 
> performed by finding the certificate that was misissued. 
> The misissued certificates where detected by the improved quality control. No 
> further measures are currently planned.

Have automated tests been put in place to make sure the operation of
reissuing a SHA-1 certificate always fails, even after further updates
to the software?

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

Re: StartCom cross-signs disclosed by Certinomis

[Gervase Markham via dev-security-policy]

Getting back to this very late... I am studying this situation today.

On 07/08/17 10:21, Franck Leroy wrote:
> Then in November 2016 I contacted Kathleen and Gerv to know if there was some 
> stoppers to work with Inigo to help StartCom to be back in the business.
> There was no opposition as long as we follow the requirements of the 
> remediation plan. Gerv also answered that our plan was good to him.

The plan I approved was the following (quoting you):


"May be the safer solution for the interim period they have their new
root trusted, is that ;

  + we create a new subCAs with startssl names (signed by Certinomis
root) in our pki systems on a dedicated HSM.

  + startcom will only have RA access, and we can control all certs
issuance as the HSM is under our control.

  + when startssl new root is publicly trusted by Mozilla, we give the
HSM and an export of the database to Startcom.

  + then startcom cross sign the dedicated CAs with their new root, and
then they are autonomous to use the CAs their own pki system."


This seems to be very different to the plan you implemented.

In that email exchange, you asked if a cross-sign was permitted.
Kathleen replied:


"It would have to be for their new root(s) only. Definitely not allowed
for their old roots.

As always, the CA with the root cert in Mozilla's program is responsible
for ensuring that their subCAs fully comply with the CA Browser Forum's
Baseline Requirements and Mozilla's CA Certificate Policy.

I think the following from
https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 would still apply:
"


Various bugs have been filed since then to suggest that StartCom has not
been following those two documents. In addition, StartCom's first
attempt at demonstrating they had met that list of action items (leaving
aside the question of whether they, in fact, have) was in mid-July:
https://bugzilla.mozilla.org/show_bug.cgi?id=1311832#c12

This was long after you did your cross-sign.

I am continuing to consider what the best next steps are in this situation.

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

Re: CAs not compliant with CAA CP/CPS requirement

[Kim Nguyen via dev-security-policy]

Am Freitag, 8. September 2017 21:25:20 UTC+2 schrieb Andrew Ayer:
> The BRs state:
> 
> "Effective as of 8 September 2017, section 4.2 of a CA's Certificate
> Policy and/or Certification Practice Statement (section 4.1 for CAs
> still conforming to RFC 2527) SHALL state the CA's policy or practice
> on processing CAA Records for Fully Qualified Domain Names; that policy
> shall be consistent with these Requirements. It shall clearly specify
> the set of Issuer Domain Names that the CA recognises in CAA 'issue' or
> 'issuewild' records as permitting it to issue. The CA SHALL log all
> actions taken, if any, consistent with its processing practice."
> 
> Since it is now 8 September 2017, I decided to spot check the CP/CPSes
> of some CAs.
> 
> At time of writing, the latest published CP/CPSes of the following CAs
> are not compliant with the above provision of the BRs:
> 
> Amazon (https://www.amazontrust.com/repository/) - Does not check CAA
> 
> Comodo (https://www.comodo.com/about/comodo-agreements.php) - Does not
> specify issuer domain names
> 
> DigiCert (https://www.digicert.com/legal-repository/) - Does not
> specify issuer domain names, and processing is not compliant with BRs
> ("If a CAA record exists that does not list DigiCert as an authorized
> CA, DigiCert verifies that the applicant has authorized issuance,
> despite the CAA record.")
> 
> Google Trust Services (https://pki.goog/) - Does not check CAA
> 
> Identrust (https://secure.identrust.com/certificates/policy/ts/) -
> Does not check CAA
> 
> Izenpe
> (http://www.izenpe.eus/s15-content/en/contenidos/informacion/descarga_certificados/es_url/index.shtml)
> - Does not specify issuer domain names
> 
> PROCERT (https://www.procert.net.ve/eng/ca.html) - No mention of CAA
> 
> Symantec / GeoTrust (https://www.geotrust.com/resources/repository/legal/)
> - Does not specify issuer domain names
> 
> Trustis (https://www.trustis.com/pki/trustis-ssl/standard/index.htm) -
> No mention of CAA
> 
> Visa (http://www.visa.com/pki/) - Does not check CAA
> 
> 
> These CAs have compliant CP/CPSes:
> 
> Entrust
> 
> GlobalSign
> 
> GoDaddy
> 
> Let's Encrypt
> 
> QuoVadis
> 
> Trustwave
> 
> 
> It would be nice to hear confirmation from the non-compliant CAs that they
> really are checking CAA as required, and if so, why they overlooked the
> requirement to update their CP/CPS.
> 
> Regards,
> Andrew

Dear all,
we can confirm that D-Trust is also performing CAA as required, the updated 
CA/CPS is currently under Review with our conformity assessment Body and will 
be published as soon as possible. 
Regards, Kim
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy