[cabfpub] Leaving CSS

As of 1st January 2019, I will no longer be an employee of CSS/Comodo Group Inc. and will therefore be stepping down as CSS representative to CABForum. PHB ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Servercert-wg] [Ext] Voting Begins: SC13 version 5: CAA Contact Property and Associated E-mail Validation Methods

I was asked if I would be the expert when 6844 was in last call. I agreed. I thought I was the expert until it turned out it was never recorded. Since there is no code space shortage in CAA (by intent), the only real function an expert really needs perform is to point out if there is an

Re: [cabfpub] [Servercert-wg] Voting Begins: SC13 version 5: CAA Contact Property and Associated E-mail Validation Methods

CSS votes Yes on ballot SC13. Phill On Mon, Dec 17, 2018 at 4:55 PM Tim Hollebeek via Servercert-wg wrote: Ballot SC13: CAA Contact Property and Associated E-mail Validation Methods Purpose of Ballot: Increasingly, contact information is not available in WHOIS due to concerns about

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

CSS votes yes on Ballot SC3 version 2. From: Public On Behalf Of Mike Reilly (GRC) via Public Sent: Wednesday, August 15, 2018 11:05 AM To: Tim Hollebeek ; CA/B Forum Server Certificate WG Public Discussion List ; CA/Browser Forum Public Discussion List Subject: Re: [cabfpub] Voting

Re: [cabfpub] Membership Application of Sony

Given that this is the first outing for this set of rules, I think it is important to bear in mind the ultimate objective rather than the rules we only just created. That does not mean breaking the rules but we should be prepared to change them if needed. So rather than asking if Sony’s

Re: [cabfpub] Voting Begins: Ballot 224: WHOIS and RDAP

Comodo Group Inc. votes Yes on ballot 224. [I believe we signed up as Comodo Group Inc. Comodo Security Solutions is a wholly owned subsidiary of CGI which is the entity that I am employed by and report through] From: Public On Behalf Of Tim Hollebeek via

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

We seem to have a terminology issue here. What is a server? This is obvious in HTTP but far from obvious in the context of email because there is an inbound and an outbound ‘server’ and it acts as a client and a server at different times. I agree that certificates used to authenticate Mail

Re: [cabfpub] Ballot 221 v3: Two-Factor Authentication and Password Improvements

The NIST guidelines are based on solid evidence showing that forcing people to change their passwords is counterproductive. There is no evidence suggesting that it actually improves security and plenty of reason to believe that it encourages practices that make matters worse. But that said,

Re: [cabfpub] Voting ends tomorrow on Ballot 223 v2 (Update BR Section 8.4 for CA audit criteria)

Comodo Group Inc, votes Yes. From: Public On Behalf Of Kirk Hall via Public Sent: Monday, May 14, 2018 11:20 AM To: CA/Browser Forum Public Discussion List Subject: [cabfpub] Voting ends tomorrow on Ballot 223 v2 (Update BR Section 8.4 for

[cabfpub] CA Contact info, etc.

So at the exact minute this topic started, I received a request to review this document: https://tools.ietf.org/html/draft-ietf-uta-smtp-tlsrpt-17 It is essentially the same problem in a slightly different domain. This is targeted at ISPs managing mail servers. But any technology involving certs

Re: [cabfpub] [Ext] BR Authorized Ports, add 8443

From: Ryan Sleevi [mailto:sle...@google.com] Sent: Friday, March 2, 2018 11:22 AM To: Phillip Cc: CA/Browser Forum Public Discussion List ; Paul Hoffman ; Ben Wilson Subject: Re: [cabfpub] [Ext] BR

Re: [cabfpub] [Ext] BR Authorized Ports, add 8443

xt] BR Authorized Ports, add 8443 On Fri, Mar 2, 2018 at 10:35 AM, Phillip via Public <public@cabforum.org <mailto:public@cabforum.org> > wrote: To clarify what Paul said, We need to distinguish between the use of a port for certificate validation and the use of a port for de

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

I have proposed this as an AOB topic for LAMPS. On the wider problem, please remember I do not work for ComodoCA and have no more information on this than anyone else. I do find some aspects of the situation troubling though not necessarily the ones others are finding troubling. That a

Re: [cabfpub] [Ext] BR Authorized Ports, add 8443

To clarify what Paul said, We need to distinguish between the use of a port for certificate validation and the use of a port for delivery of an Internet service. The fact that we use SSL on every port to provide a service does not mean that we should allow that use for validation. I do think we

Re: [cabfpub] BR Authorized Ports, add 8443

Service Name and Transport Protocol Port Number Registry https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml Speedguide has no authority and I for one had never heard of it. IANA is the source. IF we were to consider an alternative port then it

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

From: Ryan Sleevi [mailto:sle...@google.com] Sent: Thursday, March 1, 2018 10:41 AM To: LeaderTelecom B.V. ; CA/Browser Forum Public Discussion List Cc: Phillip Subject: Re: [cabfpub] [Ticket#2018022801003595] How do you

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

I don’t understand the reasoning. If a cert is bad, it is bad and we need to revoke it. Period, end of story. This looks like punishing resellers for behavior we want to encourage. From: Public [mailto:public-boun...@cabforum.org] On Behalf Of LeaderTelecom B.V. via Public Sent:

Re: [cabfpub] [EXTERNAL] Change of Mozilla representative

Gerv, You have been involved in the CABForum since that first meeting in NYC when we came together to discuss how to fix the crisis we faced in Web security then. I greatly appreciate your contribution to this work and will be thinking about you in the days ahead. Phill > -Original

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

Actually it is the opposite as getting the errata into that state is a defacto precondition to getting the BR modified. From: Corey Bonnell [mailto:cbonn...@trustwave.com] Sent: Friday, January 26, 2018 12:23 PM To: phill...@comodo.com; Ryan Sleevi ; CA/Browser Forum

Re: [cabfpub] Ballot 217: Sunset RFC 2527

Comodo Security Solutions votes Yes to Ballot 217 From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Doug Beattie via Public Sent: Friday, December 15, 2017 1:55 PM To: Ryan Sleevi ; CA/Browser Forum Public Discussion List Subject: Re:

Re: [cabfpub] Ballot 216: Update Discussion Period Process

Comodo Security Solutions votes Yes to Ballot 216 From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham via Public Sent: Tuesday, December 12, 2017 1:51 PM To: CABFPub > Subject: [cabfpub] Ballot 216: Update

Re: [cabfpub] Browser eligibility in CABF in general (and Comodo specifically)

I am not going to respond to issues raised individually. Nor am I about to divulge future product plans. However, I do think it should be obvious that Comodo Group Inc. could hardly have engaged in a trust root curation process while being the largest issuing CA. That would have constituted

Re: [cabfpub] CAA working group description

ecify fail-closed because that’s the only fully secure approach, and the IETF can’t specify adoption of their standards in the Baseline Requirements. On 5 Oct 2017, at 11:09 am, Phillip via Public <public@cabforum.org <mailto:public@cabforum.org> > wrote: I can well imagine

Re: [cabfpub] Limitation of Liability and Indemnification

Has anyone ever established a loss as a result of a mis-issued certificate? The point of insurance is that an insurer is like an auditor except that they have skin in the game. An auditor rarely suffers as a result of a negligent audit. Arthur Andersen survived Sunbeam, DeLorean and numerous

Re: [cabfpub] CAA working group description

I am thinking the decision process needs to be three valued. * Success * Unknown * DNSSEC Fail Without DNSSEC, it is not going to be possible to distinguish ordinary network failures from attacks. I don’t see a problem with an incentive to deploy DNSSEC so long as

Re: [cabfpub] CAA working group description

I can well imagine a possibility where the IETF WG might leave some parts of the specification specified in less detail than would be desirable for compliance purposes and thus make work in CABForum desirable. But lets cross that bridge if we come to it. What somewhat worries me is a

Re: [cabfpub] CAA working group description

I am interested in working on this (obviously). My only concern is that we need to make sure that issues are being raised in the right forum which means that either we all raise them in the IETF LAMPS working group or we work out some formalized method for conveying issues from one into the

Re: [cabfpub] Voting has started on Ballot 214 - CAA Discovery CNAME Errata

Comodo votes YES From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Kirk Hall via Public Sent: Wednesday, September 20, 2017 8:56 PM To: CA/Browser Forum Public Discussion List Subject: Re: [cabfpub] Voting has started on Ballot 214 - CAA Discovery CNAME

Re: [cabfpub] Voting has started on Ballot 21 - CAA Discovery CNAME Errata

Damn, I was off mail today due to unforeseen circumstances. Technically, I was the proposer of the motion, not that it matters. Josh posted it. From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Kirk Hall via Public Sent: Wednesday, September 20, 2017 8:55 PM To:

[cabfpub] FW: Proposal: CAA Discovery

Comodo proposes the following motion, looking for a seconder. Proposal: Modify the Baseline Requirements v1.4.9 as follows: 3.2.2.8. CAA Records Change: As part of the issuance process, the CA MUST check for a CAA record for each dNSName in the subjectAltName extension of the

Re: [cabfpub] FW: [Errata Held for Document Update] RFC6844 (5065)

ion of the certificate to be issued, > according to the procedure in RFC 6844 as amended by Errata 5065 (Appendix > A). If the CA issues, they MUST do so within the TTL of the CAA record, or 8 > hours, whichever is greater. On Wed, Aug 23, 2017 at 10:12 AM, Phillip via Public <pu

Re: [cabfpub] FW: [Errata Held for Document Update] RFC6844 (5065)

n the process of implementing support for CAA? Do we implement the CAA processing rules according to this errata or do we need to comply with the current version of RFC6844? Regards Mads -Original Message- From: Public [mailto:public-boun...@cabforum.org <mailto:public-boun...@cab

[cabfpub] FW: [Errata Held for Document Update] RFC6844 (5065)

We have held for document update! -Original Message- From: RFC Errata System [mailto:rfc-edi...@rfc-editor.org] Sent: Tuesday, August 22, 2017 12:58 PM To: phill...@comodo.com; phill...@comodo.com; rob.stradl...@comodo.com Cc: e...@rtfm.com; i...@ietf.org; p...@ietf.org;

Re: [cabfpub] Two CAA questions

One of the main things that CAs do as part of their business is precisely helping the customer configure their server to use the product. This is only one of dozens of misconfiguration issues that arise. DNSSEC is complex enough in itself. One of the side effects of DNSSEC is that it will

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

hallambaker.com> > wrote: > > > > On Tue, Jun 13, 2017 at 11:26 AM, Paul Hoffman via Public > <public@cabforum.org> wrote: >> >> On Jun 13, 2017, at 8:14 AM, Gervase Markham via Public >> <public@cabforum.org> wrote: >> > >> > On

Re: [cabfpub] "[UNVERIFIED SENDER]Re: no CAA authorizations -- RFC 6844

izations -- RFC 6844 On 22/06/17 21:13, Phillip via Public wrote: > I am pretty sure that Peter and myself only diverged in our > interpretation of the original proposal from Iida. Phill, you wrote earlier: "It is my understanding that the text as drafted prohibits issue of a wildcard

Re: [cabfpub] "[UNVERIFIED SENDER]Re: no CAA authorizations -- RFC 6844

. From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Phillip via Public Sent: Thursday, June 22, 2017 4:13 PM To: 'Ryan Sleevi' <sle...@google.com>; 'Peter Bowen' <p...@amzn.com>; 'CA/Browser Forum Public Discussion List' <public@cabforum.org> Subject: Re: [cab

Re: [cabfpub] "[UNVERIFIED SENDER]Re: no CAA authorizations -- RFC 6844

wildcard domain. This makes it clear that issue property applies when a wildcard domain is processed unless there is an issuewild property. Thanks, Peter On Jun 22, 2017, at 11:46 AM, Phillip via Public <public@cabforum.org <mailto:public@cabforum.org> > wrote: It is my u

Re: [cabfpub] "[UNVERIFIED SENDER]Re: no CAA authorizations -- RFC 6844

That was the intended semantics. If only issue records were specified, they govern regular and wildcard. If any wildcard is specified, it has no effect for a non wildcard request but governs any wildcard request. Thus if the records are $ORIGIN example.com . CAA 0

Re: [cabfpub] "[UNVERIFIED SENDER]Re: no CAA authorizations -- RFC 6844

A record set, all issue properties MUST be ignored when processing a request for a domain that is a wildcard domain. This makes it clear that issue property applies when a wildcard domain is processed unless there is an issuewild property. Thanks, Peter On Jun 22, 2017, at 11:46

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

It is my understanding that the text as drafted prohibits issue of a wildcard certificate if the record set only contains issue records and issue of a non wildcard certificate if the record set only contains issuewild records. My reasoning is as follows: The relevant parts of the specification

[cabfpub] SHA-1 Update to S/MIME?

Did I hear Gerv mention that there is a plan to remove SHA-1 from the S/MIME? Sound difficult on my end. One of the major issues with S/MIME has been that there is no way to negotiate cipher suites in an async protocol. Would be nice if we could agree to support a common base for crypto beyond

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

Markham via Public <public@cabforum.org> wrote: > > On 13/06/17 15:33, Phillip via Public wrote: >> I do not see a good argument for including the text in the BR and a >> good reason not to. > > Well, you may not consider it a good argument, but the recommend

Re: [cabfpub] FW: [Technical Errata Reported] RFC6844 (5029)

List <public@cabforum.org>; 'Ryan Sleevi' <sle...@google.com> Cc: Phillip <phill...@comodo.com> Subject: Re: [cabfpub] FW: [Technical Errata Reported] RFC6844 (5029) On 06/06/17 16:13, Phillip via Public wrote: > My proposal is to amend the BR to read “RFC 6844 as amended by

Re: [cabfpub] FW: [Technical Errata Reported] RFC6844 (5029)

org> Cc: Phillip <phill...@comodo.com> Subject: Re: [cabfpub] FW: [Technical Errata Reported] RFC6844 (5029) On Tue, Jun 6, 2017 at 10:35 AM, Phillip via Public <public@cabforum.org <mailto:public@cabforum.org> > wrote: This is the update for the CAA errata as approved

Re: [cabfpub] Fixup ballot for CAA

ent from you on it. On Mon, Jun 5, 2017 at 12:04 PM, Phillip via Public <public@cabforum.org <mailto:public@cabforum.org> > wrote: Implementation of CAA turned up an issue to do with the recursive treatment of pointer records. An errata has been proposed to fix the specification to

Re: [cabfpub] Fixup ballot for CAA

unaddressed feedback submitted by Jacob Hoffman-Andrews regarding the correctness of that Errata. Has that been resolved now? I haven't seen any acknowledgement from you on it. On Mon, Jun 5, 2017 at 12:04 PM, Phillip via Public <public@cabforum.org <mailto:public@cabforum.org> > wrote

[cabfpub] Fixup ballot for CAA

Implementation of CAA turned up an issue to do with the recursive treatment of pointer records. An errata has been proposed to fix the specification to achieve the processing agreed to be desirable: https://www.rfc-editor.org/errata_search.php?eid=4992 I would like to propose a motion to fix