date:20180205

Re: Certificates with 2008 Debian weak key bug

2018-02-05 Thread Wayne Thayer via dev-security-policy

On Mon, Feb 5, 2018 at 4:33 PM, Alex Cohn via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I logged two of those five certificates (https://crt.sh/?id=308392091
> and https://crt.sh/?id=307753186) to Argon, as part of a project to
> log every certificate in the censys.io database to a public CT log. I
> believe Censys found them by scanning all of IPv4 and grabbing the
> default (i.e. no SNI) certificate presented on port 443.
>
> Given that this method will not uncover every certificate ever issued,
> and that Certum isn't or wasn't checking for weak keys and isn't
> logging certificates to CT, should Mozilla ask Certum to scan every
> currently-valid certificate they have issued for weak keys?
>
> Thanks for pointing this out Alex. I would like to think that this is
required by the incident report, but it's not specifically called out, so I
added this request to the bug.

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

Re: Certificates with 2008 Debian weak key bug

2018-02-05 Thread Alex Cohn via dev-security-policy

I logged two of those five certificates (https://crt.sh/?id=308392091
and https://crt.sh/?id=307753186) to Argon, as part of a project to
log every certificate in the censys.io database to a public CT log. I
believe Censys found them by scanning all of IPv4 and grabbing the
default (i.e. no SNI) certificate presented on port 443.

Given that this method will not uncover every certificate ever issued,
and that Certum isn't or wasn't checking for weak keys and isn't
logging certificates to CT, should Mozilla ask Certum to scan every
currently-valid certificate they have issued for weak keys?

Alex

On Mon, Feb 5, 2018 at 2:56 PM, Hanno Böck via dev-security-policy
 wrote:
> On Mon, 5 Feb 2018 12:07:06 -0500
> Eric Mill via dev-security-policy
>  wrote:
>
>> WoSign and StartCom are untrusted, but Certum is still trusted, right?
>
> Yes.
>
> In case that was unclear: The sentence "As we all know these are no
> longer trusted by Mozilla, ..." was referring to the chapter above,
> i.e. the three Startcom+Wosign certs, not the whole mail.
>
> --
> 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: Validation Summit

2018-02-05 Thread tech29063--- via dev-security-policy

The CA/Browser Forum’s Bylaws at Section 2.3(c) allow the Forum Chair 
(currently me) to invite Interested Parties to participate in Working Group 
meetings.

I hereby extend an invitation to Forum Interested Parties to participate in 
person or remotely in the all-day Validation Working Group meeting on Tuesday, 
March 6, 2018 at Amazon’s offices in Herndon, VA (located near Dulles Airport). 
 If you are employed by a Forum member, please coordinate with your company’s 
regular Forum representatives.  This invitation is for the Tuesday Validation 
Working Group meeting only, and does not extend to the Forum’s plenary sessions 
on Wednesday and Thursday.

All Interested Parties who want to participate should send their name and 
contact information (email address and phone, preferably) to Tim Hollebeek and 
Wayne Thayer, [tim-dot-hollebeek-at-digicert –dot-com and 
wthayer-at-mozilla-dot-com].  Tim and Wayne will provide you with additional 
details and logistics for participating in the meeting.

To become an Interested Party who is eligible to participate, before the 
meeting you must sign and return a copy of the Forum’s ”Intellectual Property 
Rights Agreement-1.2-PKI-enabled” found here: 
https://cabforum.org/ipr-policy/ 
https://cabforum.org/wp-content/uploads/Intellectual-Property-Rights-Agreement-1.2-PKI-enabled.pdf
 

Participants must also follow the Forum’s Code of Conduct found at Exhibit C of 
the Bylaws, 
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-Bylaws-v.-1.7.pdf 

Thanks to all for your interest.

Kirk Hall, Chair
CA/Browser Forum
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Validation Summit

2018-02-05 Thread Wayne Thayer via dev-security-policy

Gerv and I have made, and the CA/Browser Forum has accepted a proposal to
convene a "Validation Summit" on Tuesday March 6th during the next
regularly scheduled CA/Browser Forum face-to-face meeting that will be held
in the Washington DC area.

The intent of this summit is to perform an analysis of each of the "blessed
10" domain validation methods, identify weaknesses, and determine if each
method needs to be improved or deprecated. You can find a proposed agenda
at [1].

The CA/Browser Forum has agreed to invite security experts who have
specialized knowledge of threat analysis and CA operations to participate,
and I would like to extend that invitation to members of the Mozilla
security community. It would be particularly helpful to have participants
who have experience in the following areas:



   1. Real-world experience with the validation procedures as they are
   currently practiced by public CAs
   2. Experience with threat modeling, analyzing a variety of protocols, or
   other methods for rigorously analyzing processes and procedures for
   potential vulnerabilities
   3. Deep technical expertise related to how validation-related
   technologies perform and/or fail in the real world (DNS, WHOIS, Domain
   Registrars, Reverse IP lookup, and so on)
   4. Technical challenges that prevent various validation methods from
   being usable by a significant fraction of certificate applicants, and thus
   drive users towards less desirable methods
   5. Automation of validation protocols (i.e. ACME)

Those putting their names forward should be prepared to adhere to the Code
of Conduct [2] and to participate in a constructive discussion that remains
focused on the topic at hand. If you would like to participate, you will be
required to become an Interested Party [3] and sign the CA/Browser Forum
IPR Agreement. [4] (Note: if your company is already a CA/Browser Forum
member, please check with your representative)

If you intend to meet these requirements and attend the summit as an
Interested Party, please email me (wthayer-at-mozilla-dot-com) so that I
can get you added to the list of attendees and provide more information.

We do expect to have a remote attendance option available; however, given
the size of the group, please be aware that it can be difficult to
participate even when the audio quality is good.  If you would like to
attend in-person but require travel/accommodation sponsorship, please
mention that in your email to me, along with a ballpark figure for costs
(estimate the hotel as $122 per night).

Wayne

[1] https://cabforum.org/pipermail/public/2018-February/012908.html
[2]
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-Bylaws-v.-1.7.pdf
(Exhibit C)
[3] https://cabforum.org/current-work
[3] https://cabforum.org/ipr-policy/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with 2008 Debian weak key bug

2018-02-05 Thread Hanno Böck via dev-security-policy

On Mon, 5 Feb 2018 12:07:06 -0500
Eric Mill via dev-security-policy
 wrote:

> WoSign and StartCom are untrusted, but Certum is still trusted, right?

Yes.

In case that was unclear: The sentence "As we all know these are no
longer trusted by Mozilla, ..." was referring to the chapter above,
i.e. the three Startcom+Wosign certs, not the whole mail.

-- 
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: Certificates with 2008 Debian weak key bug

2018-02-05 Thread Wayne Thayer via dev-security-policy

I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1435770
requesting an incident report from Certum.

On Mon, Feb 5, 2018 at 10:07 AM, Eric Mill via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> WoSign and StartCom are untrusted, but Certum is still trusted, right?
>
> Yes, the two certificates issued by Certum are trusted by Mozilla.

On Mon, Feb 5, 2018 at 11:08 AM, Hanno Böck via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Hi,
> >
> > I searched crt.sh for valid certificates vulnerable to the 2008 Debian
> > weak key bug. (Only 2048 bit.)
> >
> > Overall I found 5 unexpired certificates.
> >
> > Two certificates by Certum (reported on Saturday, Certum told me "We
> > have taken necessary steps to clarify this situation as soon as
> > possible", they're not revoked yet):
> > https://crt.sh/?id=308392091=ocsp
> > https://crt.sh/?id=663=ocsp
> >
> > Wosign:
> > https://crt.sh/?id=30347743
> > StartCom:
> > https://crt.sh/?id=54187884
> > https://crt.sh/?id=307753186
> >
> > As we all know these are no longer trusted by Mozilla, I reported them
> > nevertheless. No reply yet.
> >
> > Old bugs never die, I recommend every CA adds a check for the Debian
> > bug to their certificate issuance process.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with 2008 Debian weak key bug

2018-02-05 Thread Eric Mill via dev-security-policy

WoSign and StartCom are untrusted, but Certum is still trusted, right?

On Mon, Feb 5, 2018 at 11:08 AM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi,
>
> I searched crt.sh for valid certificates vulnerable to the 2008 Debian
> weak key bug. (Only 2048 bit.)
>
> Overall I found 5 unexpired certificates.
>
> Two certificates by Certum (reported on Saturday, Certum told me "We
> have taken necessary steps to clarify this situation as soon as
> possible", they're not revoked yet):
> https://crt.sh/?id=308392091=ocsp
> https://crt.sh/?id=663=ocsp
>
> Wosign:
> https://crt.sh/?id=30347743
> StartCom:
> https://crt.sh/?id=54187884
> https://crt.sh/?id=307753186
>
> As we all know these are no longer trusted by Mozilla, I reported them
> nevertheless. No reply yet.
>
> Old bugs never die, I recommend every CA adds a check for the Debian
> bug to their certificate issuance process.
>
> --
> 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
>



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

Certificates with 2008 Debian weak key bug

2018-02-05 Thread Hanno Böck via dev-security-policy

Hi,

I searched crt.sh for valid certificates vulnerable to the 2008 Debian
weak key bug. (Only 2048 bit.)

Overall I found 5 unexpired certificates.

Two certificates by Certum (reported on Saturday, Certum told me "We
have taken necessary steps to clarify this situation as soon as
possible", they're not revoked yet):
https://crt.sh/?id=308392091=ocsp
https://crt.sh/?id=663=ocsp

Wosign:
https://crt.sh/?id=30347743
StartCom:
https://crt.sh/?id=54187884
https://crt.sh/?id=307753186

As we all know these are no longer trusted by Mozilla, I reported them
nevertheless. No reply yet.

Old bugs never die, I recommend every CA adds a check for the Debian
bug to their certificate issuance process.

-- 
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: ComSign Root Renewal Request

2018-02-05 Thread Julien Cristau via dev-security-policy

Re Section 3.4, you seem to assume the domain holder is a ComSign
subscriber.  In case of misissuance, that may not be true.

Cheers,
Julien

On Mon, Feb 5, 2018 at 4:23 PM, YairE via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi, thank you for pointing the above
> Here is our response:
>
> Section 1.3.2.5
> We have corrected our CPS now that only limited actions could be performed
> by DTP's
> And they cannot perform domain validation.
>
> Section 3.2.2.4
> We are aware of the problems with the methods that have been raised, we
> thought that as long as they are permitted in the BR we would keep them
> included on our CPS, of course that we prefer not to use them and will use
> the more secured methods like 3.2.4.4.2, 3.2.4.4.3 etc.
> >After reviewing the January Communication we have removed the problematic
> methods from our CPS entirely.
>
> Section 3.2.2.8
> As Ryan mentioned Comsign’s CAA identifier is documented on section
> 4.2.1.1(v)
> We also added it in section 3.2.2.8 now
>
> Section 3.4
> I do not understand why does Ryan claim that a domain holder cannot
> request a revocation in case of misissuance, it clearly states that any
> subscriber could revoke any certificate for any reason he seems fit as long
> as they are identified.
>
> You can see all the updates on our CPS in our site repository:
> https://www.comsign.co.il/repository/
> on our UK site:
> https://www.comsign.co.uk/?page_id=1282
> and in this link as well:
> https://s3-us-west-2.amazonaws.com/comsign/CPS/CPS_4.1_eng.pdf
>
> Particularly Concerning
> The software we are currently using is RSA CA 6.7 on Solaris.
> As we mentioned we are now under audit on the new Microsoft CA and in the
> process of moving to that software instead of our old software.
> ___
> 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: ComSign Root Renewal Request

2018-02-05 Thread YairE via dev-security-policy

Hi, thank you for pointing the above
Here is our response:

Section 1.3.2.5
We have corrected our CPS now that only limited actions could be performed by 
DTP's
And they cannot perform domain validation. 

Section 3.2.2.4
We are aware of the problems with the methods that have been raised, we thought 
that as long as they are permitted in the BR we would keep them included on our 
CPS, of course that we prefer not to use them and will use the more secured 
methods like 3.2.4.4.2, 3.2.4.4.3 etc.
>After reviewing the January Communication we have removed the problematic 
>methods from our CPS entirely.

Section 3.2.2.8
As Ryan mentioned Comsign’s CAA identifier is documented on section 4.2.1.1(v)
We also added it in section 3.2.2.8 now

Section 3.4
I do not understand why does Ryan claim that a domain holder cannot request a 
revocation in case of misissuance, it clearly states that any subscriber could 
revoke any certificate for any reason he seems fit as long as they are 
identified.

You can see all the updates on our CPS in our site repository:
https://www.comsign.co.il/repository/
on our UK site:
https://www.comsign.co.uk/?page_id=1282
and in this link as well:
https://s3-us-west-2.amazonaws.com/comsign/CPS/CPS_4.1_eng.pdf

Particularly Concerning
The software we are currently using is RSA CA 6.7 on Solaris. 
As we mentioned we are now under audit on the new Microsoft CA and in the 
process of moving to that software instead of our old software.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with 2008 Debian weak key bug

Re: Certificates with 2008 Debian weak key bug

Re: Validation Summit

Validation Summit

Re: Certificates with 2008 Debian weak key bug

Re: Certificates with 2008 Debian weak key bug

Re: Certificates with 2008 Debian weak key bug

Certificates with 2008 Debian weak key bug

Re: ComSign Root Renewal Request

Re: ComSign Root Renewal Request

10 matches

Site Navigation

Mail list logo

Footer information