Re: question about DNS CAA and S/MIME certificates

> 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

Re: question about DNS CAA and S/MIME certificates

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

RE: question about DNS CAA and S/MIME certificates

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

Re: question about DNS CAA and S/MIME certificates

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 >

RE: question about DNS CAA and S/MIME certificates

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

Re: question about DNS CAA and S/MIME certificates

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

RE: question about DNS CAA and S/MIME certificates

> 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

Re: question about DNS CAA and S/MIME certificates

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

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

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

Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

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

Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

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

Re: question about DNS CAA and S/MIME certificates

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

Re: question about DNS CAA and S/MIME certificates

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

Re: question about DNS CAA and S/MIME certificates

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

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

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,

Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

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

RE: question about DNS CAA and S/MIME certificates

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.

RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)

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

Re: question about DNS CAA and S/MIME certificates

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

Re: question about DNS CAA and S/MIME certificates

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

Re: question about DNS CAA and S/MIME certificates

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

Re: Unrevoked/unexpired certificate with Debian Weak Key

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

Re: Unrevoked/unexpired certificate with Debian Weak Key

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

Unrevoked/unexpired certificate with Debian Weak Key

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

Re: question about DNS CAA and S/MIME certificates

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