Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

[Ángel via dev-security-policy]

On 2017-12-09 at 08:59 -0700, Wayne Thayer wrote:
> It can be confusing even for people following these things. That's where I
> think collecting problem reporting info from audited sub-CAs in CCADB would
> help.
> 
> For everyone else, finding the correct problem reporting information is
> mostly a matter of luck. Perhaps we should require an email address be
> included in the end-entity certificate? Unless that info was exposed in the
> browser, it would still be difficult to find, but at least it would then be
> in a consistent location.

Rather than an email, I think it should be a url. That could be an email
through the use of mailto:, but I suspect CAs will find preferable to
provide a web page where they explain what it is for, how to submit,
etc.

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

Re: Verisign signed speedport.ip ?

[Peter Bowen via dev-security-policy]

On Sat, Dec 9, 2017 at 11:42 AM, Lewis Resmond via dev-security-policy
 wrote:
> I was researching about some older routers by Telekom, and I found out that 
> some of them had SSL certificates for their (LAN) configuration interface, 
> issued by Verisign for the fake-domain "speedport.ip".
>
> They (all?) are logged here: https://crt.sh/?q=speedport.ip
>
> I wonder, since this domain and even the TLD is non-existing, how could 
> Verisign sign these? Isn't this violating the rules, if they sign anything 
> just because a router factory tells them to do so?
>
> Although they are all expired since several years, I am interested how this 
> could happen, and if such incidents of signing non-existing domains could 
> still happen today.

Before the CA/Browser Forum Baseline Requirements were created, this
was not explicitly forbidden.  Since approximately July 1, 2012 no new
certificates have been allowed for unqualified names or names for
which the TLD does not exist in the IANA root zone.

So, to answer your questions:

Q: How could Verisign sign these?
A: These were all issued prior to the Baseline Requirements coming into effect

Q: Could [...] such incidents of signing non-existing domains could
still happen today?
A: Not like this.  All Domain Names in certificates now must be Fully
Qualified Domains and the CA must validate that the FQDN falls in a
valid namespace.  It is allowable for me to get a certificate for
nonexistent.home.peterbowen.org, even though that FQDN does not exist,
as I am the registrant of peterbowen.org.

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

Re: Verisign signed speedport.ip ?

[Patrick Figel via dev-security-policy]

Until November 11, 2015, publicly-trusted CAs were allowed to issue
certificates for internal names and reserved IP addresses. All
certificates of this nature had to be revoked by October 1, 2016.

More details here: https://cabforum.org/internal-names/

Patrick

On 09.12.17 20:42, Lewis Resmond via dev-security-policy wrote:
> Hello,
> 
> I was researching about some older routers by Telekom, and I found out that 
> some of them had SSL certificates for their (LAN) configuration interface, 
> issued by Verisign for the fake-domain "speedport.ip".
> 
> They (all?) are logged here: https://crt.sh/?q=speedport.ip
> 
> I wonder, since this domain and even the TLD is non-existing, how could 
> Verisign sign these? Isn't this violating the rules, if they sign anything 
> just because a router factory tells them to do so?
> 
> Although they are all expired since several years, I am interested how this 
> could happen, and if such incidents of signing non-existing domains could 
> still happen today.
> ___
> 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

Verisign signed speedport.ip ?

[Lewis Resmond via dev-security-policy]

Hello,

I was researching about some older routers by Telekom, and I found out that 
some of them had SSL certificates for their (LAN) configuration interface, 
issued by Verisign for the fake-domain "speedport.ip".

They (all?) are logged here: https://crt.sh/?q=speedport.ip

I wonder, since this domain and even the TLD is non-existing, how could 
Verisign sign these? Isn't this violating the rules, if they sign anything just 
because a router factory tells them to do so?

Although they are all expired since several years, I am interested how this 
could happen, and if such incidents of signing non-existing domains could still 
happen today.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CA generated keys

[Tim Hollebeek via dev-security-policy]

 

Apologies for the new thread.  It's difficult for me to reply to messages
that were sent before I joined Digicert.

 

With respect to CA generated SSL keys, there are a few points that I feel
should be considered.

 

First, third parties who are *not* CAs can run key generation and escrow
services, and then the third party service can apply for a  certificate for
the key, and deliver the certificate and the key to a customer.  I'm not
sure how this could be prevented.  So if this actually did end up being a
Mozilla policy, the practical effect would be that SSL keys can be generated
by third parties and escrowed, *UNLESS* that party is trusted by Mozilla.
This seems . backwards, at best.

 

Second, although I strongly believe that in general, as a best practice,
keys should be generated by the device/entity it belongs to whenever
possible, we've seen increasing evidence that key generation is difficult
and many devices cannot do it securely.  I doubt that forcing the owner of
the device to generate a key on a commodity PC is any better (it's probably
worse).  With an increasing number of small devices running web servers,
keys generated by audited, trusted third parties under whatever rules
Mozilla chooses to enforce about secure key delivery may actually in many
circumstances be superior than what would happen if the practice is banned.

 

-Tim

 



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 incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

[Kristian Fiskerstrand via dev-security-policy]

On 12/09/2017 01:50 AM, Kurt Roeckx via dev-security-policy wrote:
> But it's not obvious to me who to contact to revoke a given
> certifiate, and it would be really useful that given a certificate
> it would be obvious what to do, who to contact, to get it revoked.

Could it be useful to establish a practice of including such contact
information in the certificate itself, e.g. requiring a URI in some
standardized key containing the contact point?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

[Tom via dev-security-policy]

It can be confusing even for people following these things. That's where I
think collecting problem reporting info from audited sub-CAs in CCADB would
help.

For everyone else, finding the correct problem reporting information is
mostly a matter of luck. Perhaps we should require an email address be
included in the end-entity certificate? Unless that info was exposed in the
browser, it would still be difficult to find, but at least it would then be
in a consistent location.



It may be related to that bug: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1418451


The certificate or a easily accessible public database should contains 
the information of who really is responsible for the issuance and 
revocation of the certificate.

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

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

[Wayne Thayer via dev-security-policy]

On Sat, Dec 9, 2017 at 7:50 AM, Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Sat, 9 Dec 2017 09:51:59 +0100
> Hanno Böck via dev-security-policy
>  wrote:
>
> > On Fri, 8 Dec 2017 16:43:48 -0700
> > Wayne Thayer via dev-security-policy
> >  wrote:
> >
> > > The root CA is ultimately responsible for subordinate CAs it has
> > > signed.
> >
> > I see a problem with that, as this is far from obvious.
>
> I saw "responsibility" here as meaning responsibility to the Trust
> Stores on behalf of the Relying Parties. For the Relying Parties
> themselves I think the right pattern is: Try filing a Problem Report
> with the Issuer, if the result isn't satisfactory, complain to your
> Trust Store(s). We can do the rest, can we not?
>
> Yes, I think we're talking about two separate problems. I was looking at
this from Mozilla's perspective.

>
> > I'm mostly not concerned about the people following these things
> > closely and are members of this list, but about random other people who
> > happen to find problems. It surely seems beneficial for the certificate
> > ecosystem to make sure that they can easily find the right place to
> > report problems.


It can be confusing even for people following these things. That's where I
think collecting problem reporting info from audited sub-CAs in CCADB would
help.

For everyone else, finding the correct problem reporting information is
mostly a matter of luck. Perhaps we should require an email address be
included in the end-entity certificate? Unless that info was exposed in the
browser, it would still be difficult to find, but at least it would then be
in a consistent location.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

[Nick Lamb via dev-security-policy]

On Sat, 9 Dec 2017 09:51:59 +0100
Hanno Böck via dev-security-policy
 wrote:

> On Fri, 8 Dec 2017 16:43:48 -0700
> Wayne Thayer via dev-security-policy
>  wrote:
> 
> > The root CA is ultimately responsible for subordinate CAs it has
> > signed.
> 
> I see a problem with that, as this is far from obvious.


I saw "responsibility" here as meaning responsibility to the Trust
Stores on behalf of the Relying Parties. For the Relying Parties
themselves I think the right pattern is: Try filing a Problem Report
with the Issuer, if the result isn't satisfactory, complain to your
Trust Store(s). We can do the rest, can we not?


The Trust Stores have just as much reason to distrust a root CA which
can't keep its subCAs from breaking the rules as they do if this root CA
were to break the rules directly themselves. That's sort-of the lesson
from Symantec too, right albeit in their case the problem was RAs?

It should be in the Root CA's interest to make sure that every
sub-ordinate CA, whether physically under its control or not, is
properly operated, and if there's a suspicion that it's not being
properly operated, to get that sorted out. Handling problem reports is
part of the proper operation of the CA.


It may be that root CAs decide the best way to _achieve_ this objective
[for a subCA they don't actually intend as simply a cross-signature to
bootstrap another root] is to insist upon being the point of contact
for Problem Reports, and they'll pass them on, so this way they have
oversight. Or that they insist on the Problem Reports going to an
alias, Exchange DL or similar that sends a copy to the root CA, I don't
think we need to dictate how this is done, only to re-emphasise that as
the root CA making sure the Problem Reports are handled properly is
ultimately your responsibility, however you discharge it, not a
situation for buck passing.


We definitely mustn't be shy about problems affecting another business
with a Trust Store. If Microsoft's executive management has any sense
there is an institutional firewall between their Trust Store and their
Certificate Authority functions, and the former is able to make
decisions independent of their potential impact on the latter. If a
root CA finds that it is politically uncomfortable to have two very
different relationships (Programme Member: Trust Programme / CA: subCA)
to the same public company, well, that's unfortunate, and I would
suggest the less awkward way forward is to bring the subCA relationship
to an ordered close. Perhaps Microsoft shouldn't be in both games (and
if so, the same for Google), but that again is not a problem for
Mozilla.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

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

On Fri, 8 Dec 2017 16:43:48 -0700
Wayne Thayer via dev-security-policy
 wrote:

> The root CA is ultimately responsible for subordinate CAs it has
> signed.  

I see a problem with that, as this is far from obvious.

If a random person discovers a problem with a certificate it seems
quite natural to go to the place that issued it. If you see a
certificate issued by Microsoft then why would you believe that anyone
other than Microsoft is responsible for that?

(Add to that that in order to find out that it's ultimately Digicert
that is responsible you'd have to first figure out that the root is
"Baltimore Cybertrust", then figure out that this is a company that no
longer exists and that the root has been bought by Digicert at some
point.)

IMHO we're seeing a very problematic practice here. On the one Hand CAs
offer that companies can get their own "branded" certificates that are
"issued" by them, on the other hand that's not really the case and all
the responsibility is still with the CA. For the user - and also for
potential reporters of security problems - this is obfuscating things.

I'm mostly not concerned about the people following these things
closely and are members of this list, but about random other people who
happen to find problems. It surely seems beneficial for the certificate
ecosystem to make sure that they can easily find the right place to
report problems.

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