[cabfpub] OIDs for DV and OV

[Ryan Sleevi]

On Oct 7, 2014 5:57 PM, "Rick Andrews" <Rick_Andrews at symantec.com> wrote:
>
> We had a related conversation months ago in the CABF (attached). I
brought up an issue with some customers who were asking us for SSL certs
that chained up to the US Government Federal Bridge CA (FBCA). I looked
into it, and found that the FBCA policy OID was required in all certs in
the chain, while the BRs required a policy OID in the end-entity only. I
asked whether any browser did any strict policy flow-down checking that
would break if the end-entity cert had two policy OIDs (BR and FBCA) while
the intermediate (the one we use to issue FBCA) had only one (FBCA). As I
recall, no browser said that they were doing strict policy OID checking. As
far as I recall, the issue is still unresolved. We haven’t issued any such
cert because we weren’t sure we’d be able to pass both our FBCA and BR
audits.
>

We ALL do it when trying to validate an OID. ALL RFC5280 compliant
processors do this - because its an RFC5280

We don't REJECT the cert, but neither is it valid.

>
>
> My point is that no browser seems to do strict policy OID checking, so
the DV/OV OID change should not break anything, and CAs do not need to
re-issue all the intermediates in their hierarchies.
>
>
>
> -Rick

No RP using a RFC5280 tool will validate your certs as valid for that
policy. Which is why it is either pointless or wrong.

>
>
>
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Kelvin Yiu
> Sent: Tuesday, October 07, 2014 2:40 PM
> To: Ben Wilson; Dean Coclin; i-barreira at izenpe.net; sleevi at google.com;
public at cabforum.org
>
> Subject: Re: [cabfpub] OIDs for DV and OV
>
>
>
> I don’t have a problem if a CA chooses to use the BR OIDs instead of
their own OIDs to identify BR related certificate policies as long as it is
consistently used in the certificate chain. My concern is with cases that
do not follow RFC 5280. For example, when BR OIDs are added to end entity
certificates in addition to CA specific OIDs when the CA certificate
explicitly contain only CA specific OIDs.
>
>
>
> Kelvin
>
>
>
> From: Ben Wilson [mailto:ben.wilson at digicert.com]
> Sent: Tuesday, October 7, 2014 12:56 PM
> To: Kelvin Yiu; Dean Coclin; i-barreira at izenpe.net; sleevi at google.com;
public at cabforum.org
> Subject: RE: [cabfpub] OIDs for DV and OV
>
>
>
> I don’t think that the use of a policy OID in a certificate necessarily
“ignores” “rules” around policy processing in RFC5280.   I don’t think
anyone has requested that we require a policy constraints extension.  We’re
only talking about putting a policy OID in a BR certificate, along with any
other policy OIDs the CA cares to insert.  The primary purpose of the CP
OID is to assert the policy under which the certificate has been issued.
It is not to build a path up the chain or constrain processing—those are
secondary considerations.  I agree about the necessity of putting the CP
OID in your CPS and of being audited for compliance with the policy (the
BRs and EVGs acknowledge that a point-in-time / readiness audit would be
acceptable).
>
>
>
> The BRs is the closest thing to a Certificate Policy that currently
exists.  It is “”A named set of rules that indicates the applicability of a
certificate to a particular community and/or class of application with
common security requirements.”  Section D.7.1.6 of the PKI Assessment
Guidelines states,  “The certificate policies extension is intended to
convey policy information or references to policy information.
Specifically, a PKI can place the object identifier of a certificate policy
within the certificate policies extension.  The object identifier can
enable a relying party to configure its systems to cause its software to
look for the OID of an acceptable certificate policy, permit the
transaction to continue if the system finds the OID of an acceptable CP in
the certificate, and halt the transaction if it does not.”   So while it
enables functionality, it doesn’t require it, in case that is a browser
concern.
>
>
>
>
>
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Kelvin Yiu
> Sent: Tuesday, October 7, 2014 1:03 PM
> To: Dean Coclin; i-barreira at izenpe.net; sleevi at google.com;
public at cabforum.org
> Subject: Re: [cabfpub] OIDs for DV and OV
>
>
>
> FWIW, Microsoft provides an API on Windows 7 and later to determine
whether a certificate is EV or not, according to Microsoft’s root CA
program.
>
>
>
>
http://msdn.microsoft.com/en-us/library/windows/desktop/aa377163(v=vs.85).aspx
>
>
>
> I think it is a bad idea to assert BR OIDs for xV compliance by ignoring
the rules around certificate policies processing in RFC 5280. While I
understand the desire to have a source of information to identify xV
certificates, the value is questionable to me unless the information is
also in the CPS and the appropriate audit has taken place.
>
>
>
> Kelvin
>
>
>
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Dean Coclin
> Sent: Tuesday, October 7, 2014 9:12 AM
> To: i-barreira at izenpe.net; sleevi at google.com; public at cabforum.org
> Subject: Re: [cabfpub] OIDs for DV and OV
>
>
>
> Hi Inigo,
>
> Yes, I did create such a sheet and I’ve enclosed it here. And I think it
proves my point that the current situation exacerbates the problem, making
it difficult for one to programmatically determine what type of cert they
are encountering.
>
>
>
> Dean
>
>
>
> From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net]
> Sent: Tuesday, October 07, 2014 12:44 AM
> To: Dean Coclin; sleevi at google.com; public at cabforum.org
> Subject: RE: [cabfpub] OIDs for DV and OV
>
>
>
> Dean, time ago you created an Excel sheet with those CAs that use their
own OIDs for DV and OV, similar to what was done with EV. The intention of
that list was to also have another “source” of information for considering
those certs as DV or OV for the browsers in case they need it.
>
>
>
> BTW, Izenpe uses their own OIDs plus the CABF ones.
>
>
>
>
>
>
>
> Iñigo Barreira
> Responsable del Área técnica
> i-barreira at izenpe.net
>
> 945067705
>
>
>
> ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea
gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi
erantzuna. KONTUZ!
> ATENCION! Este mensaje contiene informacion privilegiada o confidencial a
la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por
error le agradeceriamos que no hiciera uso de la informacion y que se
pusiese en contacto con el remitente.
>
>
>
> De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] En
nombre de Dean Coclin
> Enviado el: lunes, 06 de octubre de 2014 21:17
> Para: Ryan Sleevi; public at cabforum.org
> Asunto: Re: [cabfpub] OIDs for DV and OV
>
>
>
> So I get the part that Chrome (and likely other browsers in the CA/B
forum) don’t intend to distinguish DV and OV certs in any way. Got that.
Not a point of contention. In fact, I knew that when I started this
thread.  So no need to go down that path anymore. Having different OIDs
does not oblige a browser do anything.
>
>
>
> I would have expected more negative commentary from CAs but so far there
has been none. And only 1 browser has chimed in.
>
>
>
> However, browsers are not the only application that use SSL certificates.
There are others out there and I distinctly recall a conversation about 2-3
years ago where Paypal (a CA/B member) explicitly asked that these OIDs be
mandatory. Brad stated that their security group had deemed DV certs to be
a security threat to their ecosystem and wanted an easy programmatic way to
distinguish them. At the time, there was some pushback (I don’t believe
from browsers) and the OIDs ended up being optional.
>
>
>
> It looks as if some CAs do use OIDs in their DV and OV certs but some
don’t use the CA/B Forum OIDs (rather their own). This makes it difficult
to apply a uniform decision process.
>
>
>
> Certs conforming to policy and issued correctly are one aspect that some
folks are looking for. The type of certificate is another. One that has not
been vetted is different from one that has some vetting completed (other
security issues being equal). Perhaps that benefit is not tangible to some
but it certainly is to others. I can spew some stats on DV cert use and
fraud but that will just muddle this thread so I’ll save it for another day.
>
>
>
> Why do browsers care one way or the other if other parties want to make
this distinction? The CA/B Forum has defined different baseline standards
for these types of certs. Why not make transparency around those standards
easy for those that want to draw a distinction?
>
>
>
> Certainly would love to hear from some other interested parties.
>
>
>
> Thanks,
>
>
>
> Dean
>
>
>
> From: Ryan Sleevi [mailto:sleevi at google.com]
> Sent: Thursday, October 02, 2014 8:56 PM
> To: Dean Coclin
> Cc: public at cabforum.org
> Subject: Re: [cabfpub] OIDs for DV and OV
>
>
>
>
>
>
>
> On Thu, Oct 2, 2014 at 5:31 PM, Dean Coclin <Dean_Coclin at symantec.com>
wrote:
>
> Thanks for the response and pointers. I’ve read through the threads but
still have additional questions/comments. I’ll readily admit that I don’t
understand all the commentary in the Mozilla threads so I apologize if
these questions sound somewhat naïve. Happy to be educated:
>
>
>
> You've heard repeatedly from several browsers about an explicit non-goal
of distinguishing DV and OV. As the Forum is comprised of CAs and Browsers,
do we have any Browsers that wish to make such a distinction? If not, it
would be wholly inappropriate for the Forum to require it.
>
> >>I haven’t heard of any browsers that want to make that distinction
(yet). It is my understanding that the Forum BRs do require an OID for EV
certs. So why is it “inappropriate” for the Forum to require OIDs for DV/OV?
>
>
>
> Browsers have agreed to make a distinction between EV and !EV, so have
required there be a way to detect that.
>
> Browsers have not agreed that there is a distinction between DV or OV,
nor is there a need to detect the difference.
>
>
>
> That the browsers have required (effectively all stores at this point,
AFAIK) is that the root program members be BR compliant. So any new certs
issued (technically, independent of the notBefore, and we know CAs
regularly backdate from time of issuance, but it's a rough heuristic) are,
by definition, BR compliant.
>
>
>>
>>
>>
>> If there are non-browser relying parties interested in such
distinctions, the CA can always provide such distinctions themselves.
>>
>> >>Can you elaborate on what you mean by this? If there’s another way to
accomplish the end result, happy to explore further. But it would have to
be uniform among all CAs that issue these certs.
>
>
>
> I don't see why it needs to be uniform.
>
>
> The requirement as to what shape it takes is dictated by the relying
party applications.
>
> The browsers, as relying party applications, do not and have not yet
cared about the shape of DV and OV, and as per our recent F2F, aren't
really keen to either.
>
>
>
> So having the browsers dictate the shape of the solution seems
unnecessary, and an issue for these relying party applications (e.g.
Netcraft) to work with CAs.
>
>
>>
>>
>>
>> As someone very keen on programatic checks and detection for
misissuance, there's no question that this would NOT meaningfully help
address the concerns we see.
>>
>> >>I wasn’t suggesting that this addition would in any way help you with
your programmatic checks for mis-issuance.  Rather, it would make the task
for organizations like Netcraft, EFF or others that tabulate statistics on
various types of certificates easier to do. Is that not the case?
>
>
>
> Not really. These organizations are interested in the same discussions
and distinctions we are - what are the certificates being issued and do
they conform to the policies that they're supposed to.
>
>
>
> We've established that there's no 'uniform' definition of what
constitutes OV, only that the BR requires certain vetting steps for certain
subject fields that are OPTIONAL. CAs have taken these and marketed them as
OV, but there's no such distinction as a level, nor a particular profile
spelled out in the appendices as to what constitutes a "DV" vs "OV".
>
>
>
> If that was the only degree of distinction required, it's just as easy as
checking the Subject fields for any of the OPTIONAL fields.
>
>
>>
>>
>>
>> That is, there would need to be an OID _per revision_ of the BRs, to
indicate "which" version of the BRs something was complying to.
>>
>> >>Fully admit that I don’t understand how this works. But wouldn’t that
also be the case for EV (which currently requires this OID)?
>
>
>
> YES! And it's one of the many reasons why EV is somewhat muddled for
programatic checks or distinctions. And yet this is also necessary because
any change in policy, by definition, necessitates a change in OID to
(meaningfully) reflect that. And that constitutes rolling a new hierarchy
(and updating browsers' lists of recognized EV OIDs)
>
>
>>
>>
>>
>> I’m just trying to suggest a  way that someone can say: X is a DV cert,
Y is an OV cert, Z is an EV cert without a doubt. If OIDs are not the place
to do that, is there another mechanism available?
>> I’m sure you are familiar with Ryan Hurst’s blog on how difficult the
task currently is.
>
>
>
> I am (you're talking about http://unmitigatedrisk.com/?p=203 in
particular). But I'm also not supportive of encouraging a distinction that
we neither recognize nor have plans to recognize, and especially not
supportive of mandating such distinctions.
>
>
>
> This is especially true, as these distinctions don't offer any tangible
security benefits to the Web, as previously discussed.
>
>
>
> If we go to the point of mandating anything additional in certificates,
which requires a variety of changes in processes, profiles, and CPSes, I
want it to have meaningful security value. This change - which, as has been
shown by the development of audit standards and then the eventual
incorporation of those audit standards into the root programs, and then
FINALLY the enforcement of those audit standards of the root programs -
would take several years, at BEST, to deploy, and would communicate nothing
of actionable value. It's a hard sell.
>
>
>>
>>
>>
>>
>> Thanks,
>> Dean
>>
>>
>>
>> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
On Behalf Of Ryan Sleevi
>> Sent: Thursday, October 02, 2014 3:37 PM
>> To: Dean Coclin
>> Cc: public at cabforum.org
>> Subject: Re: [cabfpub] OIDs for DV and OV
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Oct 2, 2014 at 10:33 AM, Dean Coclin <Dean_Coclin at symantec.com>
wrote:
>>
>> Further to today’s discussion on our call, I’d like to get more feedback
on a proposal to make a unique standardized OID mandatory for DV and OV
certificates in the Baseline Requirements. Currently we have a mandatory
OID for EV certificates but optional for OV and DV.  This makes things
difficult for at least two groups of constituents:
>>
>>
>>
>> 1.       Relying parties that would like to distinguish between these
certificates
>>
>> You've heard repeatedly from several browsers about an explicit non-goal
of distinguishing DV and OV. As the Forum is comprised of CAs and Browsers,
do we have have any Browsers that wish to make such a distinction?
>>
>>
>>
>> If not, it would be wholly inappropriate for the Forum to require it. If
there are non-browser relying parties interested in such distinctions, the
CA can always provide such distinctions themselves.
>>
>>
>>>
>>> 2.       Analysts that report on SSL certificate data who have had to
issue revised reports because of cert misclassification
>>
>> As mentioned on the call, this has been discussed with Mozilla in the
past -
https://groups.google.com/d/msg/mozilla.dev.security.policy/-mCAK5zfhFQ/hEOQK-ubGRcJ
>>
>>
>>
>> As someone very keen on programatic checks and detection for
misissuance, there's no question that this would NOT meaningfully help
address the concerns we see.
>>
>>
>>
>> That is, there would need to be an OID _per revision_ of the BRs, to
indicate "which" version of the BRs something was complying to.
>>
>>
>>
>> I would hope that
https://groups.google.com/d/msg/mozilla.dev.security.policy/-mCAK5zfhFQ/2tRUS444krwJ
would capture some of these concerns more fully.
>>
>>
>>
>> Finally, to do anything meaningful with this in all major clients, it
would require that CAs redo their certificate hierarchy, as policy OIDs are
inherited. That's a silly thing, especially when CAs are still struggling
to migrate from SHA-1 to SHA-256 in their intermediates.
>>
>>
>>>
>>>
>>>
>>> My proposal is for CAs to put in OID X if it’s a DV certificate and OID
Y if it’s an OV certificate.
>>>
>>>
>>>
>>> As Rick reminded me on the call, we currently have something like this
for EV certificates (except that CAs are free to use the standard OID or
define one of their own).
>>>
>>>
>>>
>>> I’d like to hear pros/cons of this. Ryan S indicated that Google would
not support such a proposal but we didn’t have time to discuss the reasons.
>>>
>>>
>>>
>>> I’m sure there are both technical and policy reasons. Personally I’d
like to focus on the latter but remarks on both are welcome. This proposal
doesn’t require anyone to do anything with this data (i.e relying parties
can choose whether or not to utilize it).
>>>
>>>
>>> Thanks,
>>> Dean
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Public mailing list
>>> Public at cabforum.org
>>> https://cabforum.org/mailman/listinfo/public
>>
>>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Ben Wilson <ben at digicert.com>
> To: Rick Andrews <Rick_Andrews at symantec.com>
> Cc:
> Date: Sat, 15 Feb 2014 15:36:42 -0800
> Subject: RE: [cabfman] Teleconference agenda - CA/B Forum - 13 February
2014
>
> But if you can comply with two sets of policies (so there is no conflict
in that sense, then your concern seems to go away).  The only/main
difference (as compared to the BRs or EV) is the stricter federal
requirement that you have a human device sponsor (which could be one of the
EV roles).  Then the only thing remaining is what a particular browser
might do with certificate processing (like what we saw with the Netcraft
study).  It seems that RFC 5280 implies that policy mapping for path
construction is preferred over CA chaining when policies are provided and
supported by the client.    Most clients don’t follow policies, whereas I
think that a client fully compliant with RFC 5280 might choose to follow
the federal policy OIDs (unless as you suggest, both OIDs are in
intermediates).  What happens, though, since Root Certificates don’t
usually have policy OIDs?   Where does the chain truncate, and does that
matter for us? (That’s a whole other discussion.)
>
>
>
>
>
> From: management-bounces at cabforum.org [mailto:
management-bounces at cabforum.org] On Behalf Of Rick Andrews
> Sent: Friday, February 14, 2014 6:29 PM
> To: Doug Beattie; ben at digicert.com; 'CABFMAN'
> Subject: Re: [cabfman] Teleconference agenda - CA/B Forum - 13 February
2014
>
>
>
> Here’s more detail on the issue I raised during this week’s call.
>
>
>
> We have a number of customers asking us for SSL certs that chain up to
our public roots but also cross-chain to the Federal Bridge CA (FBCA). From
http://academic.research.microsoft.com/Paper/705036.aspx :
>
>
>
> “The US Federal PKI is designed around the Federal Bridge Certification
Authority. This innovative approach allows US federal agencies to operate
their own public key infrastructures and interoperate with the public key
infrastructures of other agencies in a highly simplified architecture that
minimizes cross-certification management and enhances technical
interoperability. The Federal Bridge implicitly establishes standards of
assurance for its participating members and enhances interoperability
standards among PKI product and service vendors.”
>
>
>
> I think their CP is here:
http://www.idmanagement.gov/sites/default/files/documents/FBCA_CP_RFC3647.pdf
>
>
>
> Looking through it, I don’t see any technical showstoppers. But one
concern is that the FBCA doc references RFC 3280, which is deprecated. It
mandates CRLs, but OCSP is optional. Still OK, we can add both and comply
with both policies. My second concern is that I don’t know what we’ll do if
the FBCA policy diverges from our BRs.
>
>
>
> FBCA seems to require that we put a policy OID in the cert indicating
compliance with FBCA policy. So at the very least, I think we’ll have to
put two policy OIDs in the intermediate and in each end-entity, one for
FBCA and one for CABF. But from a strict reading of RFC 5280, we should not
add a policy OID to an end-entity cert that isn’t also in all intermediates
above (or those intermediates need to contain the “anyPolicy” oid), but
FBCA says it should contain an FBCA OID. Policy OIDs should “flow down”
from roots to intermediates to end entities, and it seems incorrect to use
the CABF policy OID when the intermediate that signs it does not contain
that OID. However, we have empirical evidence that relying party agent
software (browsers) don’t strictly check this policy “flow down”. My third
concern is whether browsers will ever enforce this policy flow-down. But in
general, I’m just reluctant to try to issue a cert that complies with two
independent sets of policies.
>
>
>
> I think we have a little time set aside next week at the face-to-face to
discuss this.
>
>
>
> -Rick
>
>
>
> From: management-bounces at cabforum.org [mailto:
management-bounces at cabforum.org] On Behalf Of Doug Beattie
> Sent: Thursday, February 13, 2014 9:32 AM
> To: ben at digicert.com; 'CABFMAN'
> Subject: Re: [cabfman] Teleconference agenda - CA/B Forum - 13 February
2014
>
>
>
> During the call today there was some discussion about Policy OIDs and how
the BR guidelines should support other industry requirements (Federal
Bridge, Utility industry, etc.).  I agree this would be a good topic for
the face-to-face next week (I’m not sure where we left this during the
call).
>
>
>
> The page referenced below displays a wide range of approaches taken by
CAs, which highlights the need to provide more accurate guidance regarding
the use of one, multiple, specific BR OIDs, specific CA OIDs, other
industry OIDs, etc.  These guidelines should address the content of CA and
End Entity certificates.  This will help relying parties and browsers (who
may want to use certain values to drive their UI) to properly interpret the
intent on this extension.
>
>
>
>                 https://cabforum.org/object-registry/
>
>
>
> Doug
>
>
>
> From: management-bounces at cabforum.org [mailto:
management-bounces at cabforum.org] On Behalf Of Ben Wilson
> Sent: Wednesday, February 12, 2014 4:51 PM
> To: CABFMAN
> Subject: Re: [cabfman] Teleconference agenda - CA/B Forum - 13 February
2014
>
>
>
> Teleconference agenda – CA/B Forum
>
>
>
> Note that two items have been added for discussion under “Any Other
Business” and that the duration of the call has been extended accordingly.
>
>
>
> Date: 13 February 2014
>
>
>
> Time: 1600 – 1655 UTC
>
>
>
> (1600 UTC = 0800 PST, 0900 MST, 1000 CST, 1100 EST, 1600 WEST, 1700 CEST,
1800 EET)
>
>

>
> Conference ID 889-4985
>
>
>
> Phone numbers:
>
> Toll Access +1 (805) 309-2350
> Alternate +1 (714) 551-9842
> Toll-Free (U.S. & Canada) +1 (800) 309-2350
> Alternate +1 (800) 551-9842
> International Access Click Here
> Skype "TurboBridge" +99051000000481
> SIP Accesssip:bridge at turbobridge.com
> Local Dial-In Access Numbers  Click Here
>
>
>
> Note the two new items from Rick Andrews under “Other Business”
>
>
>
> Time
>
> Start
>
> Stop
>
> Slot
>
> Description
>
> Notes / Presenters
>
> (Thur) 13 February 2014
>
> 0:03
>
> 16:00
>
> 16:03
>
> 1
>
> Roll Call
>
>
>
> 0:03
>
> 16:03
>
> 16:06
>
> 2
>
> Read Antitrust Statement and
> Review Agenda
>
>
>
> 0:03
>
> 16:06
>
> 16:09
>
> 3
>
> Approval of Minutes of 30 January 2014
>
> Circulated on 6-Feb-2014
>
> 0:01
>
> 16:09
>
> 16:10
>
> 4
>
> Discussion of Ballots
>
> None
>
> 0:05
>
> 16:10
>
> 16:15
>
> 5
>
> Review of Membership Applications
>
> Visa's email to questions list dated 4-Feb-2014
>
> 0:10
>
> 16:15
>
> 16:25
>
> 6
>
> Review Working Group Agendas for Mountain View
>
> RFC 3647, SSL Performance, Code Signing, and EV Working Groups
>
> 0:15
>
> 16:25
>
> 16:40
>
> 7
>
> Review Agenda for Mountain View F2F
>
> Email with subject: Updated Draft Agenda for F2F Meeting sent to public
list 10-Feb-2014
>
> 0:14
>
> 16:40
>
> 16:54
>
> 8
>
> Any Other Business
>
> Potential conflict under RFC5280 between FBCA policy OIDs and the CABF
policy OIDs in intermediate CA certificates
>
>
>
> Proposal to change the BRs for gTLDs to 30 days from date of delegation
>
> 0:01
>
> 16:54
>
> 16:55
>
> 9
>
> Next phone call -- Thurs. Mar. 6th
>
>
>
> 0:00
>
> 16:55
>
> 16:55
>
> 10
>
> Adjourn
>
>
>
>
>
>
>
>
>
>
>
>
>
> Antitrust Statement:
>
> As you know, this meeting includes companies that compete against one
another. This meeting is intended to discuss technical
>
> standards related to the provision of existing and new types of digital
certificates without restricting competition in developing
>
> and marketing such certificates. This meeting is not intended to share
competitively-sensitive information among competitors,
>
> and therefore all participants agree not to discuss or exchange
information related to:
>
> (a) Pricing policies, pricing formulas, prices or other terms of sale;
>
> (b) Costs, cost structures, profit margins,
>
> (c) Pending or planned service offerings,
>
> (d) Customers, business, or marketing plans; or
>
> (e) The allocation of customers, territories, or products in any way.
>
>
>
> NOTE: THE TELECONFERENCE WILL BE RECORDED FOR THE PURPOSE OF PREPARING
THE MINUTES.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141007/720e39b6/attachment-0001.html