Re: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Jakob Bohm]

On 14/09/2016 16:11, Kyle Hamilton wrote:



On 9/12/2016 20:20, Jakob Bohm wrote:

On 13/09/2016 03:03, Kyle Hamilton wrote:

I would prefer not to see a securelogin-.arubanetworks.com
name, because such makes it look like Aruba Networks is operating the
captive portal.  If (for whatever reason) the system is compromised, or
the login process is altered, or there's a need to enter credit card
information [I do not know if these devices can be configured to require
payment, but since this group typically discusses policy in general I
think it's appropriate to address during this discussion] but there are
then unauthorized charges caused by the device being compromised, then
Aruba Networks is going to be the one who's called to answer for it.
Because Aruba sells the devices and plays no part in their ongoing
operation, they'll quite rightly shut any claim down.  This leads the
user to have no recourse.  I think it would be better if there were a
mandate that all of these devices obtain ACME (i.e., Let's Encrypt)
certificates when they first start up.

Provisioning a self-signed certificate for the administrator to
configure the device with prior to obtaining an ACME certificate would
in my mind be legitimate, as a warning that "hey, the device isn't
completely configured yet".  However, since I'm not a User Experience
guy, I may be incorrect here.

I also suggest that the now-revoked certificate should be put in the
OneCRL, because of its widespread
captive-DNS/captive-network/no-CRL-or-OCSP-retrieval environment and
compromised private key.


Just to clarify, I never said that the use was for a "captive portal"
or other such 3rd party hit address.  My presumption was that
https://securelogin.arubanetworks.com would be a manually entered URL
printed in the user manual or on the device itself.  However you may
have other sources for it being a captive portal.


http://community.arubanetworks.com/t5/Wireless-Access/Certificate-securelogin-arubanetworks-com-and-trial-SSL-certs/td-p/28158
is an Aruba Networks customer request to alter the name that the users
are directed to with a "guest wifi pass".  This, and other things,
indicate that the name in the now-revoked certifcate is used for captive
portal authentication (to prevent users from having their credentials
sniffed over an unencrypted wifi connection).



OK, you had a second source for that fact.


The securelogin-.arubanetworks.com domain name was my
hypothetical/suggested name for a cert not associated with a
shared/compromised key, but with a per-device certificate and key
generated on a secure production line before the device was put in a
cardboard box and shipped on a slow boat from China.


Understood.


The point of having a real trusted cert rather than a self-signed cert
for the first-time login would be to protect the user against a WiFi
spoofed MiTM, a protection which is gone for the revoked cert due to
the publicly compromised key.


I understand.  In this instance, I don't think it's quite as much a
problem as you're concerned about.  The configuration of such a
(managed, non-consumer-level) device would generally be performed over
the hardware network -- either in the configuration lab of the network
provider who purchased and is installing it, or on-site via the
hardwired network connection that it's bridging access to.  That
interface is guaranteed not to have guests connecting directly to it,
and so is really the only appropriate interface for secure things like
configuration to be done over.  (That said, there's a lot of
security-unconscious manufacturers out there -- but if they're
security-unconscious, they probably won't listen to this bit of security
advice, either.)



For non-managed devices (and some managed ones), it is common to have
only two interfaces: "outside/insecure/internet" and
"inside/secure/lan", with different classes of inside users
distinguished only by login and other such things.


For actual instances of configuration interfaces exposed over WiFi, this
approach is probably infeasible without a reworking of the architecture
of such devices (perhaps akin to the changes required by FCC for
consumer wifi routers in US to prevent installers of DD-WRT from setting
their region to Japan and using unauthorized 2.4GHz spectrum above
802.11a/b/g channel 11), as updated device firmware would need to be
distributed without the keys and certificates (which would need to stay
in secure memory, approximately like the firmware wifi chip driver
configurations now used to meet FCC's mandate).  I understand that this
is what you suggested.



Existing devices typically already have a non-replaced storage (but not
secured) area that holds the per-device MAC address.  FCC insistence on
locking down worldwide products to their own local rules is a pox on
the entire industry.  For instance a recent over-the-air update of my
non-US made non-US used non-US bought phone dropped access to WiFi
channels 12 and 

Re: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Kyle Hamilton]

On 9/12/2016 20:20, Jakob Bohm wrote:
> On 13/09/2016 03:03, Kyle Hamilton wrote:
>> I would prefer not to see a securelogin-.arubanetworks.com
>> name, because such makes it look like Aruba Networks is operating the
>> captive portal.  If (for whatever reason) the system is compromised, or
>> the login process is altered, or there's a need to enter credit card
>> information [I do not know if these devices can be configured to require
>> payment, but since this group typically discusses policy in general I
>> think it's appropriate to address during this discussion] but there are
>> then unauthorized charges caused by the device being compromised, then
>> Aruba Networks is going to be the one who's called to answer for it.
>> Because Aruba sells the devices and plays no part in their ongoing
>> operation, they'll quite rightly shut any claim down.  This leads the
>> user to have no recourse.  I think it would be better if there were a
>> mandate that all of these devices obtain ACME (i.e., Let's Encrypt)
>> certificates when they first start up.
>>
>> Provisioning a self-signed certificate for the administrator to
>> configure the device with prior to obtaining an ACME certificate would
>> in my mind be legitimate, as a warning that "hey, the device isn't
>> completely configured yet".  However, since I'm not a User Experience
>> guy, I may be incorrect here.
>>
>> I also suggest that the now-revoked certificate should be put in the
>> OneCRL, because of its widespread
>> captive-DNS/captive-network/no-CRL-or-OCSP-retrieval environment and
>> compromised private key.
>>
>> -Kyle H
>>
> Just to clarify, I never said that the use was for a "captive portal"
> or other such 3rd party hit address.  My presumption was that
> https://securelogin.arubanetworks.com would be a manually entered URL
> printed in the user manual or on the device itself.  However you may
> have other sources for it being a captive portal.

http://community.arubanetworks.com/t5/Wireless-Access/Certificate-securelogin-arubanetworks-com-and-trial-SSL-certs/td-p/28158
is an Aruba Networks customer request to alter the name that the users
are directed to with a "guest wifi pass".  This, and other things,
indicate that the name in the now-revoked certifcate is used for captive
portal authentication (to prevent users from having their credentials
sniffed over an unencrypted wifi connection).

> The securelogin-.arubanetworks.com domain name was my
> hypothetical/suggested name for a cert not associated with a
> shared/compromised key, but with a per-device certificate and key
> generated on a secure production line before the device was put in a
> cardboard box and shipped on a slow boat from China.

Understood.

> The point of having a real trusted cert rather than a self-signed cert
> for the first-time login would be to protect the user against a WiFi
> spoofed MiTM, a protection which is gone for the revoked cert due to
> the publicly compromised key.

I understand.  In this instance, I don't think it's quite as much a
problem as you're concerned about.  The configuration of such a
(managed, non-consumer-level) device would generally be performed over
the hardware network -- either in the configuration lab of the network
provider who purchased and is installing it, or on-site via the
hardwired network connection that it's bridging access to.  That
interface is guaranteed not to have guests connecting directly to it,
and so is really the only appropriate interface for secure things like
configuration to be done over.  (That said, there's a lot of
security-unconscious manufacturers out there -- but if they're
security-unconscious, they probably won't listen to this bit of security
advice, either.)

For actual instances of configuration interfaces exposed over WiFi, this
approach is probably infeasible without a reworking of the architecture
of such devices (perhaps akin to the changes required by FCC for
consumer wifi routers in US to prevent installers of DD-WRT from setting
their region to Japan and using unauthorized 2.4GHz spectrum above
802.11a/b/g channel 11), as updated device firmware would need to be
distributed without the keys and certificates (which would need to stay
in secure memory, approximately like the firmware wifi chip driver
configurations now used to meet FCC's mandate).  I understand that this
is what you suggested.

However, the firmware of those devices would need to prevent the
proposed key and certificate from being used for anything other than the
administration interface, in order to prevent a misattribution attack
against the user and hardware manufacturer.  It would be difficult to
achieve this with any platform that had an open platform for third-party
firmware.  (I'm not saying these devices of Aruba's have an open
platform, but many consumer-level devices do -- and
https://build.slashdot.org/story/16/08/01/1855206/fcc-requires-tp-link-to-support-open-source-router-firmware

Re: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Jakob Bohm]

On 13/09/2016 03:03, Kyle Hamilton wrote:

I would prefer not to see a securelogin-.arubanetworks.com
name, because such makes it look like Aruba Networks is operating the
captive portal.  If (for whatever reason) the system is compromised, or
the login process is altered, or there's a need to enter credit card
information [I do not know if these devices can be configured to require
payment, but since this group typically discusses policy in general I
think it's appropriate to address during this discussion] but there are
then unauthorized charges caused by the device being compromised, then
Aruba Networks is going to be the one who's called to answer for it.
Because Aruba sells the devices and plays no part in their ongoing
operation, they'll quite rightly shut any claim down.  This leads the
user to have no recourse.  I think it would be better if there were a
mandate that all of these devices obtain ACME (i.e., Let's Encrypt)
certificates when they first start up.

Provisioning a self-signed certificate for the administrator to
configure the device with prior to obtaining an ACME certificate would
in my mind be legitimate, as a warning that "hey, the device isn't
completely configured yet".  However, since I'm not a User Experience
guy, I may be incorrect here.

I also suggest that the now-revoked certificate should be put in the
OneCRL, because of its widespread
captive-DNS/captive-network/no-CRL-or-OCSP-retrieval environment and
compromised private key.

-Kyle H

On 9/7/2016 00:41, Jakob Bohm wrote:

Given the specific name in those certificates, and the place where the
private key was seen, I would guess the actual use case is this:
...


Just to clarify, I never said that the use was for a "captive portal"
or other such 3rd party hit address.  My presumption was that
https://securelogin.arubanetworks.com would be a manually entered URL
printed in the user manual or on the device itself.  However you may
have other sources for it being a captive portal.

The securelogin-.arubanetworks.com domain name was my
hypothetical/suggested name for a cert not associated with a
shared/compromised key, but with a per-device certificate and key
generated on a secure production line before the device was put in a
cardboard box and shipped on a slow boat from China.

The point of having a real trusted cert rather than a self-signed cert
for the first-time login would be to protect the user against a WiFi
spoofed MiTM, a protection which is gone for the revoked cert due to
the publicly compromised key.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Kyle Hamilton]

I would prefer not to see a securelogin-.arubanetworks.com
name, because such makes it look like Aruba Networks is operating the
captive portal.  If (for whatever reason) the system is compromised, or
the login process is altered, or there's a need to enter credit card
information [I do not know if these devices can be configured to require
payment, but since this group typically discusses policy in general I
think it's appropriate to address during this discussion] but there are
then unauthorized charges caused by the device being compromised, then
Aruba Networks is going to be the one who's called to answer for it. 
Because Aruba sells the devices and plays no part in their ongoing
operation, they'll quite rightly shut any claim down.  This leads the
user to have no recourse.  I think it would be better if there were a
mandate that all of these devices obtain ACME (i.e., Let's Encrypt)
certificates when they first start up.

Provisioning a self-signed certificate for the administrator to
configure the device with prior to obtaining an ACME certificate would
in my mind be legitimate, as a warning that "hey, the device isn't
completely configured yet".  However, since I'm not a User Experience
guy, I may be incorrect here.

I also suggest that the now-revoked certificate should be put in the
OneCRL, because of its widespread
captive-DNS/captive-network/no-CRL-or-OCSP-retrieval environment and
compromised private key.

-Kyle H

On 9/7/2016 00:41, Jakob Bohm wrote:
> Given the specific name in those certificates, and the place where the
> private key was seen, I would guess the actual use case is this:
>
> Each router (presumably a SOHO router) contains a DNS server that
> responds with its own internal RFC1918 IP address for the name
> securelogin.arubanetworks.com and then the routers internal user
> interface shows a https page with the router configuration user
> interface.  The printed 1 page manual that accompanies those routers
> probably says to plug in the router then open your browser and type in
> that name with https in front.  No actual legitimate public server
> would use that DNS name or certificate, and arubanetworks.com
> presumably ensures this (that is certainly the current status of the
> public DNS).
>
> If that is indeed the use case, users are not going to replace that
> certificate by any "real" certificate and will probably either generate
> a per device self-signed certificate and then add a browser exception
> OR they will just add a browser exception for the certificate that is
> now going to be revoked.  Depending on the actual router firmware
> available at github (and any older versions incorporating the same
> certificate), the user may not even have the ability to replace the
> certificate with a self-signed one.  Now sharing a single private key
> among thousands of router user interfaces is obviously bad security,
> but the common alternative (used by most other routers) is to use
> unencrypted http, perhaps over an (initially) unencrypted WiFi link.
>
> The correct, but more expensive, option would be for each router to get
> a unique certificate for securelogin-.arubanetworks.com
> (where  is the MAC address of the router) with an
> intercepting redirect from securelogin.arubanetworks.com or something
> similar.  However the process to securely generate and install a
> different private key and certificate for each router on the
> assembly line, and preserve those across routine firmware upgrades
> would probably be costly in a cost-competitive market, even if the
> router manufacturer ran a trusted sub-ca or could otherwise get the
> certificates for free.  I guess that is why this router manufacturer
> (presumably) chose to get a single low cost certificate and embed the
> private key in the firmware images.
>
> On 07/09/2016 01:26, Steve Medin wrote:
>> Agree, regardless of 4.9.5's investigation gap, in this case 4.9.1.1(3)
>> clearly applies as well as other clauses. At this point, revocation
>> is less
>> harm than the key compromise. It may be an effective way to get the
>> message
>> to the affected device operators who have not replaced the default
>> certificate with a purchased one.
>>
>> Kind regards,
>> Steven Medin
>> PKI Policy Manager, Symantec Corporation
>>
>> -Original Message-
>> From: Jeremy Rowley [mailto:jeremy.row...@digicert.com]
>> Sent: Tuesday, September 06, 2016 7:06 PM
>> To: Steve Medin 
>> Cc: Gervase Markham ; Kyle Hamilton
>> ;
>> mozilla-dev-security-pol...@lists.mozilla.org
>> Subject: Re: Compromised certificate that the owner didn't wish to
>> revoke
>> (signed by GeoTrust)
>>
>> BRs require revocation within 24 hours of notice. It's a terrible
>> timeline
>> but one the browsers have strictly enforced for even wide spread
>> deployments.
>>
>>> On Sep 6, 2016, at 4:30 PM, Steve Medin 
>>> wrote:
>>>

Re: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Jernej Simončič]

On Wed, 7 Sep 2016 03:55:02 -0700 (PDT), Nick Lamb wrote:

> If you DIY, the rate limits obviously aren't a problem, and lots of DIY 
> devices have Let's Encrypt issued certificates today. Home "routers" built 
> out of a Raspberry Pi or a Mini PC are fairly popular with hobbyists. So rate 
> limits (which exist for a perfectly sensible reason) are the only reason you 
> can't buy a device that does this off the shelf.

Wouldn't Let's Encrypt's 3-month certificate validity time also pose a
problem for such devices? I'm pretty sure I've bought routers that sat in
some warehouse far longer than 3 months in the past.

-- 
begin  .sig
< Jernej Simončič ><>◊<>< jernej|s-ng at eternallybored.org >
end
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Steve Medin]

This certificate was just revoked. Kyle, thanks for bringing this to our
attention - we were able to start work once you posted here at m.d.s.policy.

Kind regards,
Steven Medin
PKI Policy Manager, Symantec Corporation


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+steve_medin=symantec.com@lists.mozilla.o
rg] On Behalf Of Steve Medin
Sent: Tuesday, September 06, 2016 7:27 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Gervase Markham
; Kyle Hamilton 
Subject: RE: Compromised certificate that the owner didn't wish to revoke
(signed by GeoTrust)

Agree, regardless of 4.9.5's investigation gap, in this case 4.9.1.1(3)
clearly applies as well as other clauses. At this point, revocation is less
harm than the key compromise. It may be an effective way to get the message
to the affected device operators who have not replaced the default
certificate with a purchased one.

Kind regards,
Steven Medin
PKI Policy Manager, Symantec Corporation

-Original Message-
From: Jeremy Rowley [mailto:jeremy.row...@digicert.com]
Sent: Tuesday, September 06, 2016 7:06 PM
To: Steve Medin 
Cc: Gervase Markham ; Kyle Hamilton ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Compromised certificate that the owner didn't wish to revoke
(signed by GeoTrust)

BRs require revocation within 24 hours of notice. It's a terrible timeline
but one the browsers have strictly enforced for even wide spread
deployments.

> On Sep 6, 2016, at 4:30 PM, Steve Medin  wrote:
> 
> We have become aware of this certificate and its key compromise, thank 
> you for this information. We are contacting the owner to understand 
> impact to the deployed devices, but with clear intent to revoke. We 
> will provide updates while we make progress.
> 
> Kind regards,
> Steven Medin
> PKI Policy Manager, Symantec Corporation
> 
> 
> 
> 
> -Original Message-
> From: dev-security-policy
>
[mailto:dev-security-policy-bounces+steve_medin=symantec.com@lists.mozilla.o
> rg] On Behalf Of Gervase Markham
> Sent: Tuesday, September 06, 2016 2:02 PM
> To: Kyle Hamilton ; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Compromised certificate that the owner didn't wish to 
> revoke (signed by GeoTrust)
> 
>> On 06/09/16 18:25, Kyle Hamilton wrote:
>> Aruba chose not to notify GeoTrust that it needed to be revoked due 
>> to compromised private  key.  I am notifying because I believe it 
>> violates the Basic Requirements for someone other than the identified 
>> subject to possess the private key for a publicly-trusted certificate.
> 
> It does; have you notified GeoTrust using whatever mechanism they make 
> available for such notifications? They are supposed to have one, 
> according to the BRs. I'm not sure posting here would count.
> 
> Gerv
> 
> 
> ___
> 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


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: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Nick Lamb]

Responding to the scenario Jakob described which I agree is likely in outline

Let's Encrypt has seen a number of enquiries about relaxing their rate limits 
or granting some sort of exception so that firmware OEMs can use Let's Encrypt 
to have their devices self-issue using ACME from a name pool controlled by the 
OEM.

With ACME, out of the box a device can get itself unique, working Web PKI certs 
periodically so long as:

* It has some source of entropy
* It has an FQDN in the Internet's public DNS or can get one
* It can either make FQDN:80 or FQDN:443 reach it, or add DNS leaf records off 
the FQDN in the public DNS.

These are all eminently soluble problems and don't involve changes to the 
manufacturing process, unless entropy has to be somehow "baked in" to the 
devices to achieve that bullet point.

If you DIY, the rate limits obviously aren't a problem, and lots of DIY devices 
have Let's Encrypt issued certificates today. Home "routers" built out of a 
Raspberry Pi or a Mini PC are fairly popular with hobbyists. So rate limits 
(which exist for a perfectly sensible reason) are the only reason you can't buy 
a device that does this off the shelf.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Jakob Bohm]

Given the specific name in those certificates, and the place where the
private key was seen, I would guess the actual use case is this:

Each router (presumably a SOHO router) contains a DNS server that
responds with its own internal RFC1918 IP address for the name
securelogin.arubanetworks.com and then the routers internal user
interface shows a https page with the router configuration user
interface.  The printed 1 page manual that accompanies those routers
probably says to plug in the router then open your browser and type in
that name with https in front.  No actual legitimate public server
would use that DNS name or certificate, and arubanetworks.com
presumably ensures this (that is certainly the current status of the
public DNS).

If that is indeed the use case, users are not going to replace that
certificate by any "real" certificate and will probably either generate
a per device self-signed certificate and then add a browser exception
OR they will just add a browser exception for the certificate that is
now going to be revoked.  Depending on the actual router firmware
available at github (and any older versions incorporating the same
certificate), the user may not even have the ability to replace the
certificate with a self-signed one.  Now sharing a single private key
among thousands of router user interfaces is obviously bad security,
but the common alternative (used by most other routers) is to use
unencrypted http, perhaps over an (initially) unencrypted WiFi link.

The correct, but more expensive, option would be for each router to get
a unique certificate for securelogin-.arubanetworks.com
(where  is the MAC address of the router) with an
intercepting redirect from securelogin.arubanetworks.com or something
similar.  However the process to securely generate and install a
different private key and certificate for each router on the
assembly line, and preserve those across routine firmware upgrades
would probably be costly in a cost-competitive market, even if the
router manufacturer ran a trusted sub-ca or could otherwise get the
certificates for free.  I guess that is why this router manufacturer
(presumably) chose to get a single low cost certificate and embed the
private key in the firmware images.

On 07/09/2016 01:26, Steve Medin wrote:

Agree, regardless of 4.9.5's investigation gap, in this case 4.9.1.1(3)
clearly applies as well as other clauses. At this point, revocation is less
harm than the key compromise. It may be an effective way to get the message
to the affected device operators who have not replaced the default
certificate with a purchased one.

Kind regards,
Steven Medin
PKI Policy Manager, Symantec Corporation

-Original Message-
From: Jeremy Rowley [mailto:jeremy.row...@digicert.com]
Sent: Tuesday, September 06, 2016 7:06 PM
To: Steve Medin 
Cc: Gervase Markham ; Kyle Hamilton ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Compromised certificate that the owner didn't wish to revoke
(signed by GeoTrust)

BRs require revocation within 24 hours of notice. It's a terrible timeline
but one the browsers have strictly enforced for even wide spread
deployments.


On Sep 6, 2016, at 4:30 PM, Steve Medin  wrote:

We have become aware of this certificate and its key compromise, thank you
for this information. We are contacting the owner to understand impact to
the deployed devices, but with clear intent to revoke. We will provide
updates while we make progress.

Kind regards,
Steven Medin
PKI Policy Manager, Symantec Corporation




-Original Message-
From: dev-security-policy


[mailto:dev-security-policy-bounces+steve_medin=symantec.com@lists.mozilla.o

rg] On Behalf Of Gervase Markham
Sent: Tuesday, September 06, 2016 2:02 PM
To: Kyle Hamilton ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Compromised certificate that the owner didn't wish to revoke
(signed by GeoTrust)


On 06/09/16 18:25, Kyle Hamilton wrote:
Aruba chose not to notify GeoTrust that it needed to be revoked due to
compromised private  key.  I am notifying because I believe it
violates the Basic Requirements for someone other than the identified
subject to possess the private key for a publicly-trusted certificate.


It does; have you notified GeoTrust using whatever mechanism they make
available for such notifications? They are supposed to have one, according
to the BRs. I'm not sure posting here would count.




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

Re: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Jeremy Rowley]

BRs require revocation within 24 hours of notice. It's a terrible timeline but 
one the browsers have strictly enforced for even wide spread deployments.

> On Sep 6, 2016, at 4:30 PM, Steve Medin  wrote:
> 
> We have become aware of this certificate and its key compromise, thank you
> for this information. We are contacting the owner to understand impact to
> the deployed devices, but with clear intent to revoke. We will provide
> updates while we make progress.
> 
> Kind regards,
> Steven Medin
> PKI Policy Manager, Symantec Corporation
> 
> 
> 
> 
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+steve_medin=symantec.com@lists.mozilla.o
> rg] On Behalf Of Gervase Markham
> Sent: Tuesday, September 06, 2016 2:02 PM
> To: Kyle Hamilton ;
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Compromised certificate that the owner didn't wish to revoke
> (signed by GeoTrust)
> 
>> On 06/09/16 18:25, Kyle Hamilton wrote:
>> Aruba chose not to notify GeoTrust that it needed to be revoked due to 
>> compromised private  key.  I am notifying because I believe it 
>> violates the Basic Requirements for someone other than the identified 
>> subject to possess the private key for a publicly-trusted certificate.
> 
> It does; have you notified GeoTrust using whatever mechanism they make
> available for such notifications? They are supposed to have one, according
> to the BRs. I'm not sure posting here would count.
> 
> Gerv
> 
> 
> ___
> 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


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: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Steve Medin]

We have become aware of this certificate and its key compromise, thank you
for this information. We are contacting the owner to understand impact to
the deployed devices, but with clear intent to revoke. We will provide
updates while we make progress.

Kind regards,
Steven Medin
PKI Policy Manager, Symantec Corporation




-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+steve_medin=symantec.com@lists.mozilla.o
rg] On Behalf Of Gervase Markham
Sent: Tuesday, September 06, 2016 2:02 PM
To: Kyle Hamilton ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Compromised certificate that the owner didn't wish to revoke
(signed by GeoTrust)

On 06/09/16 18:25, Kyle Hamilton wrote:
> Aruba chose not to notify GeoTrust that it needed to be revoked due to 
> compromised private  key.  I am notifying because I believe it 
> violates the Basic Requirements for someone other than the identified 
> subject to possess the private key for a publicly-trusted certificate.

It does; have you notified GeoTrust using whatever mechanism they make
available for such notifications? They are supposed to have one, according
to the BRs. I'm not sure posting here would count.

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: Compromised certificate that the owner didn't wish to revoke (signed by GeoTrust)

[Gervase Markham]

On 06/09/16 18:25, Kyle Hamilton wrote:
> Aruba chose not to notify GeoTrust that it needed to be revoked due to
> compromised private  key.  I am notifying because I believe it violates
> the Basic Requirements for someone other than the identified subject to
> possess the private key for a publicly-trusted certificate.

It does; have you notified GeoTrust using whatever mechanism they make
available for such notifications? They are supposed to have one,
according to the BRs. I'm not sure posting here would count.

Gerv


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