Re: [cabfpub] [Ext] .well-known and re-directs

I think that I broadly agree with Ryan on this but with possibly different argument. For me, the key issue is whether the validation mechanism provides evidence that the request comes from the intended party. The burden of proof for any validation mechanism is on the proposer. For HTTP

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

Well if you think trying to toss out a vote on an absurd technicality to be ‘the spirit of comity, respect, and productive contribution’. From: Ryan Sleevi [mailto:sle...@google.com] Sent: Tuesday, April 18, 2017 11:33 AM To: phill...@comodo.com Cc: CA/Browser Forum Public Discussion

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

As I proposed earlier, can we amend this so that instead of saying: "CAs MUST process the issue, issuewild, and iodef property tags as specified in RFC 6844, although they are not required to act on the contents of the iodef property tag." We say "CAs MUST process the issue, issuewild, and

Re: [cabfpub] Ballot 195: CAA Fixup

I have just submitted a (very) full errata as promised: https://www.rfc-editor.org/errata_search.php?eid=4988 I would like to propose that the resubmission state RFC 6844 (as amended by errata 4988). From: Public

Re: [cabfpub] Ballot 194 – Effective Date of Ballot 193 Provisions

I have just submitted a (very) full errata as promised: https://www.rfc-editor.org/errata_search.php?eid=4988 I would like to propose that the resubmission state RFC 6844 (as amended by errata 4988). -Original Message- From: Public [mailto:public-boun...@cabforum.org] On Behalf Of

Re: [cabfpub] CAA Fixup ballot draft

I would like to hold off till thursday when LAMPS meets and we can hopefully get closure on the tree walking issue and get to say RFC6844 as modified by erratum X. > On Mar 28, 2017, at 8:15 AM, Gervase Markham via Public > wrote: > > > Hi everyone, > > Here's a

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

Lets hold off on a followup ballot until after I can talk to the IETF Security ADs in Chicago at the end of the month. I would like us to decide exactly what handling we want for CNAME and DNAME and ensure the spec is completely clear and unambiguous. As to what the handling should be, I

Re: [cabfpub] Certificate lifetimes: end state or trajectory?

From: Gervase Markham [mailto:g...@mozilla.org] > On 03/03/17 17:25, Phillip Hallam-Baker wrote: > > But when we get into discussions, the security reason for doing it is > > so that 'bad certs' are valid for shorter times. Whether you like it > > or not, that is a validity argument by

Re: [cabfpub] Certificate lifetimes: end state or trajectory?

> From: Gervase Markham [mailto:g...@mozilla.org] > Hi Philip, > > On 03/03/17 16:14, Phillip Hallam-Baker wrote: > > Going from 2 years to 1 or even 90 days makes no significant > > difference to security in my view. The only way to make a significant > > difference is to take the

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

On the question of where we should discuss this, on this type of issue, I would expect the views that the IETF would be interested in hearing from are * Those people with deployment experience. * The industry planning to deploy. Given where we are, I would expect the discussion here to be

Re: [cabfpub] SHA-1 Collision Found

> On Feb 23, 2017, at 10:40 PM, Ryan Sleevi wrote: > > > > On Thu, Feb 23, 2017 at 7:04 PM, phill...@comodo.com > > wrote: > If we are to lead, how about doing the obvious and setting a date

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

> On Feb 10, 2017, at 9:53 AM, Ryan Sleevi wrote: > > > On Fri, Feb 10, 2017 at 9:30 AM, phill...@comodo.com > > wrote: > So what are these other reasons that I am ignoring? > > From