Just to say that looking at this from Europe, I don't see this feasible.
Citizens getting their personal eIDAS-compliant certificate go through
face-to-face validation and will give virtually any valid e-mail address to
appear in their certificate.
El sábado, 12 de mayo de 2018, 2:30:58 (UTC+
Hi,
Yesterday was the 10y anniversary of the Debian OpenSSL random number
generator bug.
A few days ago I did a re-check of the CT logs for vulnerable keys.
I found one unexpired, unrevoked certificate issued by a CA called
"QuoVadis". I reported it and it's been revoked, they told me they'll
ch
On 14/05/2018 10:42, Hanno Böck wrote:
Hi,
Yesterday was the 10y anniversary of the Debian OpenSSL random number
generator bug.
A few days ago I did a re-check of the CT logs for vulnerable keys.
I found one unexpired, unrevoked certificate issued by a CA called
"QuoVadis". I reported it and i
On 14/05/18 11:39, Jakob Bohm via dev-security-policy wrote:
On 14/05/2018 10:42, Hanno Böck wrote:
Hi,
Yesterday was the 10y anniversary of the Debian OpenSSL random number
generator bug.
A few days ago I did a re-check of the CT logs for vulnerable keys.
I found one unexpired, unrevoked cer
It seems perfectly reasonable and desirable to require that CAs, regardless
of the type of certificate they are issuing, respect CAA.
If an email provider wishes to restrict some types of certificates (e.g.
HTTPS) while allow others (e.g. S/MIME), this could be accomplished through
additional expr
Pedro Fuentes wrote:
> Just to say that looking at this from Europe, I don't see this feasible.
>
> Citizens getting their personal eIDAS-compliant certificate go through
> face-to-face validation and will give virtually any valid e-mail address to
> appear in their certificate.
>
Then that
But it also seems reasonable for organisations making CAA assertions to know
the scope of their stipulations before they make them, no?
So, if in the case of Yahoo, they make the assertion “All of our web
certificates should come from DigiCert”, are they aware that they are also
making the stat
Another approach could be to have something akin to the (non-ICANN)
public suffix list, but for e-mail. This would list e-mail domains
where the e-mail address holders are not the subordinates (employees,
students, etc.) of the domain holder.
Such a list would have multiple uses (just like the p
For the record, I posted someone else's strength testing algorithm, and pointed
out that it was bad 😊 I personally don't think building strength testing
algorithms
is hopeless, and I think good ones are very useful. I tend to agree with the
current
NIST recommendation, which is to primarily o
Yes, but as you correctly point out, this should be taken care of as part of
the CAA-bis
effort. The original RFC had enough errors with respect to web certificates; I
think
it would be irresponsible to apply it to e-mail certificates right now without
carefully
considering the consequences.
W
On Wednesday, May 9, 2018 at 11:42:56 PM UTC-4, Wayne Thayer wrote:
> I think we have settled on the following resolution to this issue:
>
> Add the following to section 5.2 (Forbidden and Required Practices):
>
> CAs MUST NOT generate the key pairs for end-entity certificates that have
> > an EK
I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion, Dean???
- We can’t permit user generated passwords (at least that is Tim's proposal,
Wayne may not agree yet but he will when he reads this email)
- We can’t distribute both the password and PKCS#12 over the same channel, even
On Mon, May 14, 2018 at 11:48 AM, Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> But it also seems reasonable for organisations making CAA assertions to
> know the scope of their stipulations before they make them, no?
>
> So, if in the case of Yahoo, they ma
The Public Suffix List is a model for failure, not success - and I say that
as one of the two PSL maintainers. As to the remaining points, I think each
and every one of them doesn't actually hold up to scrutiny, and in fact,
the opposite conclusion is more in line with reality.
For example, if ant
On Mon, May 14, 2018 at 1:10 PM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Yes, but as you correctly point out, this should be taken care of as part
> of the CAA-bis
> effort. The original RFC had enough errors with respect to web
> certificates; I th
On Mon, May 14, 2018 at 11:29 AM Bruce via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Wednesday, May 9, 2018 at 11:42:56 PM UTC-4, Wayne Thayer wrote:
> > I think we have settled on the following resolution to this issue:
> >
> > Add the following to section 5.2 (Forb
On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion,
> Dean???
> - We can’t permit user generated passwords (at least that is Tim's
> proposal, Wayne may not
On 14/05/2018 22:53, Wayne Thayer wrote:
On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion,
Dean???
- We can’t permit user generated passwords (at least tha
On 14/05/2018 20:55, Ryan Sleevi wrote:
The Public Suffix List is a model for failure, not success - and I say that
as one of the two PSL maintainers. As to the remaining points, I think each
and every one of them doesn't actually hold up to scrutiny, and in fact,
the opposite conclusion is more
> Today this is a "non-issue" because nothing is obligating CAs to respect
> CAA,
> and thus they can (and are) doing the thing that helps them issue more
> certificates (and, presumably, make more money) - but that doesn't
> necessarily
> mean its the right thing.
I can think of at least one C
El lunes, 14 de mayo de 2018, 23:59:07 (UTC+2), Tim Hollebeek escribió:
> As Neil correctly notes, it would be foolish to try to impose semantics and
> apply
> policy from the web CAA records onto email certificate issuance without first
> figuring out what the semantics, requirements and polici
There’s an IETF component, but minimum necessary standards for email
certificate issuance is a policy issue, not a technical one.
Somewhere, it needs to say “CAs issuing e-mail certificates MUST check CAA in
accordance with CAA-bis.”
-Tim
With CABF governance reform coming into effect
I don't actually think there is any IETF component to this. There can be,
but it's not required to be.
On Mon, May 14, 2018 at 6:20 PM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> There’s an IETF component, but minimum necessary standards for email
> ce
Normally I’d agree that IETF cannot and should not be a blocker for action at
Mozilla and/or CABF, but based on our experience with CAA for web certificates,
I would encourage people to get in their time machines and go back two to three
years, and listen to Tim standing up and saying “I like CA
I'm not sure how that's advancing the discussion forward or adding new
information. The discussion of CAA and wanting to get feedback predates
even the IETF finalization, as multiple browsers kept encouraging CAs to
experiment with and attempt to deploy CAA so that we could make sure the
kinks were
> On 14 May 2018, at 20:55, Ryan Sleevi via dev-security-policy
> wrote:
>
> If there are proponents of a 'fail open' model,
> especially amongst CAs, then does it behove them to specify as quickly as
> possible a 'fail closed' model, so that we don't have to try and divine
> intent and second
26 matches
Mail list logo
