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
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.
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
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
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
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
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
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 ;
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
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
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
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
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
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:
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
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
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
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
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,
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
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
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
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
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
24 matches
Mail list logo
