Re: Miss-issuance: URI in dNSName SAN

2017-07-22 Thread Ryan Sleevi via dev-security-policy
On Fri, Jul 21, 2017 at 4:04 AM ramirommunoz--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> El jueves, 20 de julio de 2017, 16:49:15 (UTC+2), Gervase Markham
> escribió:
> > On 19/07/17 14:53, Alex Gaynor wrote:
> > > I'd like to report the following instance of miss-issuance:
> >
> > Thank you. Again, I have drawn this message to the attention of the CAs
> > concerned (Government of Venezuela and Camerfirma).
> >
> > Gerv
>
> Hi all
>
> Regarding Camerfirma certificates, we have follow the rules imposed by the
> local public administration to regulate the profile of several
> certificates. SSL certificates for public administration websites included.
> There is a entry in cabforum where this issue is described
> https://cabforum.org/pipermail/public/2016-June/007896.html.
> New eIDAS regulation has forced to Spanish Administration to fix this
> problem so from now on we can issue certificate that fully fulfil the
> cabforum rules.
> AC Camerfirma will offer to our public administration customers to renew
> the SSL certificates  with our new eIDAS 2016 CAs.


Could you point where the regulation require(s/d) the CN and SAN (in type
dNSName) contain a URI?

The past discussion was in context of additional SAN types not permitted by
the BRs, but the issue highlighted in this thread is clear violation of RFC
5280 semantics, and it is difficult to believe that was encompassed by
Camerafirma's previous disclosure.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Regarding CA requirements as to technical infrastructure utilized in automated domain validations, etc. (if any)

2017-07-22 Thread birgelee--- via dev-security-policy
On Friday, July 21, 2017 at 5:06:42 PM UTC-5, Matthew Hardeman wrote:
> It seems that a group of Princeton researchers just presented a live 
> theoretical* misissuance by Let's Encrypt.
> 
> They did a sub-prefix hijack via a technique other than those I described 
> here and achieved issuance while passing-through traffic for other 
> destination within the IP space of the hijacked scope.
> 
> They've got a paper at: 
> https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.pdf
> 
> I say that theoretical because they hijacked a /24 of their own /23 under a 
> different ASN but I am given to believe that the "adversarial" ASN is also 
> under their control or that they had permission to use it.  In as far as this 
> is the case, this technically isn't a misissuance because hijacking ones own 
> IP space is technically just a different routing configuration diverting the 
> traffic to the destination they properly control to another point of 
> interconnection they properly controlled.

Hi,

I am Henry Birge-Lee, one of the researchers at Princeton leading that effort. 
I just performed that live demo a couple hours ago. You are correct about how 
we performed that attack. One minor detail is that we were forced to use the 
same ASN twice (for both the adversary and the victim). The adversary and the 
victim were two different routers peering with completely different ASes, but 
we were forced to reuse the AS because we were performing the announcements 
with the PEERING testbed (https://peering.usc.edu/) and are not allowed to 
announce from another ASN. Thus from a policy point of view this was not a 
misissuance and our BGP announcements would likely not have triggered an alarm 
from a BGP monitoring system. Even if we had the ability to hijack another ASes 
prefix and trigger such alarms we would be hesitant to because of ethical 
considerations. Our goal was to demonstrate the effectiveness and ease of 
interception of the technique we used, not freak out network operat
 ors because of potential hijacks.

I know some may argue that had we triggered alarms from the major BGP 
monitoring frameworks, CAs might not have issued us the certificates the did. 
We find that this is unlikely because 1) The DV certificate signing process is 
automated but the type of BGP announcements we made would likely require manual 
review before they could be definitively flagged as an attack 2) There is no 
evidence CAs are doing this (we know Let's Encrypt does not use BGP data 
because of their transparency and conversations with their executive director 
Josh Aas as well as their engineering team).

As for further work, implementation of countermeasures into the CA and Browser 
forum Baseline Requirements is our eventual goal and we see engaging with this 
ongoing discussion as a step in the right direction.

Over the next couple days I will look over these conversations in more detail 
and look for ways that we can integrate these ideas into the research we are 
doing.

Best,
Henry Birge-Lee

Princeton University department of Computer Science
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Miss-issuance: URI in dNSName SAN

2017-07-22 Thread ramirommunoz--- via dev-security-policy
El jueves, 20 de julio de 2017, 16:49:15 (UTC+2), Gervase Markham  escribió:
> On 19/07/17 14:53, Alex Gaynor wrote:
> > I'd like to report the following instance of miss-issuance:
> 
> Thank you. Again, I have drawn this message to the attention of the CAs
> concerned (Government of Venezuela and Camerfirma).
> 
> Gerv

Hi all

Regarding Camerfirma certificates, we have follow the rules imposed by the 
local public administration to regulate the profile of several certificates. 
SSL certificates for public administration websites included. There is a entry 
in cabforum where this issue is described 
https://cabforum.org/pipermail/public/2016-June/007896.html.
New eIDAS regulation has forced to Spanish Administration to fix this problem 
so from now on we can issue certificate that fully fulfil the cabforum rules.
AC Camerfirma will offer to our public administration customers to renew the 
SSL certificates  with our new eIDAS 2016 CAs. 

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


Re: Certigna Root Renewal Request

2017-07-22 Thread josselin.allemandou--- via dev-security-policy
The ticket is open since 3 months. This seems to be correct for everyone. 
Is it possible to close it now ?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy