Hi Cynthia,
We've figured out what happened with your certificate but are still looking at
whether other certificates were issued using the same process. I don't have
enough information to file an incident report yet, but I wanted to give you the
update I promised earlier.
Basically, here's
While I was going to respond to the below, Nick Lamb has beaten me to it.
I concur in full with the remarks in that reply.
We should not be picking national favorites as a root program. There's a
whole world out there which must be supported.
What we should be doing is ensuring that we know the
On Wed, Feb 27, 2019 at 9:04 AM Nick Lamb wrote:
>
> It does feel as though ARPA should consider adding a CAA record to
> in-addr.arpa and similar hierarchies that don't want certificates,
> denying all CAs, as a defence in depth measure.
>
Unless I significantly misunderstand CAA, this
On Wed, 27 Feb 2019 09:30:45 -0500
Alex Gaynor via dev-security-policy
wrote:
> Finally, I think there's a point that is very much being stepped
> around here. The United States Government, including its intelligence
> services, operate under the rule of law, it is governed by both
> domestic
Having received no further comments, I am recommending approval of Hongkong
Post's inclusion request.
As Matt suggested earlier in this thread, I would not typically approve a
request for a CA with an open compliance bug, but in this case the bug is
open awaiting implementation of pre-issuance
Well yes, assuming the validation person overrides the safeguards and randomly
changes the scope of the domain validation to something other than what the
system specifies. We're still looking into how this happened and if the
validation agent did this in any other case.
-Original
Okay that seems like an issue as to me that says that this could have
happened to any domain and not just in-addr.arpa?
- Cynthia
On 2019-02-27 01:55, Jeremy Rowley via dev-security-policy wrote:
From our side, a validation agent weirdly scoped the domain, saying that the
domain was
> On 27/02/2019 00:10, Matthew Hardeman wrote:
> > Is it even proper to have a SAN dnsName in in-addr.arpa ever?
> >
> > While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it
> > rarely has anything other than PTR and NS records defined.
> >
>
> While there is no current use, and the
On 27/02/2019 09:54, michel.lebihan2...@gmail.com wrote:
I also found that certificates that were issued very recently have duplicate
SANs:
https://crt.sh/?id=1231853308=cablint,x509lint,zlint
https://crt.sh/?id=1226557113=cablint,x509lint,zlint
On Wed, Feb 27, 2019 at 8:04 PM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Tue, 26 Feb 2019 17:10:49 -0600
> Matthew Hardeman via dev-security-policy
> wrote:
>
> > Is it even proper to have a SAN dnsName in in-addr.arpa ever?
>
> It does feel as
I also found that certificates that were issued very recently have duplicate
SANs:
https://crt.sh/?id=1231853308=cablint,x509lint,zlint
https://crt.sh/?id=1226557113=cablint,x509lint,zlint
https://crt.sh/?id=1225737388=cablint,x509lint,zlint
___
Hello,
I noticed this certificate
https://crt.sh/?id=1231965201=cablint,x509lint,zlint that has an invalid
domain `mail.xinhua08.con` in SANs. This looks like a typo and
`mail.xinhua08.com` is present in other certificates. Such an issue makes me
wonder about the quality of their validation.
On 27/02/2019 01:31, Matthew Hardeman wrote:
> I'd like to take a moment to point out that determination of the beneficial
> ownership of business of various sorts (including CAs) can, in quite a
> number of jurisdictions, be difficult to impossible (short of initiating
> adverse legal
On Tue, 26 Feb 2019 17:10:49 -0600
Matthew Hardeman via dev-security-policy
wrote:
> Is it even proper to have a SAN dnsName in in-addr.arpa ever?
It does feel as though ARPA should consider adding a CAA record to
in-addr.arpa and similar hierarchies that don't want certificates,
denying all
On 27/02/2019 00:10, Matthew Hardeman wrote:
Is it even proper to have a SAN dnsName in in-addr.arpa ever?
While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it rarely
has anything other than PTR and NS records defined.
While there is no current use, and the test below was
(Writing in my personal capacity)
On Tue, Feb 26, 2019 at 7:31 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
[...]
> All of Google, Amazon, and Microsoft are in the program. All of these have
> or had significant business with at least the US DOD
G’day Folks,
I want to thank Ryan for sharing the relevant discussion history regarding the
change that precipitated the current language for serialNumber entropy in the
BRs. Based on this background, it is clear to DM what is required for expected
compliance with this control and that this
> (Sorry for continuing this off-topic thread.)
>
> Hello Tomas,
>
> I hope this is indeed not your current implementation and that it wasn’t in
> use anymore when ballot 164 became effective, because that’s not safe:
I tried to say so in my original post, but I see I was not very clear.
tomasshredder--- via dev-security-policy
writes:
>We still get asked by customers to implement sequential serial numbers from
>time to time, but it's getting more and more rare.
Another reason for using random data, from the point of view of a software
toolkit provider, is that it's the only
On 27 Feb 2019, at 09:07, tomasshredder--- via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>>
wrote:
On Wednesday, February 27, 2019 at 3:27:05 AM UTC+1, Peter Gutmann wrote:
Mike Kushner via dev-security-policy
mailto:dev-security-policy@lists.mozilla.org>>
writes:
On Wednesday, February 27, 2019 at 3:27:05 AM UTC+1, Peter Gutmann wrote:
> Mike Kushner via dev-security-policy
> writes:
>
> >EJBCA was possible the first (certainly one of the first) CA products to use
> >random serial numbers.
>
> Random serial numbers have been in use for a long, long
21 matches
Mail list logo
