Re: [cabfpub] Voting ends on Thursday, Sept. 6 at 11 am Eastern Time for Ballot SC8: Election of Server Certificate Working Group Chair

Comodo Security Solutions votes yes on Ballot SC8 > On Sep 4, 2018, at 11:22 AM, Kirk Hall via Public wrote: > > Voting ends on Thursday, Sept. 6 at 11 am Eastern Time for Ballot SC8: > Election of Server Certificate Working Group Chair. > > Remember, there are two ballots occurring at the

Re: [cabfpub] [Servercert-wg] Voting Begins: Ballot SC2 - version 2: Validating certificates via CAA CONTACT

Comodo abstains on SC2 Given my experience of fixing up issues raised after a ballot, I would prefer that we get this right. > On Jul 24, 2018, at 4:44 PM, Curt Spann via Public > wrote: > > Apple abstains on ballot SC2. > > Since this may have security implication I would rather take

Re: [cabfpub] Voting Begins: Ballot SC2 - version 2: Validating certificates via CAA CONTACT

I was out at IETF while this was being discussed. Unfortunately, the person I needed to speak to about it was not there. Thus I do not have status on: https://tools.ietf.org/id/draft-ietf-dnsop-attrleaf-12.txt This is adopted as a WG

Re: [cabfpub] XMSS became an RFC

k from the community and help make it clearer what an "RFC" > means. > > On Wed, Jun 6, 2018 at 9:19 AM, philliph--- via Public <mailto:public@cabforum.org>> wrote: > Re the post quantum crypto discussion, XMSS is now an RFC. > > https://datatracker.ie

[cabfpub] XMSS became an RFC

Re the post quantum crypto discussion, XMSS is now an RFC. https://datatracker.ietf.org/doc/rfc8391/ ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] For Discussion: S/MIME Working Group Charter

But the critical word was not in the discussion. Dimitri’s observation that the groups are really divided by id-kp- is the critical point in my mind because it also shows where the boundary lies between CABForum and IETF. S/MIME needs some serious fixing. It is currently a niche product that

Re: [cabfpub] Voting Begins: Ballot 220: Minor Cleanups (Spring 2018)

Comodo Group Inc. votes yes. > On Mar 23, 2018, at 6:40 AM, Tim Hollebeek via Public > wrote: > > > Ballot 220: Minor Cleanups (Spring 2018) > > Purpose of Ballot: This ballot corrects two incorrect cross-references and > one terminology error. > > The following

Re: [cabfpub] Voting Begins: Ballot 206: Amendment to IPR Policy & Bylaws re Working Group Formation

Comodo Group Inc. votes yes. > On Mar 27, 2018, at 11:20 PM, Virginia Fournier via Public > wrote: > > > Ballot 206: Amendment to IPR Policy & Bylaws re Working Group Formation > > Purpose of Ballot: This ballot is the result of the work done by the > CA/Browser Forum

Re: [cabfpub] How do you handle mass revocation requests?

Going back to the original question. We have a format for a certificate request (well a few actually). Do we have a PKIX feature that can be used to allow a key holder to request revocation? I can’t think of a PKIX standard for one and it does appear to be a missing feature. Ron Rivest and

Re: [cabfpub] Voting begins: Ballot 218 version 2

Comodo Security Services votes Yes on ballot 218 > > From: Public > on behalf of Tim Hollebeek via Public > > > Reply-To: Tim Hollebeek

Re: [cabfpub] Draft ballot 219: Clarify handling of CAA Record Sets with no "issue"/"issuewild" property tag

+1 Unless the semantics are changed, an errata can be approved rather than held for document revision. Since we are not proposing to change the semantics, that would be the right approach. We did have a long discussion about this with the interaction of issue and issuewild if people recall.

[cabfpub] Happy new year security fiasco

I have not thought out how this will affect our pond yet but it looks like it is going to be a press field day. https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ ___

Re: [cabfpub] Should we cancel CABF Conference on Thursday?

No, that was the message I was responding to. You raised the meta-issue of precedent, I was responding to the meta-issue not to 214. At the end of the day, there has to be some cut over for every CA such that they are doing processing X on one day and processing Y the next. Having the CABForum

Re: [cabfpub] Fix to CAA ballot

ready to go. > > From: Public [mailto:public-boun...@cabforum.org > <mailto:public-boun...@cabforum.org>] On Behalf Of philliph--- via Public > Sent: Saturday, September 23, 2017 7:48 AM > To: CA/Browser Forum Public Discussion List <public@cabforum.org > <mailto:pu

[cabfpub] Fix to CAA ballot

Looking at the current situation, I am thinking that the fixup ballot to the fixup ballot should assume 214 fails and be worded as follows: In the Baseline Requirements v1.4.9 Section 3.2.2.8. CAA Records Strike: As part of the issuance process, the CA MUST check for a CAA record for each

Re: [cabfpub] CAA: Interpretation of 3.2.2.8 + 3.2.2.5

That is my interpretation. Further, given the state of the reverse-DNS, I would be nervous about trying to extend CAA to address IP address certs. If there was a requirement for such, it looks like it will be in scope for LAMPS. The intent of CAA was to put limits on the issue of certs with

Re: [cabfpub] Two CAA questions

> On Aug 2, 2017, at 6:23 PM, Kirk Hall via Public wrote: > > I have two CAA questions from our technical group. I am posting here to see > what others think. Do we need to make any changes to BR 3.2.2.8 (created > under Ballot 187)? Thanks for any feedback. > >

Re: [cabfpub] [Ext] Fixup ballot for CAA

then remove > that once/if the CAA document is updated? > > This seems clearer and with one less dependency - namely, on the CABForum > website. > > On Tue, Jul 11, 2017 at 1:30 PM, philliph--- via Public <public@cabforum.org> > wrote: >> So to close on thi

Re: [cabfpub] [Ext] Fixup ballot for CAA

So to close on this, I suggest the following that I think meets the points raised by both Paul and myself which I think are equally valid: 1) Reference the IETF Errata in the BR text 2) Archive a copy of the errata on the CABForum site 3) In the references section of the BR, cite the IETF as the

Re: [cabfpub] no CAA authorizations -- RFC 6844

It was certainly the intention that presence of an issue prevents issue of wildcard certs. I will re-read that section and report. Meanwhile, I have had some comment on the discovery fixup and will rev that. > On Jun 22, 2017, at 8:34 AM, Gervase Markham via Public >

Re: [cabfpub] OCSP Requests and Do Not Track

They all can trivially, the sites should perform OCSP stapling. Privacy was one of the original reasons for proposing it. > On Jun 14, 2017, at 5:41 PM, Jacob Hoffman-Andrews via Public > wrote: > > Forwarding on behalf of a colleague at EFF who is working on the Do Not

Re: [cabfpub] [EXTERNAL]Re: ]RE: Ballot 194 - Effective Date of Ballot 193 Provisions is in the VOTING period (ends April 16)

The best way to address future concerns would be to propose a ballot to fix them. > On Apr 18, 2017, at 4:42 PM, Ryan Sleevi via Public > wrote: > > > > On Tue, Apr 18, 2017 at 4:25 PM, Peter Bowen > wrote: > Ryan, > > Am I

Re: [cabfpub] [EXTERNAL]Re: ]RE: Ballot 194 - Effective Date of Ballot 193 Provisions is in the VOTING period (ends April 16)

The best use you could make of your time would be to let this absurd argument drop. > On Apr 18, 2017, at 11:24 AM, Ryan Sleevi <sle...@google.com> wrote: > > > > On Tue, Apr 18, 2017 at 11:20 AM, philliph--- via Public <public@cabforum.org > <mailto:public@

Re: [cabfpub] [EXTERNAL]Re: ]RE: Ballot 194 - Effective Date of Ballot 193 Provisions is in the VOTING period (ends April 16)

'Votes not submitted to the Public Mail...’ If we are going to be hyper pedantic about this, nobody disputes that the vote was submitted to the Public Mail list. It is therefore a valid vote. I note that in making the claims to the contrary, people have 1) Stated that Microsoft’s intent in

Re: [cabfpub] Notice of Review Period - Ballot 194 - Effective Date of Ballot 193 Provisions

> On Apr 18, 2017, at 10:33 AM, Ryan Sleevi wrote: > > > > On Tue, Apr 18, 2017 at 10:28 AM, phill...@comodo.com > > wrote: > Actually, I had just expressed support that it was. > > That's

Re: [cabfpub] ]RE: Ballot 194 - Effective Date of Ballot 193 Provisions is in the VOTING period (ends April 16)

> On Apr 18, 2017, at 10:31 AM, Ryan Sleevi <sle...@google.com> wrote: > > > > On Tue, Apr 18, 2017 at 10:25 AM, philliph--- via Public <public@cabforum.org > <mailto:public@cabforum.org>> wrote: > I am finding the arguments here rather sur

Re: [cabfpub] Notice of Review Period - Ballot 194 - Effective Date of Ballot 193 Provisions

Actually, I had just expressed support that it was. > On Apr 18, 2017, at 10:19 AM, Ryan Sleevi via Public > wrote: > > Kirk, > > I haven't seen you address this yet. To date, you have been the only one to > express support that the vote was valid according to our

Re: [cabfpub] ]RE: Ballot 194 - Effective Date of Ballot 193 Provisions is in the VOTING period (ends April 16)

I am finding the arguments here rather surprising. When counting an election, the questions at issue are always 1) Is the person permitted to cast a ballot 2) What was their intent So to dismiss ‘intent’ as irrelevant is off the point, to say the least. In this case we have the concern that

Re: [cabfpub] Ballot 195 - CAA Fixup is in the DISCUSSION period (ends April 10)

> On Apr 10, 2017, at 3:18 PM, Jacob Hoffman-Andrews <j...@letsencrypt.org> > wrote: > > On Mon, Apr 10, 2017 at 11:20 AM, philliph--- via Public <public@cabforum.org > <mailto:public@cabforum.org>> wrote: > Discussion in the LAMPS WG indicated that the co

Re: [cabfpub] Ballot 195 - CAA Fixup is in the DISCUSSION period (ends April 10)

> On Apr 10, 2017, at 2:04 PM, Ryan Sleevi via Public > wrote: > > > > On Mon, Apr 10, 2017 at 12:39 PM, Gervase Markham via Public > > wrote: > On 10/04/17 17:27, Phillip Hallam-Baker via Public wrote: > > As I proposed

Re: [cabfpub] Ballot 195 - CAA Fixup is in the DISCUSSION period (ends April 10)

The rules for IETF errata depend on the nature of the change. Changes to the language that do not affect the technical details may be accepted or rejected. Changes to the technical content are either rejected or ‘held for document update’, that is publication of a new RFC. This is a change in

Re: [cabfpub] Brazilian bank DNS heist

> On Apr 6, 2017, at 3:44 PM, Richard Moore <r...@kde.org> wrote: > > I'm including Ryan since he's said before he's willing to forward things to > the CAB list. Comments inline. > > On 6 April 2017 at 18:46, philliph--- via Public <public@cabforum.org > <m

[cabfpub] Brazilian bank DNS heist

Several folk have asked me to take a look at this:

Re: [cabfpub] Why HSMs?

Why we have HSMs likely comes down to ‘its the way the NSA did it’. I am certain we want to have them and can come up with a number of reasons to justify the rather modest cost compared to everything else we do to run a CA. But we should probably understand the reasons in more detail. One

Re: [cabfpub] What is identity anyway? Was: C=GR, C=UK exceptions in BRs

Since I was there and you were not, I don’t see how you think you can tell me what really happened. > On Mar 21, 2017, at 9:48 AM, Ryan Sleevi wrote: > > Phillip, > > I must confess, it's hard to see what point you're attempting to make, so I'm > hoping you might take

Re: [cabfpub] C=GR, C=UK exceptions in BRs

Ryan, ‘ Do you think you could at least try to conduct your discussion here in an approximately professional fashion? The constant personal attacks are really unhelpful. Phill > On Mar 20, 2017, at 11:44 PM, Ryan Sleevi via Public > wrote: > > Dimitris, > >

Re: [cabfpub] C=GR, C=UK exceptions in BRs

The UN is not the only international organization. There are dozens. And they do not have sovereign status. Not even the UN. In practice, CERN was happy being cern.ch and the UN being un.org despite the invention of .int just for them. Let us not go making

Re: [cabfpub] Ballot 187 - Make CAA Checking Mandatory

We tried a few identifier schemes. Paul Hoffman suggested Domain Names as it is the DNS. Once you have a domain name in the record, you can use it as the basis for automation, we can define additional records to specify where to go to get a cert. 'Machine readable CPS' was suggested in the

Re: [cabfpub] Ballot 187 - Make CAA Checking Mandatory

Ryan and Peter are both right. This is where we got to the first time round. Whichever choice is made is right for some set of use cases and wrong for others. The underlying problem being that the DNS does not have a notion of administrative responsibility that is separate from maintaining a

Re: [cabfpub] Ballot 187 - Make CAA Checking Mandatory

> On Feb 24, 2017, at 9:17 PM, Peter Bowen <pzbo...@gmail.com> wrote: > > On Fri, Feb 24, 2017 at 5:49 PM, philliph--- via Public > <public@cabforum.org> wrote: >> On the CAA recursive part, I am trying to track down why there is an >> existing errata tha

Re: [cabfpub] SHA-1 Collision Found

It seems I mis-spoke on EdDSA. Curve448x uses SHAKE-256 as the internal compression function and that is a part of SHA-3. Curve25519 uses SHA-2. I thought I had lost that battle. Now I have not read the specs deeply enough to work out if that means SHA-3 is a requirement. But just as you

[cabfpub] SHA-3 and/or Curve-X

> On Feb 24, 2017, at 1:34 PM, Gervase Markham <g...@mozilla.org> wrote: > > Hi Philip, > > This is a useful timeline. It may be missing a few items, though: > > On 24/02/17 09:58, philliph--- via Public wrote: >> The availability of HSMs is a concern

Re: [cabfpub] SHA-1 Collision Found

> On Feb 24, 2017, at 12:56 PM, Eric Mill wrote: > > > > On Fri, Feb 24, 2017 at 12:11 PM, phill...@comodo.com > > wrote: > >> On Feb 24, 2017, at 11:38 AM, Eric Mill >

Re: [cabfpub] SHA-1 Collision Found

> On Feb 24, 2017, at 11:38 AM, Eric Mill wrote: > > On Fri, Feb 24, 2017 at 10:46 AM, phill...@comodo.com > > wrote: > > You are misrepresenting what I am saying. Do not put words in my mouth

Re: [cabfpub] Ballot 185 - Next steps

> On Feb 24, 2017, at 4:35 AM, Dimitris Zacharopoulos via Public > wrote: > > I believe this is not exactly our view, nobody is arguing that 13 months is > not more secure than 39 or 27 months. I am. The revocation infrastructure is currently calibrated to limit

Re: [cabfpub] SHA-1 Collision Found

> On Feb 23, 2017, at 11:31 PM, Eric Mill wrote: > > On Thu, Feb 23, 2017 at 10:54 PM, Phillip Hallam-Baker via Public > > wrote: > > Things have to break before some people will act. Which is why I consider the > proposal

Re: [cabfpub] SHA-1 Collision Found

> On Feb 23, 2017, at 11:59 PM, Ryan Sleevi wrote: > > > > On Thu, Feb 23, 2017 at 8:52 PM, Peter Bowen > wrote: > All that is preventing the use of id-rsassa-pkcs1-v1_5-with-sha3-256, > id-rsassa-pkcs1-v1_5-with-sha3-384, and

Re: [cabfpub] Ballot 185 - Next steps

Given today’s SHA-1 news, how about we discuss moves to deploy SHA-3 as a fallback to SHA-2 instead? > On Feb 23, 2017, at 9:39 PM, Ryan Sleevi via Public > wrote: > > > > On Thu, Feb 23, 2017 at 5:23 PM, Kirk Hall via Public

Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates: User input

Right now it takes me about 5 years to get a change in the WebPKI. That is three years of getting agreement on the technology, two years to get the infrastructure built out to deploy and then it takes time for the certificate population to rotate. Now if people would be willing to help shorten

Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates: User input

are not updated. > On Feb 10, 2017, at 12:04 PM, Ryan Sleevi <sle...@google.com> wrote: > > > > On Fri, Feb 10, 2017 at 8:58 AM, philliph--- via Public <public@cabforum.org > <mailto:public@cabforum.org>> wrote: > Which is the reason I think that ma

Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates

> On Feb 10, 2017, at 11:38 AM, Ryan Sleevi wrote: > > On Fri, Feb 10, 2017 at 8:19 AM, phill...@comodo.com > > wrote: > > Unfortunately, the flaw in your argument starts here, and unfortunately

Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates: User input

> On Feb 10, 2017, at 5:36 AM, Gervase Markham via Public > wrote: > > On 10/02/17 10:32, Christian Heutger wrote: >> I don’t talk about the effort of replacing a certificate. I talk >> about the driver behind limiting the lifetime and what would and >> primarly (as it’s

Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates

> On Feb 10, 2017, at 10:39 AM, Ryan Sleevi via Public > wrote: > > > > On Fri, Feb 10, 2017 at 7:17 AM, wrote: > There are two possible reasons for limiting the validity interval > > 1) To limit the length of CRLs (or equivalent). > 2) To enable

Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates

> On Feb 6, 2017, at 10:46 AM, Ryan Sleevi wrote: > > > > On Mon, Feb 6, 2017 at 7:34 AM, phill...@comodo.com > > wrote: > Ryan, > > Browsers have never agreed to anything ever. Browsers do

Re: [cabfpub] Draft CAA motion

If you want to be ultra strict, state that the zone does not have a DNSSEC validation chain to the ICANN root. There are some people using DNSSEC that does not chain to ICANN but not many these days. > On Nov 7, 2016, at 3:27 PM, Eric Mill via Public wrote: > > The line

Re: [cabfpub] SHA-1 ban via Mozilla policy

Done… One point I made there is that it is all very well telling the IoT developers what they should have done after the fact. But we are not telling people what they should be doing instead today. Probably we should be telling CAs to set up a set of roots specifically for embedded devices

Re: [cabfpub] CA key generation, storage, and FIPS

This likely dates from the time that NIST had decided to EOL the RSA algorithm and push everyone towards Elliptic Curves. Now that Quantum is looming as a more likely threat than a new factoring technique they are rowing back in the opposite direction. FIPS can be changed. I suggest that