Re: [cabfpub] Ballot 204: Forbid DTPs from doing Domain/IP Ownership Validation

On Thu, Jul 6, 2017 at 11:43 AM, Doug Beattie via Public < public@cabforum.org> wrote: > Gerv, > > > > I realize I just missed the review period, but I wanted to ask a question > anyway. > > > > Regarding this statement: > > "The CA SHALL confirm that, as of the date the Certificate issues, the

Re: [cabfpub] [Ext] Updated Ballot 190 v3 dated June 30, 2017

Paul, Under "has more labels", "example.com" and "example.com.example.net" - example.com.example.net has more labels than the validated FQDN. This is where the term "Authorization Domain Name" is much more clearly worded, by describing that the ADN for an FQDN may be constructed by "The CA may

Re: [cabfpub] Pre-ballot for Ballot 190

On Thu, Jun 29, 2017 at 7:59 PM, Kirk Hall wrote: > I can only respond to two of your questions. > > > > As to your first question, a third level domain can be referred to as > “higher” than a second level domain, and so on: > >

Re: [cabfpub] Pre-ballot for Ballot 190

There is confusing language - which can be ambiguous - and then language that may be actively detrimental (that is, the plain reading is a normative change). Consider 3.2.2.4.1 as an example. It includes the following draft text: "Note: Once the FQDN has been validated using this method, the CA

Re: [cabfpub] Updating DTP definition

Kirk, Would you agree that your proposed wording introduces the issue that is avoided by the current wording, which is that a CA can easily misread this to suggest that, say, if the DTP is covered under the "WebTrust for CAs" audit, it need not necessarily be covered under the "WebTrust for CAs -

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

This is consistent with the deployed reality, so I similarly concur with Peter's view and believe that Phillip's understanding may be a misunderstanding of the text. Certainly, it would be a breaking change for deployments to adopt the proposed interpretation, and for that reason, would be very

Re: [cabfpub] Baseline Requirements "Certificate Policy" for the Issuance and Management of Publicly-Trusted Certificates

As it stands, http://www.webtrust.org/principles-and-criteria/docs/item83987.pdf and http://www.etsi.org/deliver/etsi_en/319400_319499/31941102/02.01.01_60/en_31941102v020101p.pdf both note "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" That is, the

Re: [cabfpub] Baseline Requirements "Certificate Policy" for the Issuance and Management of Publicly-Trusted Certificates

On Wed, Jun 21, 2017 at 8:23 AM, Gervase Markham wrote: > On 21/06/17 13:56, 陳立群 via Public wrote: > > *Baseline Requirements: *The Baseline Requirements for the Issuance and > > Management of Publicly-Trusted Certificates as > > published by the CA/Browser Forum and any

Re: [cabfpub] Baseline Requirements "Certificate Policy" for the Issuance and Management of Publicly-Trusted Certificates

Hi Li-Chun, On the basis of the bylaws, this should be conducted as a balloted change to correct. I'm sure there would be no objection to a ballot making this typographical fix :) With respect to what obligations or impact it has on CAs, you don't need to wait for a ballot to correct this when

Re: [cabfpub] Ballot 203: Formation of Network Security Working Group (v2)

Google votes ABSTAIN We remain concerned that the proposed "Expiration" is questionable with respect to the Bylaws as presently written. In one respect, this Ballot could be read as proposing a WG outside the protections and affordances of the Bylaws - thus calling into question members'

Re: [cabfpub] [EXTERNAL]Re: CA/Browser Face to Face Meeting 41 Agenda – Berlin

; I’d point out that over the years we have heard from many people and > organizations at our meetings. It’s been very useful. > > > > *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Peter > Bowen via Public > *Sent:* Tuesday, June 13, 2017 2:35 PM > *To:* CA/Brow

Re: [cabfpub] [EXTERNAL]Re: CA/Browser Face to Face Meeting 41 Agenda – Berlin

abforum.org> > *Cc:* Peter Bowen <p...@amzn.com> > *Subject:* Re: [cabfpub] [EXTERNAL]Re: CA/Browser Face to Face Meeting 41 > Agenda – Berlin > > > > > > On Jun 13, 2017, at 2:28 PM, Ryan Sleevi via Public <public@cabforum.org> > wrote: > > > >

Re: [cabfpub] [EXTERNAL]Re: CA/Browser Face to Face Meeting 41 Agenda – Berlin

On Tue, Jun 13, 2017 at 5:00 PM, Kirk Hall via Public wrote: > On your first question - some major enterprise users would like to present > their ideas and concerns about SSL certificate rules, changes, etc. from > their perspective, which I know the browsers have wanted

Re: [cabfpub] Send us you list of current problems with the Network Security Guidelines

On Tue, Jun 13, 2017 at 4:41 PM, Kirk Hall wrote: > I'm still uncertain what the logic is behind objections to collecting > NetSec comments from people (can be CAs, auditors, even browsers) in a > master list, as opposed to making people post their concerns

Re: [cabfpub] [EXTERNAL]Re: Send us you list of current problems with the Network Security Guidelines

Kirk, This is not helpful or productive. Should I take your response to mean that you do not wish to engage with or answer the question, which was hopefully both simple and clear, which was simply trying to understand why, given the problems, you would propose anonymity? Understanding your

Re: [cabfpub] [EXTERNAL]Re: Send us you list of current problems with the Network Security Guidelines

Hi Kirk, While I realize your reply was seeking for more clarification, I think it's important to note that you didn't actually engage with the question I asked. I'm hoping to ask again - could you go into detail why this would be beneficial for discussion? Thanks On Sat, Jun 10, 2017 at 12:54

Re: [cabfpub] Send us you list of current problems with the Network Security Guidelines

On Fri, Jun 9, 2017 at 4:34 PM, Kirk Hall via Public wrote: > Bruce and I will combine all suggestions received and report *anonymously* > to the whole group for a discussion in Berlin. > That seems pretty detrimental to discussion - that is, the anonymous aspect - unless

Re: [cabfpub] [EXTERNAL] 答复: Changing numbers of self-audited certificates

>From the browser perspective, our target is 100% audit, particularly around technical controls. Recognizing the practical limitations of that, we've been willing to go less. However, as a practical matter, the choice and application of the sampling, as currently practiced, does not align with

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

I believe you may have misunderstood my question. That said, it would be very useful if you could point to such a public message from the ADs. As an IETF veteran, I'm sure you understand this process, but for the sake of the members less engaged in such SDOs, there's two aspects here: 1)

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

On Tue, Jun 6, 2017 at 10:35 AM, Phillip via Public wrote: > This is the update for the CAA errata as approved by Jacob. Please review > in case there is another cut n' paste screw up and we can go to a ballot. > > Do I have a seconder? > Could you clarify what you're

Re: [cabfpub] [EXTERNAL]Re: Ballot 203: Formation of Network Security Working Group

On Mon, Jun 5, 2017 at 5:32 PM, Peter Bowen wrote: > > Is there a concern if the meeting is a “subgroup” or “committee” of the > full Forum and clearly states that such a meeting may not approve minutes > as Final, process applications to be Members, or deal with items sent to >

Re: [cabfpub] [EXTERNAL]Re: Ballot 203: Formation of Network Security Working Group

On Mon, Jun 5, 2017 at 5:07 PM, Kirk Hall wrote: > In (partial) response to Virginia's concern -- this is an "old style" > working group of the whole Forum (to work on an issue), and not a "new > style" working group under the Governance WG's definition. (I think

Re: [cabfpub] Ballot 203: Formation of Network Security Working Group

On Mon, Jun 5, 2017 at 4:49 PM, Gervase Markham wrote: > On 05/06/17 21:28, Ryan Sleevi wrote: > > If we actually have a working group, we can gather expressions of > > interest, perhaps even choose a chair, and the interested parties can > > start defining a

Re: [cabfpub] Ballot 203: Formation of Network Security Working Group

On Mon, Jun 5, 2017 at 4:23 PM, Gervase Markham wrote: > On 05/06/17 21:11, Peter Bowen wrote: > > What is the value of having a WG established by the F2F. The F2F can > discuss the topic all it wants with or without a WG charter. > > Well, it can, but the chances are that

Re: [cabfpub] Ballot 203: Formation of Network Security Working Group

On Mon, Jun 5, 2017 at 1:13 PM, Gervase Markham wrote: > Hi Ryan, > > On 05/06/17 15:14, Ryan Sleevi wrote: > > That seems a sort of broadly worded expiration, and one that would be > > hard to measure. > > Which half is hard to measure? The deliverables are fairly concrete,

Re: [cabfpub] Fixup ballot for CAA

I see. That doesn't sound like the normal IETF process, since decisions are made on the list, but I look forward to reading more about it, once more information is publicly available. On Mon, Jun 5, 2017 at 12:23 PM, Phillip wrote: > It was discussed in the LAMPS group at

Re: [cabfpub] Fixup ballot for CAA

It looks like there has been some 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 wrote: >

Re: [cabfpub] Ballot 203: Formation of Network Security Working Group

Gerv, That seems a sort of broadly worded expiration, and one that would be hard to measure. For example, if a single ratification fails, is the WG expired? If the WG never tries to ratify a proposal, does the WG expire? If the WG makes a single proposal - while others are still being worked on

Re: [cabfpub] Ballot 201 - .onion Revisions

Google votes YES ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Pre-Ballot: Underscore Characters in SANs

In order for otherName:srvNames to be permitted? Yeah. Peter had a draft ballot for that, and Jeremy continued that draft. Our (Google's) problem had been that it was coupled to this ballot, when they're really separate things. We (Google) are super-excited for SRVNames - it'll actually be a good

Re: [cabfpub] Pre-Ballot: Underscore Characters in SANs

We do On Thu, Jun 1, 2017 at 2:48 PM, Ben Wilson via Public wrote: > Let me word this another way. Who believes that an underscore character > cannot be the first character in an FQDN? > > -Original Message- > From: Public [mailto:public-boun...@cabforum.org] On

Re: [cabfpub] Pre-Ballot: Underscore Characters in SANs

You can only issue certificates for hostnames, so I'm not sure I understand the question On Thu, Jun 1, 2017 at 2:33 PM, Ben Wilson wrote: > Does this position have something to do with SRV names vs. host names? > > > > Thanks, > > > > Ben > > > > *From:* Ryan Sleevi

Re: [cabfpub] Pre-Ballot: Underscore Characters in SANs

Ben, I believe you're conflating host records with other forms of records. As TLS certificates only apply to host records, Peter's remarks are entirely appropriate and correct. As Chrome itself is working through security issues resulting from misapplication of the RFCs by underlying resolver

Re: [cabfpub] CAA Exceptions listed in Ballot 187

On Thu, May 25, 2017 at 11:43 AM, Doug Beattie via Public < public@cabforum.org> wrote: > > 3) CAA checking is optional if the CA or an Affiliate of the CA is the DNS > Operator (as defined in RFC 7719) of the domain's DNS. > > From RFC 7719: DNS operator: An entity responsible for running DNS >

Re: [cabfpub] Pre-Ballot 201 - .Onion Revisions

Apologies Ben, I somehow missed this message. Thanks for your hard work on doing this. Happy to endorse, with one request. - MOTION BEGINS - Part 1: The CA/Browser Forum, recognizing that Ballot 198 did not include a redline version against the current Final Maintenance Guidelines,

Re: [cabfpub] Draft Agenda for Thursday May 25 CABF Teleconference

Hi Kirk, I'd be interested if we could spend some time discussing l), if the members interested are able to make the call (Paul van Brouwershaven from GlobalSign if possible, Dimitris, Tim, Bruce). We spent time - both on the bug and the list - discussing OCSP Responder certificates and their

Re: [cabfpub] Preballot - Revised Ballot 190

How do you do _any_ of the validations without an Applicant, and how do you have an Applicant without a request - that was the core question. On Mon, May 22, 2017 at 4:46 AM, Geoff Keating wrote: > All the BRs say is that a request has to happen before a certificate is >

Re: [cabfpub] Preballot - Revised Ballot 190

On Fri, May 19, 2017 at 11:39 PM, Peter Bowen wrote: > > There is another way to look at it. Applicant is a defined term that is > basically a pronoun. It is reasonable to replace the capitalized > “Applicant” with a specific natural person or legal entity. So the 3.2 >

Re: [cabfpub] Preballot - Revised Ballot 190

On Fri, May 19, 2017 at 9:47 PM, Jeremy Rowley wrote: > “The certificate request MAY include all factual information about the > Applicant to be included in the Certificate, and such additional > information as is necessary for the CA to obtain from the Applicant in >

Re: [cabfpub] Preballot - Revised Ballot 190

On Fri, May 19, 2017 at 8:45 PM, Jeremy Rowley wrote: > A slightly different third interpretation: > > - Obtaining a partial request (under 4.2.1, the certificate request does > not contain all necessary information…) > How is the notion of "partial request"

Re: [cabfpub] Ballot 191 - Clarify Place of Business Information

nstitute a redlined version? > > > > *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Ryan > Sleevi via Public > *Sent:* Friday, May 19, 2017 6:53 AM > *To:* CA/Browser Forum Public Discussion List <public@cabforum.org> > *Cc:* Ryan Sleevi <sle...

Re: [cabfpub] Preballot - Revised Ballot 190

On Fri, May 19, 2017 at 7:52 PM, Peter Bowen wrote: > There is no reason a CA couldn’t pull public records based on info in CT > to help expedite things (for example identifying the company registration > number), but the validation still has to happen. You can’t finalize the >

Re: [cabfpub] Preballot - Revised Ballot 190

On Fri, May 19, 2017 at 7:48 PM, Geoff Keating wrote: > > On 19 May 2017, at 3:43 pm, Ryan Sleevi wrote: > > How does that fit with the quoted Section 4.1.2? > > "The certificate request MUST contain a request from, or on behalf of, > the Applicant for the

Re: [cabfpub] Preballot - Revised Ballot 190

On Fri, May 19, 2017 at 7:12 PM, Ben Wilson wrote: > With regard to timing and the sequence of events, I would think that it > shouldn’t matter too much as long as the steps comply with and meet the > Baseline Requirements. In other words, a CA should take steps to

Re: [cabfpub] Preballot - Revised Ballot 190

How does that fit with the quoted Section 4.1.2? "The certificate request MUST contain a request from, or on behalf of, the Applicant for the issuance of a Certificate, and a certification by, or on behalf of, the Applicant that all of the information contained therein is correct." 1) If there

Re: [cabfpub] Preballot - Revised Ballot 190

4 – CA completes any remaining validation steps and verifies that process > has not exceeded any applicable timeframes > > 5 – CA issues certificate > > > > *Ben Wilson, JD, CISA, CISSP* > > VP Compliance > > +1 801 701 9678 <(801)%20701-9678> > > >

Re: [cabfpub] Preballot - Revised Ballot 190

On Fri, May 19, 2017 at 6:00 PM, Peter Bowen wrote: > > Yes, it does. We know that CAs can generate keys on behalf of the > subscriber, so it is clear that a public key is not required. This means > that a CA could take the request for “issue a certificate to example.com”, > do

Re: [cabfpub] Preballot - Revised Ballot 190

On Fri, May 19, 2017 at 5:16 PM, Peter Bowen wrote: > > It was my intent and understanding that the 30 days had nothing to do with > 4.2.1 or 3.2.2.4’s reuse requirements or allowances. We wanted to limit > how long a validation could be in a “pending” state. Therefore we added a

Re: [cabfpub] Preballot - Revised Ballot 190

On Fri, May 19, 2017 at 10:27 AM, Peter Bowen wrote: > > The contention, from my view, is the definition of “data or document”. I > think that all agree that a "utility bill, bank statement, credit card > statement” provided by the customer in order for address verification is >

Re: [cabfpub] Preballot - Revised Ballot 190

On Fri, May 19, 2017 at 9:04 AM, Gervase Markham <g...@mozilla.org> wrote: > Hi Ryan, > > On 19/05/17 13:12, Ryan Sleevi via Public wrote: > > Luckily, this is an incorrect interpretation of what's required. It > > would only affect those domains affected by those cha

Re: [cabfpub] Ballot 191 - Clarify Place of Business Information

Thanks Bruce for providing this. It's unclear to me, in light of the discussions around 198 - .onion domains - whether this constitutes a proper ballot, since a redline version was not provided. That is, whether the --( )-- (deletion) __ __ (addition) constitute redlines or not. Assuming we

Re: [cabfpub] Preballot - Revised Ballot 190

On Fri, May 19, 2017 at 2:00 AM, Kirk Hall via Public wrote: > > As Gerv said a few weeks ago, requiring revalidation of all outstanding > domains every time there is an incremental improvement in domain validation > methods will turn out to be a tremendous disincentive to

Re: [cabfpub] Preballot - Revised Ballot 190

On Thu, May 18, 2017 at 10:13 AM, Gervase Markham <g...@mozilla.org> wrote: > On 17/05/17 17:40, Ryan Sleevi via Public wrote: > > As such, it's unclear what the intended outcome of this is. Is it meant > > to be binding on CAs? If so, we should look to be more exp

Re: [cabfpub] Preballot - Revised Ballot 190

On Thu, May 18, 2017 at 10:15 AM, Gervase Markham wrote: > On 17/05/17 18:29, Doug Beattie via Public wrote: > > 2) Set a date within the next 3-6 months for requiring only the 10 > > methods for issuance of all certificates > > I think the date for which "only 10 methods"

Re: [cabfpub] Preballot - Revised Ballot 190

On Thu, May 18, 2017 at 10:16 AM, Gervase Markham wrote: > On 17/05/17 19:33, Ryan Sleevi wrote: > > On Wed, May 17, 2017 at 2:23 PM, Gervase Markham > > wrote: > > What's the alternative proposal, given that many or most CAs

Re: [cabfpub] streetAddress

On Thu, May 18, 2017 at 2:25 AM, Adriano Santoni via Public < public@cabforum.org> wrote: > Here is an example: (please note: it's a *fake one*, generated via > an on-line fake address generator) > > O=ACME SA > STREET=38, Place Charles de Gaulle, 76600 Le Havre, France > L=Le Havre >

Re: [cabfpub] [EXTERNAL]Re: Preballot - Revised Ballot 190

Does that mean you'll be withdrawing the proposal to reuse data, which is a new provision? I hope you can understand the desire here to find an equitable balance that works for all parties. We're putting the ecosystem at risk due to some CAs poor security practices. Being transparent about that

Re: [cabfpub] Preballot - Revised Ballot 190

On Wed, May 17, 2017 at 6:23 PM, Kirk Hall via Public wrote: > +1 > +1 to what? Doug asked questions. ___ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Preballot - Revised Ballot 190

On Wed, May 17, 2017 at 4:46 PM, Doug Beattie wrote: > Rolling out a new extension and tying the value to the vetting level isn’t > trivial to implement in some of the products, unfortunately. DV is easy > because we verify the domain upon issuance, so those have

Re: [cabfpub] Preballot - Revised Ballot 190

On Wed, May 17, 2017 at 2:23 PM, Gervase Markham <g...@mozilla.org> wrote: > On 17/05/17 18:04, Ryan Sleevi via Public wrote: > > I totally appreciate that sentiment, but you realize one area of the > > concern and issues has been the proposal - made by Kirk, Gerv, and

Re: [cabfpub] Preballot - Revised Ballot 190

On Wed, May 17, 2017 at 1:29 PM, Doug Beattie wrote: > Ryan, > > > > Is this a current summary of the options: > > 1) Set a date way out in the future for allowing certificates to be > issued using deprecated domain validation methods: > > a. Not secure,

Re: [cabfpub] Preballot - Revised Ballot 190

SAN extension and this new one, and > voilà, it doesn’t minimizes at all changes to the CA infrastructure. > > Cordialement, > Erwann Abalea > > Le 17 mai 2017 à 18:24, Ryan Sleevi via Public <public@cabforum.org> a > écrit : > > Kirk, > > I didn't see an answer to thi

Re: [cabfpub] Preballot - Revised Ballot 190

> > *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Ryan > Sleevi via Public > *Sent:* Wednesday, May 17, 2017 12:25 PM > *To:* CA/Browser Forum Public Discussion List <public@cabforum.org> > *Cc:* Ryan Sleevi <sle...@google.com> > *Subject:* R

Re: [cabfpub] Preballot - Revised Ballot 190

On Wed, May 17, 2017 at 12:17 PM, Kirk Hall via Public wrote: > Jeremy, Gerv, and I have worked on this revised version of Ballot 190, and > offer it for comment as a preballot. > > A few points to highlight. > > - There is now a new fifth paragraph in the

Re: [cabfpub] Preballot - Revised Ballot 190

On Wed, May 17, 2017 at 12:28 PM, Gervase Markham <g...@mozilla.org> wrote: > On 17/05/17 17:24, Ryan Sleevi via Public wrote: > > Would you (and Jeremy and Gerv) be receptive to including this in > > 3.2.2.4? > > I have no objection; although would it h

Re: [cabfpub] Preballot - Revised Ballot 190

Kirk, I didn't see an answer to this question posed - https://cabforum.org/pipermail/public/2017-April/010802.html For example, proposed technical details were provided in https://cabforum.org/pipermail/public/2017-May/010848.html Would you (and Jeremy and Gerv) be receptive to including this

Re: [cabfpub] streetAddress

On Wed, May 17, 2017 at 6:08 AM, Adriano Santoni via Public < public@cabforum.org> wrote: > All, would like some opinions about the following question: > Can it be considered "okay" if the streetAddress component of an OV (or > EV) certificate Subject contains some more information than it's

Re: [cabfpub] Revised Notice of Review Period - Ballot 198 - .Onion Revisions

Yup. I'm curious for Apple's and Amazon's feedback, since they've been most active in bylaw discussions :) We've got several paths to clear this up, hence my straw poll outlining options I could think of that would allow us to do so (trying to do so w/in 2 weeks - e.g. prior to the IP Review

Re: [cabfpub] [EXTERNAL]Re: Revised Notice of Review Period - Ballot 198 - .Onion Revisions

ng the > discussion period), and put that in the Review Notice after a successful > vote. I’m not sure if that caused a mistake here. > > > > *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Ryan > Sleevi via Public > *Sent:* Tuesday, May 16, 2017 11:39 AM &g

Re: [cabfpub] Revised Notice of Review Period - Ballot 198 - .Onion Revisions

As Ben has highlighted, the result of 198 created a new set of issues. Kirk's original message includes the full text of the ballot (MOTION BEGINS), which, unfortunately, used text different from what was adopted in Ballot 144 (and part of the current EVGs) when Jeremy made his modifications. In

Re: [cabfpub] Domain validation

On Tue, May 16, 2017 at 12:25 PM, Ryan Sleevi wrote: > So, first and foremost, it's unclear whether you're proposing this as a > 'new' Ballot 190, or 'in addition to' Ballot 190. It's unclear if you're > trying to break the problems out, or to solve the problems themselves. >

Re: [cabfpub] Domain validation

So, first and foremost, it's unclear whether you're proposing this as a 'new' Ballot 190, or 'in addition to' Ballot 190. It's unclear if you're trying to break the problems out, or to solve the problems themselves. I certainly am biased towards approaching this like most organizations approach

Re: [cabfpub] Domain validation

On Tue, May 16, 2017 at 11:55 AM, Jeremy Rowley wrote: > > 1) The document is presented as a ballot because I based the revisions on > 190. If there are discrete sub-components someone doesn’t like, I don’t > mind breaking it up into chunks. > The problem is not

Re: [cabfpub] Domain validation

Jeremy, I think the trend has been to try to keep revisions simple - so that we don't introduce any unintentional scope. Could you expand on the reasoning for coupling these? As we saw with Ballot 193/197, it seems like it makes it more error prone. You posed it as a ballot, so it makes it hard

Re: [cabfpub] CAA Customer Identifier

Jeremy, You can extend the CAA syntax with issuer-specific properties. Do you think it makes sense to first experiment with this deployment, and then subsequently report back? Namely, the syntax for the issue property tag is issue [; = ]* The '=" portion allows you to define CA-specific

Re: [cabfpub] Profiling OCSP & CRLs

On Sat, May 13, 2017 at 11:47 AM, Dimitris Zacharopoulos wrote: > This is a very good description of the situation and the comparison of the > security concerns between the Certificate issuing system (certificates > signed by a CA) and the OCSP responder system (responses

Re: [cabfpub] Profiling OCSP & CRLs

On Thu, May 11, 2017 at 2:28 PM, Tim Shirley wrote: > Ah yes, good point. Both the private key of the responder cert AND the > system used to generate the OCSP responses need to have comparable > protections/controls to the private key of the associated online CA AND the

Re: [cabfpub] Profiling OCSP & CRLs

On Thu, May 11, 2017 at 10:02 AM, Tim Shirley wrote: > Certainly the risk profile is greater for long-lived CRLs and long-lived > OCSP responses than it is for long-lived OCSP responder certificates, since > CRLs and OCSP responses could be replayed to hide a subsequent

Re: [cabfpub] Profiling OCSP & CRLs

blic@cabforum.org> > *Cc:* Peter Bowen <p...@amzn.com> > *Subject:* Re: [cabfpub] Profiling OCSP & CRLs > > > > Ryan, > > > > This seems reasonable when you are dealing with an online CA. When you are > dealing with a root CA, it is currently reasonable

Re: [cabfpub] [EXTERNAL]Re: Profiling OCSP & CRLs

On Wed, May 10, 2017 at 5:10 PM, Bruce Morton < bruce.mor...@entrustdatacard.com> wrote: > In addition to CRLs, are revocations of issuing CAs not also addressed > with CRLSets, OneCRL and certificate blacklisting? > Well, only in as much as CAs' practices related to revocation haven't been good

Re: [cabfpub] Profiling OCSP & CRLs

Bowen <p...@amzn.com> > *Subject:* Re: [cabfpub] Profiling OCSP & CRLs > > > > Ryan, > > > > This seems reasonable when you are dealing with an online CA. When you are > dealing with a root CA, it is currently reasonable to only bring it online > once a y

Re: [cabfpub] Is CN value required in the SAN?

Right. To recap that thought: >From RFC 5280's perspective, it's legal to have an empty subject in a leaf cert IF the subjectAltName is marked critical. This comes from the following excerpts in 4.1.2.6: " If the subject is a CA (e.g., the basic constraints extension, as discussed in Section

Re: [cabfpub] [EXTERNAL]Re: Profiling OCSP & CRLs

ger. > > > > Thanks, Bruce. > > > > *From:* Public [mailto:public-boun...@cabforum.org] *On Behalf Of *Ryan > Sleevi via Public > *Sent:* Monday, May 8, 2017 7:52 PM > *To:* Curt Spann <csp...@apple.com> > *Cc:* Ryan Sleevi <sle...@google.com>; CA/B

Re: [cabfpub] Profiling OCSP & CRLs

lly, for whatever target validity period we should add some > buffer time. > > Cheers, > Curt > > On Apr 25, 2017, at 4:53 PM, Ryan Sleevi via Public <public@cabforum.org> > wrote: > > Hi folks, > > In response to various investigations about OCSP performance, o

Re: [cabfpub] Ballot 199 - Require commonName in Root and Intermediate Certificates

On Tue, Apr 25, 2017 at 11:03 AM, Gervase Markham via Public < public@cabforum.org> wrote: > *Ballot 199 - Require commonName in Root and Intermediate Certificates* > Google votes YES ___ Public mailing list Public@cabforum.org

Re: [cabfpub] [EXT] Re: Ballot 199 - Require commonName in Root and Intermediate Certificates

n 4 May 2017, at 12:30 pm, Ryan Sleevi via Public <public@cabforum.org> > wrote: > > Kirk raised that, but it does not seem to be a founded concern. > > 1) That requirement applies to all certificates issued against the current > BRs > 2) The BRs do not retroactively

Re: [cabfpub] [EXT] Re: Ballot 199 - Require commonName in Root and Intermediate Certificates

Kirk raised that, but it does not seem to be a founded concern. 1) That requirement applies to all certificates issued against the current BRs 2) The BRs do not retroactively invalidate - or, especially in the case of Ballot 197 - approve - certificate issuance. A CA has always and only been

Re: [cabfpub] Ballot 198 - Onion Revisions v2

Thanks for the reminder :) Google votes YES, as this was certainly part of the original intent and discussion about how to provide stronger assurance for these domains :) On Wed, May 3, 2017 at 8:28 PM, Jeremy Rowley via Public < public@cabforum.org> wrote: > This ballot is now in voting. > >

Re: [cabfpub] Revocation Timeframe Ballot Language

It probably comes as no surprise to anyone in the Forum that I'm not a big fan of a blanket policy for CA discretion, much like the any other method concerns :) Jeremy previously had a pretty good draft here, but didn't go forward with it. That's captured in

Re: [cabfpub] Ballot 190

On Tue, May 2, 2017 at 11:44 AM, Rob Stradling wrote: > > And if, as today, the Leaf cert doesn't contain 2.23.140.x.y.z, then the > same is true: the leaf would never validate with the 2.23.140.x.y.z OID in > the user-initial-policy-set. Right? If so, I'm not really

Re: [cabfpub] [EXTERNAL]Re: Ballot 190

On Mon, May 1, 2017 at 12:37 PM, Kirk Hall via Public wrote: > As Bruce said on our call last week, adding flags to our vetting system as > to what type of vetting method was used in in on our roadmap - but right > now, we can't know without opening each and every vetting

Re: [cabfpub] Ballot 190

Well, I was discussing in the broader context :) For example, you "could" simply indicate BRComplianceDetails ::= SEQUENCE { version OBJECT IDENTIFIER, validationMethod INTEGER } As an extension There are, of course, more efficient ways to structure this data (for example, expandable

Re: [cabfpub] Ballot 190

On Mon, May 1, 2017 at 8:41 AM, Gervase Markham via Public < public@cabforum.org> wrote: > > > 2. On the idea of marker of some sort in new certs indicating whether or > > not a newly-issued cert had been validated (or revalidated) in > > accordance with the methods in Ballot 190 – how do you see

Re: [cabfpub] Baseline Requirements v. 1.4.6

Yeah, those should be done by ballot, just to make sure everyone understands the implications and interpretation :) On Sun, Apr 30, 2017 at 1:12 PM, Jeremy Rowley via Public < public@cabforum.org> wrote: > At least one of those is part of ballot 190 > > > > *From:* Public

Re: [cabfpub] Fwd: RE: RFC 3647 Compliance

For what it's worth, the proposal gives that - 6 months - since we know there are some using 2527 :) It phases in at 8 December, which was 6 months + 44 days (14 days voting + 30 day IP review) from when I drafted it :) On Fri, Apr 28, 2017 at 9:35 AM, Gervase Markham via Public <

Re: [cabfpub] Ballot 190

On Fri, Apr 28, 2017 at 1:32 AM, Kirk Hall wrote: > One other comment. Remember that for the last few months, new Methods 1-4 > and 7-10 were actually included under Method 11 “any other method” after > Ballot 181’s effective date, and that situation will continue

Re: [cabfpub] Forbid DTPs from doing Domain/IP Ownership Validation ballot draft

On Thu, Apr 27, 2017 at 6:04 PM, Kirk Hall via Public wrote: > Gerv, I have a question on the actual implementation of your proposal – > would your proposal require all aspects of domain validation to be done by > employees of the CA? > Yes > Is everyone who is not an

Re: [cabfpub] Forbid DTPs from doing Domain/IP Ownership Validation ballot draft

On Thu, Apr 27, 2017 at 6:04 PM, Kirk Hall via Public wrote: > Ryan, in response to your recent messages – see below as to specific > concrete concerns with the proposal. > You spoke any abstract about Freedonia and MegaCA, or that they were practiced by TrendMicro. Are

Re: [cabfpub] Ballot 190

On Thu, Apr 27, 2017 at 4:00 PM, Jeremy Rowley via Public < public@cabforum.org> wrote: > Ben let me know that there were questions about Ballot 190. The ballot was > withdrawn and hasn’t gone to vote yet because of Section 2: > > > > “This provisions of Ballot Section 1 will apply only to the

Re: [cabfpub] [EXTERNAL] Forbid DTPs from doing Domain/IP Ownership Validation ballot draft

On Thu, Apr 27, 2017 at 2:57 PM, Kirk Hall via Public wrote: > You have identified one case where an external RA (DTP) was not known to > you -- I believe it was the Korean partner of Symantec, right? Have you > encountered any other cases that are similar? > This is,

<    1   2   3   4   5   6   7   8   9   >