Re: [cabfpub] Putting OIDs for the manufacturer of your kitchen sink into certificates

On Tue, May 1, 2018 at 6:33 PM, Tim Hollebeek wrote: > I wouldn't be so quick to throw cold water on additional transparency > mechanisms. Some are probably bad ideas, but there are almost certainly > good > ideas in there, too. Blockchain pixie dust does make some

Re: [cabfpub] Putting OIDs for the manufacturer of your kitchen sink into certificates

On Tue, May 1, 2018 at 5:45 PM, Tim Hollebeek wrote: > > > To make sure I understand: Are you proposing an explicit prohibition > against > > including any other extension or metadata within a Certificate > > Wow, no, certainly nothing so extreme. There is certainly

Re: [cabfpub] Putting OIDs for the manufacturer of your kitchen sink into certificates

On Tue, May 1, 2018 at 5:13 PM, Tim Hollebeek via Public < public@cabforum.org> wrote: > > > So, from time to time, approximately every month or two, someone comes up > with a brand new idea about some piece of information they would like to > require be present in every TLS digital certificate.

Re: [cabfpub] For Discussion: Code Signing Working Group Charter

Given that the id-kp-codeSigning EKU is a context-dependent, and given that only one software vendor has ever participated in such a WG, does it make sense to either scope the activities of the WG to a defined product subset - or to a defined EKU? Alternatively, should there be a minimum amount of

Re: [cabfpub] Ballot proposal - Update Section 8.4 for CA audit criteria

On Sun, Apr 15, 2018 at 2:18 AM, Dimitris Zacharopoulos via Public < public@cabforum.org> wrote: > > I am looking for two endorsers for the following ballot. > > Dimitris. > > *Ballot XXX - Update Section 8.4 for CA audit criteria* > > The following motion has been proposed by Dimitris

Re: [cabfpub] CABLint

There's been several duplicate names Are you talking about the 'cablint' portion of the AWSLabs certlint - https://github.com/awslabs/certlint ? That is what is referred to as 'cablint' on crt.sh Not to be confused with the GlobalSign certlint ( https://github.com/globalsign/certlint ) On Fri,

Re: [cabfpub] Applicability of BRs to Client Authentication certificates

On Thu, Apr 12, 2018 at 1:45 PM, Jeff Ward wrote: > If 7.1.2.3.f is ignored, it is less confusing, but there is still > potential ambiguity as to what ‘authenticating a server accessible through > the Internet’ means. It would be best if the BRs clearly specified the > technical

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

Note, the redline doc doesn't quite align with this ballot text - look for "Multi-Ffactor" in the doc :) On Wed, Mar 28, 2018 at 3:25 PM, Tim Hollebeek via Public < public@cabforum.org> wrote: > > > Ballot 221: Two-Factor Authentication and Password Improvements > > > > Purpose of Ballot: The

Re: [cabfpub] Browser implementation of cert requirements

On Fri, Mar 2, 2018 at 2:05 PM, Peter Bowen via Public wrote: > I’m working on updating cablint to make sure it has checks that match > browser checks. These will be INFO level items if they don’t align with > the BRs, but I think having them is valuable. > > I’m hoping

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

For sure. Apologies if that was worded confusing - we're hugely supportive of SRVNames, but solving the technical and policy issues around them is thorny and will require technical expertise, and I think most of the technical expertise of the Forum has been otherwise occupied by a number of more

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

On Fri, Mar 2, 2018 at 11:11 AM, Phillip wrote: > ??? I think it is fairly clear that with the necessary privs, I can > request a TCP/IP socket on any port (other than 0) and then bind a TLS > provider to it. > > > > The point I am making is that the fact the subscriber

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

On Fri, Mar 2, 2018 at 10:35 AM, Phillip via Public 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 delivery of an Internet service. The fact that we > use SSL on every port to

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

On Fri, Mar 2, 2018 at 10:08 AM, Paul Hoffman via Public < public@cabforum.org> wrote: > On Mar 1, 2018, at 7:51 AM, Ben Wilson via Public > wrote: > > > > Forwarding from Richard Wang: > > > > The current BRs say: > > > > Authorized Ports: One of the following ports: 80

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

This does not seem like a good idea. On Thu, Mar 1, 2018 at 8:05 AM, LeaderTelecom B.V. wrote: > It will be great to have daily / monthly limit for revocation for each > reseller. For example, daily limit 1% from all active certificates (minimum > 10 pcs). Monthly limit

Re: [cabfpub] BR Authorized Ports, add 8443

This was intentional and keeps the port numbers within the standard set of 'authorized' ports (in the notion of unix systems) - ports <1024 requiring privileged access. This is generally true (but not explicitly) on other systems. Given that WoSign/WoTrus's past issuance systems allowed

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

On Thu, Mar 1, 2018 at 10:34 AM, LeaderTelecom B.V. via Public < public@cabforum.org> wrote: > Dear Phillip, > > > I don’t understand the reasoning. > > If a cert is bad, it is bad and we need to revoke it. Period, end of > story. > > I afraid cases when it can affect clients. For example,

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

On Wed, Feb 28, 2018 at 3:46 PM, Geoff Keating wrote: > > > > On 28 Feb 2018, at 11:08 am, Ryan Sleevi wrote: > > > > > > > > On Wed, Feb 28, 2018 at 1:59 PM, Geoff Keating via Public < > public@cabforum.org> wrote: > >> This raises a question about the MDSP

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

On Wed, Feb 28, 2018 at 1:59 PM, Geoff Keating via Public < public@cabforum.org> wrote: > This raises a question about the MDSP policy and CAB Forum requirements. > Who is the subscriber in the reseller relation? We believe this to be the > key holder. However, the language is unclear. > > >

Re: [cabfpub] Review Notices

...@google.com>, "'CA/Browser Forum Public >> Discussion List'" <public@cabforum.org>, "'Kirk Hall'" >> <kirk.h...@entrustdatacard.com> >> Subject: Re: [cabfpub] Review Notices >> Message-ID: <074d01d39ec6$aa71e320$ff55a

Re: [cabfpub] Review Notices

> the change must be reviewed and understood as part of the whole, Kirk in > that sending out the whole document without redlining the specific changes > under review also makes review more difficult. I propose that we change > such that we keep the requirement to send out the full

Re: [cabfpub] Attendance of Interested Parties at Working Group meetings

Agreed. My specific concern is the notion of a 'vote-a-rama' of text changes to the Bylaws as the way of making progress. On Mon, Feb 5, 2018 at 12:43 PM, Tim Hollebeek wrote: > There is a bit of a “the perfect is the enemy of the good” thing going on > here, though.

Re: [cabfpub] Attendance of Interested Parties at Working Group meetings

On Mon, Feb 5, 2018 at 12:10 PM, Gervase Markham wrote: > On 05/02/18 17:05, Ryan Sleevi wrote: > > I appreciate the sentiment towards getting it out, but I also think it's > > worth highlighting that the failure to carefully review things - or to > > allow time for that -

Re: [cabfpub] Attendance of Interested Parties at Working Group meetings

On Mon, Feb 5, 2018 at 12:02 PM, Gervase Markham via Public < public@cabforum.org> wrote: > On 05/02/18 15:04, Tim Hollebeek via Public wrote: > > I expressed concern about running other WGs in parallel with VWG since I > > participate in all of them, but I can withdraw my objection with respect

Re: [cabfpub] Attendance of Interested Parties at Working Group meetings

On Fri, Feb 2, 2018 at 8:49 PM, Kirk Hall via Public wrote: > I previously agreed with Wayne that an all-day VWG meeting in Herndon, VA > on Tuesday, March 6 is a good idea – but we will have to push other WG > meetings to later, maybe Wednesday morning. *Does anyone object

Re: [cabfpub] Allocating Time for Review of All Domain Validation Methods at F2F Meeting

Note that Interested Parties cannot participate in meetings, whether F2F or Phone, unless explicitly invited, nor participate on the Wiki or Members mail list. On Fri, Feb 2, 2018 at 2:38 PM, James Burton via Public wrote: > That's an excellent idea. > > I would like to

Re: [cabfpub] Review Notices

Going back for several ballots Ballot 187 - https://cabforum.org/pipermail/public/2017-March/009989.html Ballot 189 - https://cabforum.org/pipermail/public/2017-April/010541.html Ballot 190 - https://cabforum.org/pipermail/public/2017-September/012103.html Ballot 191 -

Re: [cabfpub] Public Digest, Vol 69, Issue 118

Hi Kirk, As mentioned previously, these Review Notices don't comply with Section 2.4(e) of the Bylaws and our IPR Policy, Section 4.1 As per https://cabforum.org/wp-content/uploads/CABF-IPR-Policy-v.1.2.pdf Prior to the approval of a CAB Forum Draft Guideline as a CAB Forum Final Guideline or

Re: [cabfpub] Voting on Ballot 218

On Tue, Jan 30, 2018 at 9:37 AM, Kirk Hall via Public wrote: > Tim – your argument is “who knows if any certs have been misissued under > Method 1” could apply to all other methods. That’s not an argument that > there HAVE been misissued certs. We have been using the

Re: [cabfpub] Ballot 218 version 2: Remove validation methods #1 and #5

On Mon, Jan 29, 2018 at 3:16 PM, Mike Reilly (WDG) < mike.rei...@microsoft.com> wrote: > Ryan, I definitely agree there is a security risk with 3.2.2.4.1 and any > other validation method entirely dependent on a “trust us” model. I did > see the specifics Jeremy shared about the problems with

Re: [cabfpub] Ballot 218 version 2: Remove validation methods #1 and #5

; > > > *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Ryan > Sleevi via Public > *Sent:* Monday, January 29, 2018 12:42 PM > *To:* Mike Reilly (WDG) <mike.rei...@microsoft.com> > *Cc:* CA/Browser Forum Public Discussion List <public@cabforum.org> > &

Re: [cabfpub] Ballot 218 version 2: Remove validation methods #1 and #5

en data on how much members of our CA ecosystem >> rely on this method. >> >> >> >> I definitely believe 3.2.2.4.1 needs improvement or elimination for the >> security of customers. However, I would also like to see the risk >> mitigated in a deliberate vs

Re: [cabfpub] Ballot 218 version 2: Remove validation methods #1 and #5

o > the ecosystem. Seems we could agree on landing a vote immediately after > f2f #43. Thanks, Mike > > > > > > *From:* Public [mailto:public-boun...@cabforum.org] * On Behalf Of *Ryan > Sleevi via Public > *Sent:* Monday, January 29, 2018 7:21 AM > *To:* Bruce Morton &l

Re: [cabfpub] Ballot 218 version 2: Remove validation methods #1 and #5

Bruce, To date, Entrust has not provided any of the requested details about its use of 3.2.2.4.1, the prevalence, and the potential impact. Given the lack of responsiveness to the issues, which were raised over a month ago, and have made no substantial progress to addressing or understanding the

Re: [cabfpub] Draft Agenda for CA/Browser Teleconference of Jan. 25, 2018 at 11 am Eastern

On Fri, Jan 26, 2018 at 11:57 AM, Gervase Markham wrote: > On 26/01/18 16:22, Ryan Sleevi wrote: > > It's very important to note here - until the Chair has performed their > > duty, the Balloted documents are Draft Guidelines - and are not Final > > Guidelines or Final

Re: [cabfpub] Draft Agenda for CA/Browser Teleconference of Jan. 25, 2018 at 11 am Eastern

On Fri, Jan 26, 2018 at 10:24 AM, Gervase Markham <g...@mozilla.org> wrote: > Hi Ryan, > > On 23/01/18 02:03, Ryan Sleevi via Public wrote: > > As a possible item, or a consideration in advance, could you make sure > > the document status > > on https://c

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

I think the order of proposed operations is inverted - we should resolve this in IETF first, and then the CA/Browser Forum, much like the other Erratum. On Wed, Jan 24, 2018 at 4:45 PM, Corey Bonnell via Public < public@cabforum.org> wrote: > Hello, > > I reported an ambiguity in the CAA RFC

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

On Tue, Jan 23, 2018 at 5:10 PM, Ryan Sleevi wrote: > The issue Geoff highlighted only manifests to the extent you've already > performed the domain validation. > > If you use Methods 2 through 10 to perform the domain validation, then > you've already ensured that the domain

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

The issue Geoff highlighted only manifests to the extent you've already performed the domain validation. If you use Methods 2 through 10 to perform the domain validation, then you've already ensured that the domain is authorized to a minimal level. The only extent then to which 3.2.5 matters is

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

On Tue, Jan 23, 2018 at 2:36 PM, Bruce Morton via Public < public@cabforum.org> wrote: > > Finally we do 3.2.5, the authorization to issue check. We do not use the > information from WHOIS to perform this check. The reason is most > information is provided by the Registrant, so using it would be

Re: [cabfpub] Revocation as a domain owner

So we discussed #2 in the context of 213, and prior to that, had similar discussions relating to the context of redaction (and unredaction). I am not sure it's as cut and dry, in part, because of the challenges they present to subscribers. Imagine an entity like Google, which tries to very

Re: [cabfpub] Draft Agenda for CA/Browser Teleconference of Jan. 25, 2018 at 11 am Eastern

Hi Kirk, As a possible item, or a consideration in advance, could you make sure the document status on https://cabforum.org/baseline-requirements-documents/ is up to date? Your current status appears up to date, but our webpage seems a bit behind. Similarly, https://cabforum.org/bylaws/ is not

Re: [cabfpub] Critical Vulnerability Scenario

Hi James, I don't believe that's an issue the Forum itself can/would solve. I think the examples of MD5 and SHA-1 are examples of the best one can expect, but the issues here are largely not one of "Can CAs do something new", but of ecosystem considerations beyond the control of CAs. On Fri, Jan

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

On Fri, Jan 19, 2018 at 1:51 AM, Mads Egil Henriksveen via Public < public@cabforum.org> wrote: > Hi > > > > Buypass, Entrust Datacard and GlobalSign have been working on some text to > strengthen 3.2.2.4.1 instead of removing it - find the draft text below. > The draft was discussed in the

Re: [cabfpub] Applicant vs Applicant representative

On Mon, Jan 15, 2018 at 3:00 PM, Tim Hollebeek wrote: > Forking off to a new thread because it doesn't really need to block Ballot > 218, and as Ryan noted, the issue might exist elsewhere. > > I don't think 12 and 3 are completely parallel cases. > > In 3, you are

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

Hi Bruce, Can you share any further details about how you validate? I appreciate you believe it can be secure - I don't see anything in your message to actually show how that can be, and how that can be done in a way that can be independently assessed. Absent a workflow that can demonstrate how

Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

On Fri, Jan 12, 2018 at 7:11 PM, Ryan Sleevi wrote: > > > On Fri, Jan 12, 2018 at 2:07 PM, Tim Hollebeek > wrote: > >> >> >> I made some edits to the pull request: >> >> >> >> https://github.com/cabforum/documents/pull/79/commits/665e66 >>

Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

On Fri, Jan 12, 2018 at 2:07 PM, Tim Hollebeek wrote: > > > I made some edits to the pull request: > > > > https://github.com/cabforum/documents/pull/79/commits/ > 665e6688f95d305a9363a988c184232436b21263 > > > > Gerv might want to take a look at how I handled

Re: [cabfpub] Restrict certificate lifetime to domain registration period (if certificate expiry date is greater than domain registration)

On Fri, Jan 12, 2018 at 6:33 AM, James Burton wrote: > I will compile a spreadsheet of whois availability of all TLDs listed > here: https://www.iana.org/domains/root/db and get back to you with the > results. > Note: Even for those with WHOIS information available, WHOIS

Re: [cabfpub] Restrict certificate lifetime to domain registration period (if certificate expiry date is greater than domain registration)

The Baseline Requirements, Section 4.9.1.1, requires that the CA revoke if: 6. The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name

Re: [cabfpub] Analysis of individuals participating as Interested Parties

On Thu, Jan 11, 2018 at 1:18 PM, Kirk Hall via Public wrote: > > It’s possible we could solve this problem simply by changing the > definition of Participants in our IPRA to also include “individuals”, in > addition to entities. But that could apply to all “individuals” who

Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

So to make sure I've captured the discussion points of 3.2.2.4.1 for the "things that would be disruptive" For situations like GoDaddy (in which the CA is the Registrar as well) - or for situations like, say, Google Trust Services/Google, in which the CA is an Affiliate of the Registrar (I think;

Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

Daymion, Given the proposals so far, do you believe that the 'direct contact' method satisfies your concerns? The substantial difference here in the use of .2/.3 vs .1 is that you actually need to contact the customer for approval prior to issuance. This seems like it should be an

Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

I'm not sure that's a good approach - namely, "making reasonable improvements to #1" is, I think, a question of whether there are _other_ cases beyond the one identified (in which WHOIS is not available). Thus, I think framing it as 'reasonable improvements' may be implying there are other valid

Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

On Mon, Jan 8, 2018 at 6:05 AM, Dimitris Zacharopoulos wrote: > On 8/1/2018 11:24 πμ, Ryan Sleevi wrote: > > > > On Mon, Jan 8, 2018 at 4:11 AM, Dimitris Zacharopoulos > wrote: >> >> An example of pre-existing TLD adhering to this is .gov (in the US) - and >>

Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

On Mon, Jan 8, 2018 at 4:11 AM, Dimitris Zacharopoulos wrote: > > An example of pre-existing TLD adhering to this is .gov (in the US) - and > I'm guessing you know of one or more ccTLDs that also fit into this > category? > > The advantage being is that this permits non-gTLDs

Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

On Mon, Jan 8, 2018 at 2:45 AM, Dimitris Zacharopoulos via Public < public@cabforum.org> wrote: > On 5/1/2018 6:31 μμ, Rich Smith wrote: > > *From:* Public [mailto:public-boun...@cabforum.org > ] *On Behalf Of *Dimitris Zacharopoulos via > Public > *Sent:* Friday,

Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

I agree with Rich here. I don't think the proposed #1 would offer anything new here - #1 .1 simply refers to .2/.3 as equivalent, and #1 .2 is, as Rich points out, "Any other method" Notable on the issuance side is the other forms of validation are appropriate/usable - for example, technical

Re: [cabfpub] [EXTERNAL]Re: Ballot 218: Remove validation methods #1 and #5

[EXTERNAL]Re: [cabfpub] Ballot 218: Remove validation methods > #1 and #5 > > > > I agree with Ryan on this and stand by my endorsement of this ballot to > move forward. I’m not opposed to adding 3.2.2.4.1 back in if it can be > made much more secure and brought up to equivale

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

This does not resolve the issues mentioned. On Thu, Jan 4, 2018 at 7:47 AM, Mads Egil Henriksveen via Public < public@cabforum.org> wrote: > Removing method 1 is not the only way to solve this ambiguity, it could > also be solved by changing the language of 3.2.2.4.1 into something like > this

Re: [cabfpub] [EXTERNAL]Re: Verification of Domain Contact and Domain Authorization Document

at > need to be eliminated, but using that to tar the entire industry with a > broad brush is misleading in the extreme. > > > > -Tim > > > > *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Ryan > Sleevi via Public > *Sent:* Wednesday, January 3,

Re: [cabfpub] [EXTERNAL]Re: Verification of Domain Contact and Domain Authorization Document

Given that CAs have competing interests - namely, to sell certificates first and foremost, while at the same time not doing anything too egregious to get noticed and thus distrusted - I don't think it's reasonable, particularly given the economic incentives and industrial behaviour, to suggest

Re: [cabfpub] Ballot 218: Remove validation methods #1 and #5

Hi Kirk, We had two endorsers for the discussion. As I mentioned, there's nothing inherent in needing to direct this to VWG. As DigiCert has pointed out, there are CAs today that are doing validations that are patently insecure. While we can understand and appreciate that some members may wish

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

Given the impact of this, while I don't suggest that the VWG shouldn't take this up, I also don't think that should be reason not to continue the discussion on the public list. While I understand that Mads and Adriano have suggested they see value in 3.2.2.4.1, I do not think there's a

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

Adriano, Do you have an example of how you believe 3.2.2.4.1 can be used correctly? Specifically, it does not describe the process for validating that the Applicant is the Domain Contact with the Registrar - this isn't equivalent to using WHOIS. Here's just one scenario: - I ("Ryan Sleevi")

Re: [cabfpub] A question about BR Section 6.3.2

There is no requirement in the CA/Browser Forum at present to require regular key rotation, nor is there a way for that to be verifiably implemented across all CAs, as any subscriber can present a preexisting keypair to another CA. So no. The limit is to the lifetime of the certificate and the

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

On Tue, Dec 19, 2017 at 4:30 PM, Jeremy Rowley via Public < public@cabforum.org> wrote: > > I’m looking to remove/fix both of these methods as both these methods lack > the necessary controls to ensure that the verification ties to the domain > holder. These methods probably should have been

Re: [cabfpub] Ballot 217: Sunset RFC 2527

On Thu, Dec 7, 2017 at 11:52 AM, Ryan Sleevi wrote: > *Ballot 217: Sunset RFC 2527* > Google votes YES ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public

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

Google would be happy to co-sponsor this ballot if Kirk is withdrawing sponsorship. As noted, we believe the discussion of "minor edits" should be treated as separate, and does not need to be coupled with this otherwise beneficial change to process. On Mon, Dec 11, 2017 at 2:22 PM, Kirk Hall via

Re: [cabfpub] [EXTERNAL]Re: Ballot XXX: Update Discussion Period

ll scratching my head as to why it takes 7 days to verify a > spelling correction. > > > > -Tim > > > > *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Ryan > Sleevi via Public > *Sent:* Monday, December 11, 2017 12:07 PM > *To:* Virginia F

Re: [cabfpub] [EXTERNAL]Re: Ballot XXX: Update Discussion Period

On Mon, Dec 11, 2017 at 2:01 PM, Virginia Fournier via Public < public@cabforum.org> wrote: > > Further, I would encourage those proposing the "Editorial Language" to do > so in a separate ballot. I think we'd be reasonably confident to say that > this is not a problem being introduced by this

Re: [cabfpub] Draft Agenda CA/Browser Forum teleconference Thursday, Dec. 14, 2017 at 12:00 noon Eastern Time

Hi Kirk, By my notes, we have two ballots in the discussion period: - Ballot 216 - https://cabforum.org/pipermail/public/2017-December/012552.html (Review Dec 7 - Dec 14, voting Dec 14 - Dec 21) - Ballot 217 - https://cabforum.org/pipermail/public/2017-December/012553.html (Review Dec 7 - Dec 14,

Re: [cabfpub] [EXTERNAL]Re: Ballot XXX: Update Discussion Period

On Mon, Dec 11, 2017 at 11:37 AM, Dimitris Zacharopoulos wrote: > > Perhaps I misunderstood Kirk's original intent so please correct me if I'm > wrong. > I certainly understood Kirk's proposal to be about the discussion period, since it's specifically requested to be included

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

Hi Eric, I really appreciate you raising this point. I, too, am torn about this issue, and have been on the record expressing concerns going back for several years. To the extent the CA/Browser Forum serves to facilitate open communication between CAs and the Root Stores they participate in,

Re: [cabfpub] [EXTERNAL]Re: Ballot XXX: Update Discussion Period

Kirk, Dimitris, Could you explain how you imagine this process working? I think it's presently underspecified, highlighting Gerv's concerns. Here's just a small sample of realistic problems that would emerge: 1) At what point can such Editorial Changes be proposed? During discussion or during

Re: [cabfpub] Creating an open CA regime for telephone number "possession"

I'm not sure the Forum would be appropriate for that discussion - it certainly seems like the participants in STIR are best placed to articulate those needs - particularly given both the scope and participation of the members. My reply is meant to suggest that a distributed PKI is not, in and of

Re: [cabfpub] Creating an open CA regime for telephone number "possession"

On Fri, Dec 8, 2017 at 1:58 PM, Tony Rutkowski via Public < public@cabforum.org> wrote: > This is a stark contrast to the CA/B Forum > and its members - who arguably should > constitute this Governing Authority. Indeed, > from a policy perspective, one might ask why > there is only one Governing

Re: [cabfpub] Ballot XXX: Update Discussion Period

I can't recall that having happened. Do you recall specifics? On Fri, Dec 8, 2017 at 10:38 AM, Kirk Hall via Public wrote: > In the past, we have let ballot authors correct typos - such as > "certificaet" to "certificate". Would that no longer be allowed (meaning, > would

[cabfpub] Ballot 217: Sunset RFC 2527

*Ballot 217: Sunset RFC 2527* Purpose of Ballot: The Baseline Requirements and Extended Validation Guidelines require that CA's disclosures of the Certificate Policy and/or Certification Practice Statements include all of the material required by either RFC 2527 or RFC 3647 and structured in

Re: [cabfpub] [EXTERNAL]Re: Ballot XXX: Update Discussion Period Process

I do not believe such a phrase exists. As shown in past conversations, as substantive issues can be introduced even by the most minor of changes (recall the discussion of and vs and/or), and significantly alter both intent and execution, it's best to avoid that matter, or limit it to precise

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

Do you have a more concrete proposal for how that would look that addresses the issues that have been repeatedly raised over the years with such proposals? As we've seen in past conversations, including Ballot 190, both typographical and numbering corrections have had profound normative impact.

Re: [cabfpub] Pre-ballot: Ballot discussion ends when discussion ends, and not before

Right, I'm totally in line with the "Send it when it's ready" - but I'm concerned about the last minute changes -> force to a vote approach. It has the downside of changing what is, today, effectively 14 days review - since review can start during the discussion phase, ideally feedback can be

Re: [cabfpub] Pre-ballot: Ballot discussion ends when discussion ends, and not before

There have been more cases of bugs being introduced through changes than there have been of typographical errors. There's also been the repeated suggestion to "let it pass, and fix it afterwards" - which has also shown to be a regular poison pill for discussion and deferring solving real problems.

Re: [cabfpub] Pre-ballot: Ballot discussion ends when discussion ends, and not before

On Tue, Dec 5, 2017 at 2:41 PM, Tim Hollebeek via Public < public@cabforum.org> wrote: > > > Now that I have a bit more time, I’d like to propose a ballot that we > discussed with Gerv after the recent CAA voting snafu. The current bylaws > require the proposer to predict in advance how long the

Re: [cabfpub] [EXTERNAL]Re: Obtaining an EV cert for phishing

You are correct that 11.2.2(4)(A) does not require that, because 11.2.2(4) is limited to a specific type of subject, rather than corporate or government identities (11.2.2(1) and (3), and 11.2.2.(4), respectively). This is not surprising, as corporate legal persons do not themselves constitute

Re: [cabfpub] [EXTERNAL]Re: Obtaining an EV cert for phishing

> > > > To be fair, I was grossly simplifying the argument that it is: > > a) A crime to mislead a QGIS, QIIS, or QTIS within either the Jurisdiction > of Incorporation or the Place of Business (as Ben and Kirk suggested) > > b) A crime to use cert for 'evil' purposes, a

Re: [cabfpub] [EXTERNAL]Re: Obtaining an EV cert for phishing

y, but I thought it worth pointing out that the argument > that it'd be a crime to commit crime, is somewhat of a flawed tautology, > and by no means a way to conclude we'd prevent crime by criminalizing crime. > > > > On Tue, Nov 28, 2017 at 1:35 PM, Christian Heutger via Publ

Re: [cabfpub] Obtaining an EV cert for phishing

> to skip steps now, you would also deprive yourself of opportunities to hunt > down criminals. > > > > *Von: *Public <public-boun...@cabforum.org> im Auftrag von Ryan Sleevi > via Public <public@cabforum.org> > *Antworten an: *Ryan Sleevi <sle...@google.c

Re: [cabfpub] Obtaining an EV cert for phishing

Just to square these comments: Kirk's position was that EV certificates provide a way of tracking those who'd commit crime online because they have to disclose identity. Gerv and James pointed out that the identity information is only as useful as it is vetted, and there's scenarios where the

Re: [cabfpub] Ballot 184 - SRVnames

On Wed, Nov 15, 2017 at 2:49 PM, Gervase Markham wrote: > On 15/11/17 11:34, Ryan Sleevi wrote: > > Another option is to introduce some further signal to indicate that > > 'this' SRVName is safe to trust. This was the proposal I sketched out > > for you. > > Yes, I understand.

Re: [cabfpub] Ballot 184 - SRVnames

On Wed, Nov 15, 2017 at 2:26 PM, Gervase Markham wrote: > On 15/11/17 10:00, Ryan Sleevi wrote: > > Could you clarify what you view "enabling SRVNames" as? > > > > - Browsers/client software: In supporting them > > - The CA/Browser Forum: In dictating validation rules > > This

Re: [cabfpub] Ballot 184 - SRVnames

On Wed, Nov 15, 2017 at 12:55 PM, Peter Bowen wrote: > > > > On Nov 15, 2017, at 9:46 AM, Gervase Markham via Public < > public@cabforum.org> wrote: > > > > On 15/11/17 09:38, Ryan Sleevi wrote: > >> I gave an option immediately preceding the text you snipped, along with > >> the

Re: [cabfpub] Ballot 184 - SRVnames

On Tue, Nov 14, 2017 at 8:32 PM, Gervase Markham wrote: > On 27/10/17 09:42, Ryan Sleevi wrote: > > In any event, that at least hopefully captures the challenge, and why > > the 'simple' solution is likely not as simple as it appears. > > So what's the solution? Is there any

Re: [cabfpub] New RFC on CT Domain Label Redaction

I can understand the sentiment, but in the spirit of ensuring we install screws with screwdrivers and nails with hammers, rather than the other way around, it's worth noting that alternative methods of providing that degree of transparency exist, and in a way that can preserve much more of the

Re: [cabfpub] DV issuance for next-generation onion services

On Mon, Nov 6, 2017 at 8:56 AM, Fotis Loukos wrote: > > > > > In the classic WebPKI case, this is the same thing. > > > > > > I would not say that's a fair conclusion - in the Web PKI case, as > > permitted by the BRs, the entity in control of the content may be > > different

Re: [cabfpub] DV issuance for next-generation onion services

On Sun, Nov 5, 2017 at 9:53 AM, Fotis Loukos via Public wrote: > On 03/11/2017 07:08 μμ, Seth David Schoen via Public wrote: > > Peter Bowen writes: > > > >> I’m honestly not a big fan of being limited to these three methods — > they all are methods which have be completed

Re: [cabfpub] CT Policy moving to a new repository

That's probably better asked on the Chromium ct-policy list - ct-pol...@chromium.org The current Chrome implementation is based on rounded down month calculation, not days. In this case, if 825 days exceeds 27 months, then at present, it would require 4 SCTs, not 3. On Wed, Nov 1, 2017 at 7:19

Re: [cabfpub] Ballot 184 - SRVnames

On Thu, Oct 19, 2017 at 11:25 AM, Gervase Markham via Public < public@cabforum.org> wrote: > On 19/10/17 15:44, Jeremy Rowley wrote: > > This seems to indicate SRV restrictions are something new compared to > domain > > name constraints. I suppose it's largely up to UA's implementing the RFC > at

Re: [cabfpub] Limitation of Liability and Indemnification

> others before Enron sunk them. An insurer is required to back their > assessment of risk with actual dollars. > > > > Nothing gives perfect security but insurance is a tool we need to learn > how to use as an industry. > > > > > > *From:* Public [mailto:pu

Re: [cabfpub] Ballot 208 - dnQualifiers

Does that mean you disagree with my analysis of dnQualifier? The matter of serialNumber has already been addressed during past discussion. Notably, EV certificates are also DV certificates (in as much as no conflicts are permitted), and 9.2.6 of the EV guidelines defines serialNumber as

Re: [cabfpub] Limitation of Liability and Indemnification

On Mon, Oct 23, 2017 at 10:54 AM, Gervase Markham wrote: > On 23/10/17 14:55, Ryan Sleevi wrote: > > I don't believe this is correct or supported by fact, Gerv, nor > > supported by the limits of liability if you review CA's CP/CPS. > > I'm not sure what you mean. If you mean

<    1   2   3   4   5   6   7   8   9   >