RE: Namecheap refused to revoke certificate despite domain owner changed

[Jeremy Rowley via dev-security-policy]

RFC 6844: "The Certification Authority Authorization (CAA) DNS Resource
Record
   allows a DNS domain name holder to specify the Certification
   Authorities (CAs) authorized to issue certificates for that domain. "

CAA record checks would be outside the scope of revocation requests. 

I'm not sure I agree with " In any event, proof of ability to modify the
authoritative DNS over each label in the certificate should almost certainly
suffice to revoke a previously issued certificate that relied exclusively
upon just about any other sort of domain validation."

But only because I doubt every CA supports DNS checking, and I know several
companies where the people operating the DNS are not the same  entities
authorized to manage certificates. 


-Original Message-
From: dev-security-policy

On Behalf Of Matthew Hardeman via dev-security-policy
Sent: Friday, June 1, 2018 5:17 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-policy
; Jakob Bohm
; Wayne Thayer 
Subject: Re: Namecheap refused to revoke certificate despite domain owner
changed

On Fri, Jun 1, 2018 at 2:38 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This is one of the reasons I think we should require an OID specifying 
> the validation method be included in the cert. Then you can require 
> the CA support revocation using the same validation process as was 
> used to confirm certificate authorization. With each cert logged in 
> CT, everyone in the world will know exactly how to revoke an 
> unauthorized or no-longer-wanted cert.
>
>
I agree that it would be forensically interesting to have that data
available in the certificate.  I question whether a policy of using only the
same method of demonstrating control anew is appropriate as a policy for
granting revocation.

There is a hierarchy of supremacy in domain validation.  The party
controlling the NS delegations from the registry has absolute precedence
over the present effective DNS server administrator, should they choose to
flex it.  The party immediately in effective control of the authoritative
DNS takes precedence over a website admin within the domain.

Consider that now current CAA records and policy (for good cause, even)
might presently prohibit successful validation via the method previously
utilized to acquire the certificate that the current domain holder wishes to
have revoked.  (Even if only by specifying a new CA, rather than the CA that
previously issued the certificate for which revocation is being
sought.)  Would you then advocate that if the validation can succeed -- save
for the CAA mismatch -- that this be regarded as sufficient evidence to
revoke?  That probably deserves some careful thought.

In any event, proof of ability to modify the authoritative DNS over each
label in the certificate should almost certainly suffice to revoke a
previously issued certificate that relied exclusively upon just about any
other sort of domain validation.
___
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: Namecheap refused to revoke certificate despite domain owner changed

[Jeremy Rowley via dev-security-policy]

I was thinking more that this would be the minimum where a CA is required to 
revoke. For example, if the revocation requester can demonstrate control in the 
same fashion as the certificate issued, then the CA MUST revoke. This likely 
wouldn’t be the only way a CA would be required to revoke. And I do agree it 
won’t solve all cases. However, if the CA was able to issue a certificate using 
a particular domain control mechanism, shouldn’t they also be able to complete 
the domain control mechanism for revocation? Perhaps the domain holder cannot 
but that shouldn’t necessarily prevent the CA from supporting it. 

 

 

From: Ryan Sleevi  
Sent: Friday, June 1, 2018 4:08 PM
To: Jeremy Rowley 
Cc: r...@sleevi.com; Wayne Thayer ; Jakob Bohm 
; mozilla-dev-security-policy 

Subject: Re: Namecheap refused to revoke certificate despite domain owner 
changed

 

Yes, as mentioned in the CABF in the first link Wayne provided, even for our 
other methods, it can be problematic for domain holders to demonstrate control 
using particular methods. As Joanna mentioned, .2 can be problematic in a 
post-WHOIS world.

 

I realize that shooting down suggestions doesn't help us build sustainable 
solutions, but this was a problem we thought about a lot in the context of the 
CT redaction discussions, because the only 'effective' mitigation to 
inappropriate redaction was reveal-(and-revoke) - that is, reveal the redacted 
name, and possibly revoke the cert if you don't like what was revealed. Trying 
to decide how to authorize that request and what the consequences of that would 
be occupied a substantial part of our time (... I promise I didn't hate 
redaction "just because").

 

As an example scenario beyond what Wayne pointed out in the 
https://cabforum.org/pipermail/public/2018-January/012824.html link, consider 
such situations such as All CAs being required to support all validation 
methods for revocation. One possible scenario is a lack of interoperable 
interpretations of some methods (yet compliant with the letter) - for example, 
GlobalSign's validation methods compared to Let's Encrypt's use of the (draft) 
ACME validation methods, which comply with the letter but are different 
protocols. Another possible scenario is that a CA only supports a given method 
for revocation, not issuance, and thus the robustness of it and the testing of 
it is far weaker than might be expected (and detected) for domain validation. 

 

Understandably, we can try to patch those two examples I gave (and there is 
useful result in doing so), such as trying to further specify exactly how 
domains are validated, or potentially requiring CAs to also support all such 
methods for domain validation as well (although determining whether that means 
CAs MUST also support DV is a related and natural implication that follows that 
sort of policy). However, I was trying to present them to indicate the sort of 
holistic challenges we should think about, and why it's not quite as easy as 
'revoke the same way you validated' or 'validate using any/every possible 
method'.

 

So what does that mean for Richard? Well, I agree with Jakob in that he quoted 
the appropriate section, and there is a reasonable expectation in principle for 
the CA to do due diligence to investigate for possible revocation. And I think 
Wayne's directions on revocation do offer a number of important contributions 
to that, by providing some degree of flexibility for CAs to do meaningful 
investigations (although with some degree of transparency inevitably being 
needed when offering CA discretion). And I think the Root Stores have a role to 
play in how they communicate that expectation to CAs, such that domain holders 
have recourse if the CA is not taking meaningful steps.

 

On Fri, Jun 1, 2018 at 5:42 PM, Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote:

Which is yet another reason why removing method 1 and method 5 was a good idea. 
 Do any of the other methods share the same problem? Maybe IP address 
verification right now.

 

From: Ryan Sleevi mailto:r...@sleevi.com> > 
Sent: Friday, June 1, 2018 2:51 PM
To: Jeremy Rowley mailto:jeremy.row...@digicert.com> >
Cc: Wayne Thayer mailto:wtha...@mozilla.com> >; Jakob 
Bohm mailto:jb-mozi...@wisemo.com> >; 
mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >


Subject: Re: Namecheap refused to revoke certificate despite domain owner 
changed

 

You know I'm strongly supportive of requiring disclosure of validation methods, 
for the many benefits it brings, I'm not sure how that would address the 
concern.

 

Consider a certificate validated under .5. Would Richard now need to hire a 
lawyer to say they own their domain name now?

 

On Fri, Jun 1, 2018 at 3:38 PM, Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

This is one of the reasons I think we should require an OID specifying the 
validation method be included in the 

Re: Namecheap refused to revoke certificate despite domain owner changed

[Matthew Hardeman via dev-security-policy]

On Fri, Jun 1, 2018 at 2:38 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This is one of the reasons I think we should require an OID specifying the
> validation method be included in the cert. Then you can require the CA
> support revocation using the same validation process as was used to confirm
> certificate authorization. With each cert logged in CT, everyone in the
> world will know exactly how to revoke an unauthorized or no-longer-wanted
> cert.
>
>
I agree that it would be forensically interesting to have that data
available in the certificate.  I question whether a policy of using only
the same method of demonstrating control anew is appropriate as a policy
for granting revocation.

There is a hierarchy of supremacy in domain validation.  The party
controlling the NS delegations from the registry has absolute precedence
over the present effective DNS server administrator, should they choose to
flex it.  The party immediately in effective control of the authoritative
DNS takes precedence over a website admin within the domain.

Consider that now current CAA records and policy (for good cause, even)
might presently prohibit successful validation via the method previously
utilized to acquire the certificate that the current domain holder wishes
to have revoked.  (Even if only by specifying a new CA, rather than the CA
that previously issued the certificate for which revocation is being
sought.)  Would you then advocate that if the validation can succeed --
save for the CAA mismatch -- that this be regarded as sufficient evidence
to revoke?  That probably deserves some careful thought.

In any event, proof of ability to modify the authoritative DNS over each
label in the certificate should almost certainly suffice to revoke a
previously issued certificate that relied exclusively upon just about any
other sort of domain validation.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Disallowed company name

[Matthew Hardeman via dev-security-policy]

On Thu, May 31, 2018 at 8:38 PM, Peter Gutmann 
wrote:

>
> >Banks, trade vendors, etc, tend to reject accounts with names like this.
>
> Do they?
>
> https://www.flickr.com/photos/nzphoto/6038112443/


I would hope that we could agree that there is generally a different risk
management burden in getting a store loyalty tracking card versus getting a
loan or even opening a business demand deposit account.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Disallowed company name

[Matthew Hardeman via dev-security-policy]

On Fri, Jun 1, 2018 at 10:28 AM, Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> re: Most of the government offices responsible for approving entity
> creation are concerned first and foremost with ensuring that a unique name
> within their jurisdiction is chosen
>
> What makes you say that, most jurisdictions have no such requirement.
>
>
This was anecdotal, based on my own experience with formation of various
limited liability entities in several US states.

Even my own state of Alabama, for example, (typically regarded as pretty
backwards) has strong policies and procedures in place for this.

In Alabama, formation of a limited liability entity whether a Corporation
or LLC, etc, begins with a filing in the relevant county probate court of
an Articles of Incorporation, Articles or Organization, trust formation
documents, or similar.  As part of the mandatory filing package for those
document types, a name reservation certificate (which will be validated by
the probate court) from the Alabama Secretary of State will be required.
The filer must obtain those directly from the appropriate office of the
Alabama Secretary of State.  (It can be done online, with a credit card.
The system enforces entity name uniqueness.)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Fwd: Invalid Country Code Issuance

[Wayne Thayer via dev-security-policy]

Forwarding this for Brenda because the list's SPAM filter is preventing her
from posting it:

*From:* Brenda Bernal 
*Date:* June 1, 2018 at 1:33:46 PM PDT
*To:* 
*Subject:* *Invalid Country Code Issuance*

Digicert has posted a bug (below) on our invalid country code issuance.
Wayne requested us to post for forum visibility.



1. How your CA first became aware of the problem (e.g. via a
problem report submitted to your Problem Reporting Mechanism, a
discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal
self-audit), and the time and date.



The Product team discovered on 2018-05-17 that we had certificates in
our system that were issued from two incorrect Country codes, AN and
XK, as they were addressing a revalidation question.



2. A timeline of the actions your CA took in response. A timeline
is a date-and-time-stamped sequence of all relevant events. This may
include events before the incident was reported, such as when a
particular requirement became applicable, or a document changed, or a
bug was introduced, or an audit was done.

2018/05/17  7:30 AM MT - Certificates were discovered via
internal forum discussion

   2018/05/17 4:16 PM MT - Certificates were confirmed by
Engineering Manager with AN and XK country codes

   2018/5/18 5:01 PM MT - 'AN' ISO country code removed from CA

   2018/05/25 1:09 PM MT -'XK' ISO country code removed from CA



3. Whether your CA has stopped, or has not yet stopped, issuing
certificates with the problem. A statement that you have will be
considered a pledge to the community; a statement that you have not
requires an explanation.



We have stopped issuing certificates using these country codes at the
CA level through code changes as indicated in 2) above.



4. A summary of the problematic certificates. For each problem:
number of certs, and the date the first and last certs with that
problem were issued.

7 certs associated with AN country code and 10 certs associated with
XK country code

"XK" country code first issued was 2016/12/06 AND last issued was 2018/5/15

"AN" country code first issued was 2015/08/25 AND last issued was 2018/3/13



Here’s the link to the
bug:https://bugzilla.mozilla.org/show_bug.cgi?id=1465600 for the
crt.sh links to the certificates.



5. The complete certificate data for the problematic certificates.
The recommended way to provide this is to ensure each certificate is
logged to CT and then list the fingerprints or crt.sh IDs, either in
the report or as an attached spreadsheet, with one list per distinct
problem.



We will provide when CT logs are updated.



6. Explanation about how and why the mistakes were made or bugs
introduced, and how they avoided detection until now.



a. There was no product team in 2012 when the Baseline Requirement
requiring the use of ISO country codes was passed. At the time, an
engineer checked the ISO codes, and "AN" was still in transitionary
state, while "XK" was included as a user-assigned value. It wasn't
clear to that engineer, at that time, that it wasn't officially
accepted by the ISO standards, and was allowed in error.  We have
updated our list to exclude user codes.



b. The "AN" country code was a previously admissible country code
by ISO standards. It was removed transitionally on 2011/12/15, which
meant it could be used for 5 years while the new codes were adopted.
However, it wasn't removed from our database as an allowed value in
2016, due to the lack of a product group and oversight. Product
oversight has been established.  We have an amended process in place
to thoroughly review all ballot impact with subsequent baseline
requirement changes that will need to be reflected in software and
operational procedures.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Namecheap refused to revoke certificate despite domain owner changed

[Ryan Sleevi via dev-security-policy]

Yes, as mentioned in the CABF in the first link Wayne provided, even for
our other methods, it can be problematic for domain holders to demonstrate
control using particular methods. As Joanna mentioned, .2 can be
problematic in a post-WHOIS world.

I realize that shooting down suggestions doesn't help us build sustainable
solutions, but this was a problem we thought about a lot in the context of
the CT redaction discussions, because the only 'effective' mitigation to
inappropriate redaction was reveal-(and-revoke) - that is, reveal the
redacted name, and possibly revoke the cert if you don't like what was
revealed. Trying to decide how to authorize that request and what the
consequences of that would be occupied a substantial part of our time (...
I promise I didn't hate redaction "just because").

As an example scenario beyond what Wayne pointed out in the
https://cabforum.org/pipermail/public/2018-January/012824.html link,
consider such situations such as All CAs being required to support all
validation methods for revocation. One possible scenario is a lack of
interoperable interpretations of some methods (yet compliant with the
letter) - for example, GlobalSign's validation methods compared to Let's
Encrypt's use of the (draft) ACME validation methods, which comply with the
letter but are different protocols. Another possible scenario is that a CA
only supports a given method for revocation, not issuance, and thus the
robustness of it and the testing of it is far weaker than might be expected
(and detected) for domain validation.

Understandably, we can try to patch those two examples I gave (and there is
useful result in doing so), such as trying to further specify exactly how
domains are validated, or potentially requiring CAs to also support all
such methods for domain validation as well (although determining whether
that means CAs MUST also support DV is a related and natural implication
that follows that sort of policy). However, I was trying to present them to
indicate the sort of holistic challenges we should think about, and why
it's not quite as easy as 'revoke the same way you validated' or 'validate
using any/every possible method'.

So what does that mean for Richard? Well, I agree with Jakob in that he
quoted the appropriate section, and there is a reasonable expectation in
principle for the CA to do due diligence to investigate for possible
revocation. And I think Wayne's directions on revocation do offer a number
of important contributions to that, by providing some degree of flexibility
for CAs to do meaningful investigations (although with some degree of
transparency inevitably being needed when offering CA discretion). And I
think the Root Stores have a role to play in how they communicate that
expectation to CAs, such that domain holders have recourse if the CA is not
taking meaningful steps.

On Fri, Jun 1, 2018 at 5:42 PM, Jeremy Rowley 
wrote:

> Which is yet another reason why removing method 1 and method 5 was a good
> idea.  Do any of the other methods share the same problem? Maybe IP address
> verification right now.
>
>
>
> *From:* Ryan Sleevi 
> *Sent:* Friday, June 1, 2018 2:51 PM
> *To:* Jeremy Rowley 
> *Cc:* Wayne Thayer ; Jakob Bohm <
> jb-mozi...@wisemo.com>; mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
>
> *Subject:* Re: Namecheap refused to revoke certificate despite domain
> owner changed
>
>
>
> You know I'm strongly supportive of requiring disclosure of validation
> methods, for the many benefits it brings, I'm not sure how that would
> address the concern.
>
>
>
> Consider a certificate validated under .5. Would Richard now need to hire
> a lawyer to say they own their domain name now?
>
>
>
> On Fri, Jun 1, 2018 at 3:38 PM, Jeremy Rowley via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> This is one of the reasons I think we should require an OID specifying the
> validation method be included in the cert. Then you can require the CA
> support revocation using the same validation process as was used to confirm
> certificate authorization. With each cert logged in CT, everyone in the
> world will know exactly how to revoke an unauthorized or no-longer-wanted
> cert.
>
>
> -Original Message-
> From: dev-security-policy  digicert@lists.mozilla.org> On Behalf Of Wayne Thayer via
> dev-security-policy
> Sent: Friday, June 1, 2018 1:02 PM
> To: Jakob Bohm 
> Cc: mozilla-dev-security-policy  lists.mozilla.org>
> Subject: Re: Namecheap refused to revoke certificate despite domain owner
> changed
>
> On Fri, Jun 1, 2018 at 5:06 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> >
> > Please contact the CA again, and inform them that BR 4.9.1.1 #6
> > requires the CA (not some reseller) to revoke the certificate within 24
> hours if:
> >
> > The CA is made aware of any circumstance indicating that use of a
> > Fully-Qualified Domain Name or IP address 

RE: Namecheap refused to revoke certificate despite domain owner changed

[Jeremy Rowley via dev-security-policy]

Which is yet another reason why removing method 1 and method 5 was a good idea. 
 Do any of the other methods share the same problem? Maybe IP address 
verification right now.

 

From: Ryan Sleevi  
Sent: Friday, June 1, 2018 2:51 PM
To: Jeremy Rowley 
Cc: Wayne Thayer ; Jakob Bohm ; 
mozilla-dev-security-policy 
Subject: Re: Namecheap refused to revoke certificate despite domain owner 
changed

 

You know I'm strongly supportive of requiring disclosure of validation methods, 
for the many benefits it brings, I'm not sure how that would address the 
concern.

 

Consider a certificate validated under .5. Would Richard now need to hire a 
lawyer to say they own their domain name now?

 

On Fri, Jun 1, 2018 at 3:38 PM, Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

This is one of the reasons I think we should require an OID specifying the 
validation method be included in the cert. Then you can require the CA support 
revocation using the same validation process as was used to confirm certificate 
authorization. With each cert logged in CT, everyone in the world will know 
exactly how to revoke an unauthorized or no-longer-wanted cert.


-Original Message-
From: dev-security-policy 
mailto:digicert@lists.mozilla.org> > On Behalf Of Wayne Thayer via 
dev-security-policy
Sent: Friday, June 1, 2018 1:02 PM
To: Jakob Bohm mailto:jb-mozi...@wisemo.com> >
Cc: mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: Re: Namecheap refused to revoke certificate despite domain owner 
changed

On Fri, Jun 1, 2018 at 5:06 PM Jakob Bohm via dev-security-policy < 
dev-security-policy@lists.mozilla.org 
 > wrote:

>
> Please contact the CA again, and inform them that BR 4.9.1.1 #6 
> requires the CA (not some reseller) to revoke the certificate within 24 hours 
> if:
>
> The CA is made aware of any circumstance indicating that use of a
> Fully-Qualified Domain Name or IP address in the Certificate is no
> longer legally permitted (e.g. a court or arbitrator has revoked a
> Domain Name Registrant’s right to use the Domain Name, a relevant
> licensing or services agreement between the Domain Name Registrant
> and the Applicant has terminated, or the Domain Name Registrant has
> failed to renew the Domain Name);
>
> While CAs are not required to discover such situations themselves, 
> they must revoke once made aware of the situation (in this case by you 
> telling them).
>
> At least, this is how I read the rules.
>
> This issue has come up in several CAB Forum discussions such as [1]. 
> In
practice, I believe that the requirement Jakob quoted is rarely invoked because 
(despite the examples), the language is too vague and narrow. It can also be 
quite difficult for a CA to verify that the revocation request is coming from 
the legitimate domain name registrant [1], making it less likely the CA will 
take action.

I've made a couple of attempts to fix this, resulting in the current language 
proposed for ballot 213 [2]:

The CA obtains evidence that the validation of domain authorization or control 
for any Fully-Qualified Domain Name or IP address in the Certificate should not 
be relied upon.

I'd prefer a more prescriptive requirement that CAs allow anyone to revoke by 
proving that they control the domain name using one of the BR 3.2.2.4 methods, 
but this is a problem because most CAs don't support every domain validation 
method and many domains are configured such that some validation methods can't 
be used.

- Wayne

[1] https://cabforum.org/pipermail/public/2018-January/012824.html
[2] https://cabforum.org/pipermail/public/2018-May/013380.html
___
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: Disallowed company name

[James Burton via dev-security-policy]

Hi Jeremy,

In the UK it would be class as “same as” and therefore wouldn’t be allowed
to be incorporated. You can see this in the links:

Companies Act 2006:
https://www.legislation.gov.uk/ukpga/2006/46/part/5/chapter/3

The Company, Limited Liability Partnership and Business (Names and Trading
Disclosures) Regulations 2015:
http://www.legislation.gov.uk/uksi/2015/17/regulation/7/made


James Burton

On Fri, 1 Jun 2018 at 20:32, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Can you point to a jurisdiction that allows you to register the same name?
> I've never seen an example where it's permitted. Maybe the UK?
>
> -Original Message-
> From: dev-security-policy  digicert@lists.mozilla.org> On Behalf Of Ryan Hurst via
> dev-security-policy
> Sent: Friday, June 1, 2018 9:28 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Disallowed company name
>
> On Thursday, May 31, 2018 at 3:07:36 PM UTC-7, Matthew Hardeman wrote:
> > On Thu, May 31, 2018 at 4:18 PM, Peter Saint-Andre via
> > dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > >
> > >
> > > We can also think of many business types (e.g., scammers) that would
> > > love to have names like ⒶⓅⓅⓁⒺ but that doesn't mean it's smart to
> > > issue certificates with such names. The authorities who approve of
> > > company names don't necessarily have certificate handling in mind...
> > >
> >
> > Indeed.  Most of the government offices responsible for approving
> > entity creation are concerned first and foremost with ensuring that a
> > unique name within their jurisdiction is chosen and that a public
> > record of the entity creation exists.  They are not concerned with
> > risk management or legitimacy, broadly speaking.
> >
> > Anyone at any level of risk management in the rest of the ecosystem
> > around a business will be concerned with such matters.  Banks, trade
> > vendors, etc, tend to reject accounts with names like this.  Perhaps
> > CAs should look upon this similarly.
>
> re: Most of the government offices responsible for approving entity
> creation are concerned first and foremost with ensuring that a unique name
> within their jurisdiction is chosen
>
> What makes you say that, most jurisdictions have no such requirement.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
>
> https://clicktime.symantec.com/a/1/H8qZVRE5_iLNO8giNWdHECRPUnhWmem4t7fNC9FYfaI=?d=3yPd_yGx1m4dQz3H1uWi0wkNACGDGvIL4Z--LNoP9eDPIWeD0dhf9Ol_tFkJGBJFFgtnLt2HO_UCbFnaqQu3zUWQTHxGduRJO0a_H4yYE3qhYRX3wzvleMJ_cCcflYSP6doSbnmNReFJlR_Gjut8oNV6EnnecC1kzxXkdJG19OPUi3qjxKSp_r4Tlk3ExNNIwR3DF26nn1z6wKDyzP1siUdOGQT4oa70wTAPNZrK417n5z35ynmL65-hmQXBJkPLvbJL_UkzAgimEa4Sjh8YgHtKR2tCSas65vpsh0YyIXTny7Puzb8Hvs9uNxGPMfSyStkq2pMn3jZpzjfKsgYMMKDzdouOUktqhPACnhr6Qsx3ZdCTubWI8EkLpQsj4nYxjihAKD9mM-9LyUQGRh4mQOOQ0U4zY3qAE6fPOz-Upa5efnAlQhO0GtTkcOHiosY%3D=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-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: Namecheap refused to revoke certificate despite domain owner changed

[Joanna Fox via dev-security-policy]

In light of the limited visibility of WHOIS, Wayne's suggestion of "... allow 
anyone to revoke by proving that they control the domain name using one of the 
BR 3.2.2.4 methods" is preferable as it is a bit more encompassing rather than 
restricting to to same validation process.  This also supports the idea of 
transparency around revocation processes.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Plan to update CCADB PEM extraction tool

[Ryan Sleevi via dev-security-policy]

Ah, thanks! I was trying to figure out the context if it was a bug or
intentional - sounds like the former, in which case, all is well :)

On Fri, Jun 1, 2018 at 3:17 PM, J.C. Jones via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Ryan -
>
> Originally the Observatory had "Subject+SPKI" hash field. Someone filed a
> bug that Subject+SPKI field wasn't as useful for external comparisons as
> the SPKI, and the Observatory changed over, replacing the old Subject+SPKI
> hash with a pure SPKI hash.
>
> We were proposing to switch to just the SPKI, simply because that is what
> the Observatory is using today. However, there's no reason not to have the
> Observatory provide the Subject+SPKI hash alongside the SPKI, and then we
> can keep that field and effectively add the SPKI hash. That seems like a
> good idea, for all the reasons David pointed out in 2016
> .
>
> Thanks for catching this!
>
> Cheers,
> J.C.
>
> On Fri, Jun 1, 2018 at 11:57 AM, Julien Vehent via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > I think the revert was a mistake. I should have added the SPKI instead of
> > replacing the Subject+SPKI with SPKI. (I don't recall the discussion at
> the
> > time, but I think someone confused Subject+SPKI for SPKI and I meant to
> > address the confusion).
> >
> > I'll re-add the subject+spki field, this time in addition to SPKI, and
> > re-populate the DB.
> >
> > - Julien
> > ___
> > 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: Namecheap refused to revoke certificate despite domain owner changed

[Ryan Sleevi via dev-security-policy]

You know I'm strongly supportive of requiring disclosure of validation
methods, for the many benefits it brings, I'm not sure how that would
address the concern.

Consider a certificate validated under .5. Would Richard now need to hire a
lawyer to say they own their domain name now?

On Fri, Jun 1, 2018 at 3:38 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This is one of the reasons I think we should require an OID specifying the
> validation method be included in the cert. Then you can require the CA
> support revocation using the same validation process as was used to confirm
> certificate authorization. With each cert logged in CT, everyone in the
> world will know exactly how to revoke an unauthorized or no-longer-wanted
> cert.
>
> -Original Message-
> From: dev-security-policy  digicert@lists.mozilla.org> On Behalf Of Wayne Thayer via
> dev-security-policy
> Sent: Friday, June 1, 2018 1:02 PM
> To: Jakob Bohm 
> Cc: mozilla-dev-security-policy  lists.mozilla.org>
> Subject: Re: Namecheap refused to revoke certificate despite domain owner
> changed
>
> On Fri, Jun 1, 2018 at 5:06 PM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> >
> > Please contact the CA again, and inform them that BR 4.9.1.1 #6
> > requires the CA (not some reseller) to revoke the certificate within 24
> hours if:
> >
> > The CA is made aware of any circumstance indicating that use of a
> > Fully-Qualified Domain Name or IP address in the Certificate is no
> > longer legally permitted (e.g. a court or arbitrator has revoked a
> > Domain Name Registrant’s right to use the Domain Name, a relevant
> > licensing or services agreement between the Domain Name Registrant
> > and the Applicant has terminated, or the Domain Name Registrant has
> > failed to renew the Domain Name);
> >
> > While CAs are not required to discover such situations themselves,
> > they must revoke once made aware of the situation (in this case by you
> > telling them).
> >
> > At least, this is how I read the rules.
> >
> > This issue has come up in several CAB Forum discussions such as [1].
> > In
> practice, I believe that the requirement Jakob quoted is rarely invoked
> because (despite the examples), the language is too vague and narrow. It
> can also be quite difficult for a CA to verify that the revocation request
> is coming from the legitimate domain name registrant [1], making it less
> likely the CA will take action.
>
> I've made a couple of attempts to fix this, resulting in the current
> language proposed for ballot 213 [2]:
>
> The CA obtains evidence that the validation of domain authorization or
> control for any Fully-Qualified Domain Name or IP address in the
> Certificate should not be relied upon.
>
> I'd prefer a more prescriptive requirement that CAs allow anyone to revoke
> by proving that they control the domain name using one of the BR 3.2.2.4
> methods, but this is a problem because most CAs don't support every domain
> validation method and many domains are configured such that some validation
> methods can't be used.
>
> - Wayne
>
> [1] https://cabforum.org/pipermail/public/2018-January/012824.html
> [2] https://cabforum.org/pipermail/public/2018-May/013380.html
> ___
> 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: Namecheap refused to revoke certificate despite domain owner changed

[Jeremy Rowley via dev-security-policy]

This is one of the reasons I think we should require an OID specifying the 
validation method be included in the cert. Then you can require the CA support 
revocation using the same validation process as was used to confirm certificate 
authorization. With each cert logged in CT, everyone in the world will know 
exactly how to revoke an unauthorized or no-longer-wanted cert.

-Original Message-
From: dev-security-policy 
 On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Friday, June 1, 2018 1:02 PM
To: Jakob Bohm 
Cc: mozilla-dev-security-policy 
Subject: Re: Namecheap refused to revoke certificate despite domain owner 
changed

On Fri, Jun 1, 2018 at 5:06 PM Jakob Bohm via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

>
> Please contact the CA again, and inform them that BR 4.9.1.1 #6 
> requires the CA (not some reseller) to revoke the certificate within 24 hours 
> if:
>
> The CA is made aware of any circumstance indicating that use of a
> Fully-Qualified Domain Name or IP address in the Certificate is no
> longer legally permitted (e.g. a court or arbitrator has revoked a
> Domain Name Registrant’s right to use the Domain Name, a relevant
> licensing or services agreement between the Domain Name Registrant
> and the Applicant has terminated, or the Domain Name Registrant has
> failed to renew the Domain Name);
>
> While CAs are not required to discover such situations themselves, 
> they must revoke once made aware of the situation (in this case by you 
> telling them).
>
> At least, this is how I read the rules.
>
> This issue has come up in several CAB Forum discussions such as [1]. 
> In
practice, I believe that the requirement Jakob quoted is rarely invoked because 
(despite the examples), the language is too vague and narrow. It can also be 
quite difficult for a CA to verify that the revocation request is coming from 
the legitimate domain name registrant [1], making it less likely the CA will 
take action.

I've made a couple of attempts to fix this, resulting in the current language 
proposed for ballot 213 [2]:

The CA obtains evidence that the validation of domain authorization or control 
for any Fully-Qualified Domain Name or IP address in the Certificate should not 
be relied upon.

I'd prefer a more prescriptive requirement that CAs allow anyone to revoke by 
proving that they control the domain name using one of the BR 3.2.2.4 methods, 
but this is a problem because most CAs don't support every domain validation 
method and many domains are configured such that some validation methods can't 
be used.

- Wayne

[1] https://cabforum.org/pipermail/public/2018-January/012824.html
[2] https://cabforum.org/pipermail/public/2018-May/013380.html
___
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: Disallowed company name

[Jeremy Rowley via dev-security-policy]

Can you point to a jurisdiction that allows you to register the same name? I've 
never seen an example where it's permitted. Maybe the UK?

-Original Message-
From: dev-security-policy 
 On 
Behalf Of Ryan Hurst via dev-security-policy
Sent: Friday, June 1, 2018 9:28 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Disallowed company name

On Thursday, May 31, 2018 at 3:07:36 PM UTC-7, Matthew Hardeman wrote:
> On Thu, May 31, 2018 at 4:18 PM, Peter Saint-Andre via 
> dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> >
> >
> > We can also think of many business types (e.g., scammers) that would 
> > love to have names like ⒶⓅⓅⓁⒺ but that doesn't mean it's smart to 
> > issue certificates with such names. The authorities who approve of 
> > company names don't necessarily have certificate handling in mind...
> >
> 
> Indeed.  Most of the government offices responsible for approving 
> entity creation are concerned first and foremost with ensuring that a 
> unique name within their jurisdiction is chosen and that a public 
> record of the entity creation exists.  They are not concerned with 
> risk management or legitimacy, broadly speaking.
> 
> Anyone at any level of risk management in the rest of the ecosystem 
> around a business will be concerned with such matters.  Banks, trade 
> vendors, etc, tend to reject accounts with names like this.  Perhaps 
> CAs should look upon this similarly.

re: Most of the government offices responsible for approving entity creation 
are concerned first and foremost with ensuring that a unique name within their 
jurisdiction is chosen

What makes you say that, most jurisdictions have no such requirement.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/H8qZVRE5_iLNO8giNWdHECRPUnhWmem4t7fNC9FYfaI=?d=3yPd_yGx1m4dQz3H1uWi0wkNACGDGvIL4Z--LNoP9eDPIWeD0dhf9Ol_tFkJGBJFFgtnLt2HO_UCbFnaqQu3zUWQTHxGduRJO0a_H4yYE3qhYRX3wzvleMJ_cCcflYSP6doSbnmNReFJlR_Gjut8oNV6EnnecC1kzxXkdJG19OPUi3qjxKSp_r4Tlk3ExNNIwR3DF26nn1z6wKDyzP1siUdOGQT4oa70wTAPNZrK417n5z35ynmL65-hmQXBJkPLvbJL_UkzAgimEa4Sjh8YgHtKR2tCSas65vpsh0YyIXTny7Puzb8Hvs9uNxGPMfSyStkq2pMn3jZpzjfKsgYMMKDzdouOUktqhPACnhr6Qsx3ZdCTubWI8EkLpQsj4nYxjihAKD9mM-9LyUQGRh4mQOOQ0U4zY3qAE6fPOz-Upa5efnAlQhO0GtTkcOHiosY%3D=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-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: Plan to update CCADB PEM extraction tool

[J.C. Jones via dev-security-policy]

Ryan -

Originally the Observatory had "Subject+SPKI" hash field. Someone filed a
bug that Subject+SPKI field wasn't as useful for external comparisons as
the SPKI, and the Observatory changed over, replacing the old Subject+SPKI
hash with a pure SPKI hash.

We were proposing to switch to just the SPKI, simply because that is what
the Observatory is using today. However, there's no reason not to have the
Observatory provide the Subject+SPKI hash alongside the SPKI, and then we
can keep that field and effectively add the SPKI hash. That seems like a
good idea, for all the reasons David pointed out in 2016
.

Thanks for catching this!

Cheers,
J.C.

On Fri, Jun 1, 2018 at 11:57 AM, Julien Vehent via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I think the revert was a mistake. I should have added the SPKI instead of
> replacing the Subject+SPKI with SPKI. (I don't recall the discussion at the
> time, but I think someone confused Subject+SPKI for SPKI and I meant to
> address the confusion).
>
> I'll re-add the subject+spki field, this time in addition to SPKI, and
> re-populate the DB.
>
> - Julien
> ___
> 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: Namecheap refused to revoke certificate despite domain owner changed

[Wayne Thayer via dev-security-policy]

On Fri, Jun 1, 2018 at 5:06 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> Please contact the CA again, and inform them that BR 4.9.1.1 #6 requires
> the CA (not some reseller) to revoke the certificate within 24 hours if:
>
> The CA is made aware of any circumstance indicating that use of a
> Fully-Qualified Domain Name or IP address in the Certificate is no
> longer legally permitted (e.g. a court or arbitrator has revoked a
> Domain Name Registrant’s right to use the Domain Name, a relevant
> licensing or services agreement between the Domain Name Registrant
> and the Applicant has terminated, or the Domain Name Registrant has
> failed to renew the Domain Name);
>
> While CAs are not required to discover such situations themselves, they
> must revoke once made aware of the situation (in this case by you
> telling them).
>
> At least, this is how I read the rules.
>
> This issue has come up in several CAB Forum discussions such as [1]. In
practice, I believe that the requirement Jakob quoted is rarely invoked
because (despite the examples), the language is too vague and narrow. It
can also be quite difficult for a CA to verify that the revocation request
is coming from the legitimate domain name registrant [1], making it less
likely the CA will take action.

I've made a couple of attempts to fix this, resulting in the current
language proposed for ballot 213 [2]:

The CA obtains evidence that the validation of domain authorization or
control for any Fully-Qualified Domain Name or IP address in the
Certificate should not be relied upon.

I'd prefer a more prescriptive requirement that CAs allow anyone to revoke
by proving that they control the domain name using one of the BR 3.2.2.4
methods, but this is a problem because most CAs don't support every domain
validation method and many domains are configured such that some validation
methods can't be used.

- Wayne

[1] https://cabforum.org/pipermail/public/2018-January/012824.html
[2] https://cabforum.org/pipermail/public/2018-May/013380.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Namecheap refused to revoke certificate despite domain owner changed

[Jakob Bohm via dev-security-policy]

On 01/06/2018 06:22, Richard S.  Leung wrote:

I'm not sure if this is the appropriate place to post this topic, but I felt 
like this is important.

I bought myself a new domain this month, and found out that there is a 3-year 
SSL certificate valid for my domain via crt.sh.

Naturally I contacted Comodo SSL Abuse Dept. and got redirected to the reseller 
- Namecheap,
after reaching out to Namecheap they insisted that as long as I issued a new 
certificate, the valid certificate that the former domain owner had will have 
no power whatsoever ( which is not true ).

Quote:

```
Hello Richard!

Thank you for clarifying.

Regretfully, revocation can only be done with the authorization of certificate 
owner (i.e. the same details are required for it).

The certificate in question is not installed on your hosting, so it will not 
affect your domain name any way.

Unless the person with the access to the certificate hacks your hosting access, 
he will not be able to use it.

As the extra measure, you can also prohibit that certificate usage with CAA DNS 
record or HPKP header.
```

Even after ticket escalation, they're just re-assuring me that MITM somehow will not 
exist as long as I set up a new SSL cert and "there is no need to worry about the 
security of your website and the information transmitted via Internet".

So, according to Namecheap's statement, Wosign accident is just a fraud and 
people obtained github.com's certificate will do absolutely no harm to Github.

I will post the whole reply Namecheap sent me if someone requested.



Please contact the CA again, and inform them that BR 4.9.1.1 #6 requires
the CA (not some reseller) to revoke the certificate within 24 hours if:

   The CA is made aware of any circumstance indicating that use of a
   Fully-Qualified Domain Name or IP address in the Certificate is no
   longer legally permitted (e.g. a court or arbitrator has revoked a
   Domain Name Registrant’s right to use the Domain Name, a relevant
   licensing or services agreement between the Domain Name Registrant
   and the Applicant has terminated, or the Domain Name Registrant has
   failed to renew the Domain Name);

While CAs are not required to discover such situations themselves, they
must revoke once made aware of the situation (in this case by you
telling them).

At least, this is how I read the rules.




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: Disallowed company name

[Peter Saint-Andre via dev-security-policy]

On 6/1/18 10:04 AM, Ryan Sleevi via dev-security-policy wrote:
> On Fri, Jun 1, 2018 at 9:14 AM, Peter Kurrasch via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> Security can be viewed as a series of AND's that must be satisfied in
>> order to conclude "you are probably secure". For example, when you browse
>> to an important website, make sure that "https" is used AND that the domain
>> name looks right  AND that a "lock icon" appears in the UI AND, if the site
>> uses EV certs, that the name of the organization seems correct. Failing any
>> of those, stop immediately; if all of them hold true, you are probably fine.
>>
> 
> Note that research has shown that your first, second, third, and fourth
> options are all unreasonable requests of humans trying to be productive.
> 
> That is, https is unnecessarily confusing, "the domain looks right" is an
> unreasonable task (might as well say "Make sure the fabardle is boijoing"
> when presenting domains), and lock icons positive indicator is unnecessary
> hostile. And that's before we get to EV certs (are you saying I shouldn't
> do business with KLM?)
> 
> So basically, all four steps are unreasonable to determine you're fine :)

Yes, it's a shame that we technologists have abjectly failed at
producing usable security.

However, given the mess we've made of things, we can at least do our
best to protect protect users with the weak and faulty mechanisms we've
created (and work to create better ones). What policies are appropriate
for organizational names in certificates?

Peter




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: Disallowed company name

[Ryan Sleevi via dev-security-policy]

On Fri, Jun 1, 2018 at 9:14 AM, Peter Kurrasch via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Security can be viewed as a series of AND's that must be satisfied in
> order to conclude "you are probably secure". For example, when you browse
> to an important website, make sure that "https" is used AND that the domain
> name looks right  AND that a "lock icon" appears in the UI AND, if the site
> uses EV certs, that the name of the organization seems correct. Failing any
> of those, stop immediately; if all of them hold true, you are probably fine.
>

Note that research has shown that your first, second, third, and fourth
options are all unreasonable requests of humans trying to be productive.

That is, https is unnecessarily confusing, "the domain looks right" is an
unreasonable task (might as well say "Make sure the fabardle is boijoing"
when presenting domains), and lock icons positive indicator is unnecessary
hostile. And that's before we get to EV certs (are you saying I shouldn't
do business with KLM?)

So basically, all four steps are unreasonable to determine you're fine :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Namecheap refused to revoke certificate despite domain owner changed

[Richard S. Leung via dev-security-policy]

I'm not sure if this is the appropriate place to post this topic, but I felt 
like this is important.

I bought myself a new domain this month, and found out that there is a 3-year 
SSL certificate valid for my domain via crt.sh. 

Naturally I contacted Comodo SSL Abuse Dept. and got redirected to the reseller 
- Namecheap, 
after reaching out to Namecheap they insisted that as long as I issued a new 
certificate, the valid certificate that the former domain owner had will have 
no power whatsoever ( which is not true ).

Quote:

```
Hello Richard!

Thank you for clarifying.

Regretfully, revocation can only be done with the authorization of certificate 
owner (i.e. the same details are required for it). 

The certificate in question is not installed on your hosting, so it will not 
affect your domain name any way.

Unless the person with the access to the certificate hacks your hosting access, 
he will not be able to use it.

As the extra measure, you can also prohibit that certificate usage with CAA DNS 
record or HPKP header.
``` 

Even after ticket escalation, they're just re-assuring me that MITM somehow 
will not exist as long as I set up a new SSL cert and "there is no need to 
worry about the security of your website and the information transmitted via 
Internet".

So, according to Namecheap's statement, Wosign accident is just a fraud and 
people obtained github.com's certificate will do absolutely no harm to Github.

I will post the whole reply Namecheap sent me if someone requested.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Disallowed company name

[Ryan Hurst via dev-security-policy]

On Thursday, May 31, 2018 at 3:07:36 PM UTC-7, Matthew Hardeman wrote:
> On Thu, May 31, 2018 at 4:18 PM, Peter Saint-Andre via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> >
> >
> > We can also think of many business types (e.g., scammers) that would
> > love to have names like ⒶⓅⓅⓁⒺ but that doesn't mean it's smart to issue
> > certificates with such names. The authorities who approve of company
> > names don't necessarily have certificate handling in mind...
> >
> 
> Indeed.  Most of the government offices responsible for approving entity
> creation are concerned first and foremost with ensuring that a unique name
> within their jurisdiction is chosen and that a public record of the entity
> creation exists.  They are not concerned with risk management or
> legitimacy, broadly speaking.
> 
> Anyone at any level of risk management in the rest of the ecosystem around
> a business will be concerned with such matters.  Banks, trade vendors, etc,
> tend to reject accounts with names like this.  Perhaps CAs should look upon
> this similarly.

re: Most of the government offices responsible for approving entity creation 
are concerned first and foremost with ensuring that a unique name within their 
jurisdiction is chosen

What makes you say that, most jurisdictions have no such requirement.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Plan to update CCADB PEM extraction tool

[Ryan Sleevi via dev-security-policy]

On Fri, Jun 1, 2018 at 10:20 AM, Ryan Sleevi  wrote:

>
>
> On Thu, May 31, 2018 at 6:54 PM, Kathleen Wilson via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> All,
>>
>> We are working towards updating the tool that we use in the CCADB to
>> parse PEM data and fill in the corresponding fields in the CCADB. The new
>> tool is in the TLS Observatory:
>>
>> https://github.com/mozilla/tls-observatory
>>
>> 3) Certificate ID
>> OLD: hash(Subject + SPKI), with colons
>> NEW: hash(SPKI), no colons
>> OLD: 4F:31:A6:06:59:45:EA:BC:6A:45:CB:AD:72:D8:0A:20:A4:40:0E:55:
>> 05:B9:2A:0C:4C:F1:F6:C1:A3:10:92:9F
>> NEW: FF5680CD73A5703DA04817A075FD462506A73506C4B81A1583EF549478D26476
>>
>
> Thanks for the heads up. Could you explain why the change to just SPKI?
>

(For context,
https://github.com/mozilla/tls-observatory/commit/a8124ad65cb6f7ea8aca9648bc8985157a2a84a4#diff-738e6d4c59e010e98c704b9802751ebe
was the change, but it didn't document the motivation)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Plan to update CCADB PEM extraction tool

[Ryan Sleevi via dev-security-policy]

On Thu, May 31, 2018 at 6:54 PM, Kathleen Wilson via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> All,
>
> We are working towards updating the tool that we use in the CCADB to parse
> PEM data and fill in the corresponding fields in the CCADB. The new tool is
> in the TLS Observatory:
>
> https://github.com/mozilla/tls-observatory
>
> 3) Certificate ID
> OLD: hash(Subject + SPKI), with colons
> NEW: hash(SPKI), no colons
> OLD: 4F:31:A6:06:59:45:EA:BC:6A:45:CB:AD:72:D8:0A:20:A4:40:0E:55:
> 05:B9:2A:0C:4C:F1:F6:C1:A3:10:92:9F
> NEW: FF5680CD73A5703DA04817A075FD462506A73506C4B81A1583EF549478D26476
>

Thanks for the heads up. Could you explain why the change to just SPKI?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Disallowed company name

[Peter Kurrasch via dev-security-policy]

  Regarding the options listed, I would agree with the first 2 but disagree with the third.My characterization of this situation is as follows:1. Trust is not granted to everyone. This is true in virtual realms as well as the real world. For example, not everyone in this forum trusts me (and perhaps shouldn't). 2. Bad actors will resort to trickery, lies, and deception to get what they want and sometimes they will be successful despite every effort to stop them.3. The onus is on CA's to prove that "additional validation" equals "more trustworthy". Their failure to do so will lead to the demise of EV.Security can be viewed as a series of AND's that must be satisfied in order to conclude "you are probably secure". For example, when you browse to an important website, make sure that "https" is used AND that the domain name looks right  AND that a "lock icon" appears in the UI AND, if the site uses EV certs, that the name of the organization seems correct. Failing any of those, stop immediately; if all of them hold true, you are probably fine.As the token bad guy in this forum, I have to make all of those steps happen if I expect to trick my victims. If I bother to get an EV cert but the name wildly mismatches for my particular objective, there's an increased chance my efforts at deception will fail. If any of those steps are taken away, my job is that much easier.From: Wayne Thayer via dev-security-policySent: Thursday, May 31, 2018 5:39 PM‎...> In my opinion, this is just a rehash of the same debate we've been havingover misleading information in certificates ever since James obtained the"Identity Verified" EV certificate. The options we have to address thisseem to be:1. Accept that some entities, based on somewhat arbitrary rules anddecisions, can't get OV or EV certs2. Accept that the organization information in certificates will sometimesbe misleading or at least uninformative3. Decide that organization information in certificates is irrelevant andignore it, or get rid of itWe currently have chosen "some parts of all of the above" :-)I am most interested in exploring the first option since that is thedirection CAs are headed with the recent proposal to limit EV certificatesto organizations that have existed for more than 18 months [1]. As long asanyone can obtain a DV certificate, are restrictions on who can obtain anOV or EV certificate a problem, and if so, why?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy