To be clear, I don’t actually seek to scrap it.

 

The proposal was abandoned because of reasoning similar to yours.  No one 
thought it was worth the effort.

 

-Tim

 

From: Ryan Sleevi [mailto:[email protected]] 
Sent: Tuesday, July 3, 2018 10:11 AM
To: Tim Hollebeek <[email protected]>; CABFPub <[email protected]>
Cc: Dimitris Zacharopoulos <[email protected]>; Adriano Santoni - Actalis S.p.A. 
<[email protected]>
Subject: Re: [cabfpub] New Server Certificate Working Group

 

There's a distinction between can and is. These two capture very different 
states, in which the "Root Certificate Issuer" encompasses what we 
traditionally call "Super-CAs" in the Mozilla terminology.

 

If the suggestion is that a Super-CA needs to start issuing to end-entities to 
join the Forum, that's a step back.

If the suggestion is that a Super-CA can't join the Forum, that's a step back.

 

Thus, if you seek to scrap it without doing harm, it's not actually scrapped - 
it's just no longer split out into two definitions, but one unified definition 
that... allows for both cases. Thus it doesn't really achieve anything.

 

On Tue, Jul 3, 2018 at 9:14 AM Tim Hollebeek via Public <[email protected] 
<mailto:[email protected]> > wrote:

Right, the proposal was to scrap Root Certificate Issuer, since any such entity 
can be a Certificate Issuer if it chooses to do so, and almost all do for 
obvious reasons.

 

We actually started down that path a bit before abandoning it.

 

-Tim

 

From: Dimitris Zacharopoulos [mailto:[email protected] <mailto:[email protected]> 
] 
Sent: Tuesday, July 3, 2018 9:02 AM
To: Adriano Santoni <[email protected] 
<mailto:[email protected]> >
Cc: Tim Hollebeek <[email protected] 
<mailto:[email protected]> >; CA/Browser Forum Public Discussion List 
<[email protected] <mailto:[email protected]> >
Subject: Re: [cabfpub] New Server Certificate Working Group

 

 

On 3/7/2018 3:36 μμ, Tim Hollebeek via Public wrote:

This was discussed on the Governance Reform Working Group, and as I recall, 
most people agree the distinction probably isn’t useful and is a historical 
artifact.  But there wasn’t enough motivation to scrap it.

 

It is intended to support the notion of a company that operates a root and 
signs other CA certificates, but doesn’t issue end entity certificates itself.  
Such a company is a Root Certificate Issuer but not a Certificate Issuer.

 


In addition to that, a company might be operating only a SubCA that they have 
obtained from another company that operates a RootCA. These companies are also 
entitled to become Members as a "Certificate Issuer".

Dimitris.



-Tim

 

From: Public [mailto:[email protected]] On Behalf Of Adriano Santoni 
via Public
Sent: Tuesday, July 3, 2018 2:41 AM
To: [email protected] <mailto:[email protected]> 
Subject: Re: [cabfpub] New Server Certificate Working Group

 

Hi Kirk,

based on these definitions, it seems to me that most CAs among CABF members 
fall into both categories. 

What is the purpose of distinguishing between the two, after all?

Adriano

 

 

Il 03/07/2018 01:30, Kirk Hall via Public ha scritto:

I would look again at the definitions on the two different ways to participate 
as a CA.  

 

My guess is that CAs who have and use their own trusted roots will choose (2) 
Root Certificate Issuer, while CAs who do not have their own trusted roots will 
choose (1) Certificate Issuer, but I’m not sure on that.  The only reason why 
we are asking Members to declare their status is just so everyone can know and 
can confirm that the Member meets the membership qualifications.  

 

(1) Certificate Issuer: The member organization operates a certification 
authority that has a current and successful WebTrust for CAs audit, or ETSI TS 
102042, ETSI 101456, or ETSI EN 319 411-1 audit report prepared by a 
properly-qualified auditor, and that actively issues certificates to Web 
servers that are openly accessible from the Internet, such certificates being 
treated as valid when using a browser created by a Certificate Consumer Member. 
Applicants that are not actively issuing certificates but otherwise meet 
membership criteria may be granted Associate Member status under Bylaw Sec. 3.1 
for a period of time to be designated by the Forum.

 

(2) Root Certificate Issuer: The member organization operates a certification 
authority that has a current and successful WebTrust for CAs, or ETSI TS 
102042, ETSI TS 101456, ETSI EN 319 411-1 audit report prepared by a 
properly-qualified auditor, and that actively issues certificates to 
subordinate CAs that, in turn, actively issue certificates to Web servers that 
are openly accessible from the Internet, such certificates being treated as 
valid when using a browser created by a Certificate Consumer Member. Applicants 
that are not actively issuing certificates but otherwise meet membership 
criteria may be granted Associate Member status under Bylaw Sec. 3.1 for a 
period of time to be designated by the Forum.

 

 

From: Peter Miškovič [mailto:[email protected]] 
Sent: Monday, July 2, 2018 2:34 AM
To: Kirk Hall  <mailto:[email protected]> 
<[email protected]>
Cc: CA/Browser Forum Public Discussion List  <mailto:[email protected]> 
<[email protected]>; Ben Wilson  <mailto:[email protected]> 
<[email protected]>
Subject: [EXTERNAL]RE: New Server Certificate Working Group

 

Hi Kirk,

could you explain to me difference between (1) and (2)? We are CA which issue 
subordinate CAs for our own purpose and from them actively issues certificates 
to Web servers. Am I right if I suppose that we are “Root Certificate Issuer” 
and not only “Certificate Issuer”.

Thanks.

 

Regards

Peter

 

 

 

From: Public <[email protected] <mailto:[email protected]> 
> On Behalf Of Kirk Hall via Public
Sent: Saturday, June 30, 2018 12:26 AM
To: Ben Wilson <[email protected] <mailto:[email protected]> >; 
CABFPub <[email protected] <mailto:[email protected]> >
Subject: Re: [cabfpub] New Server Certificate Working Group

 

Ben, on the wiki page you created, can you add a column between the column 
“Date of Declaration” and the column “Date of Withdrawal” and label it “Type”.  
Then maybe put on the page at the top a guide to the three types of Members and 
the one type of Associate member, something like this:

 

Type

1 = Certificate Issuer

2 = Root Certificate Issuer

3 = Certificate Consumer

4 = Associate Member

 

We probably should also post these definitions on the wiki page from the Server 
Certificate Working Group Charter to remind people what the terms mean.

 

(1) Certificate Issuer: The member organization operates a certification 
authority that has a current and successful WebTrust for CAs audit, or ETSI TS 
102042, ETSI 101456, or ETSI EN 319 411-1 audit report prepared by a 
properly-qualified auditor, and that actively issues certificates to Web 
servers that are openly accessible from the Internet, such certificates being 
treated as valid when using a browser created by a Certificate Consumer Member. 
Applicants that are not actively issuing certificates but otherwise meet 
membership criteria may be granted Associate Member status under Bylaw Sec. 3.1 
for a period of time to be designated by the Forum.

 

(2) Root Certificate Issuer: The member organization operates a certification 
authority that has a current and successful WebTrust for CAs, or ETSI TS 
102042, ETSI TS 101456, ETSI EN 319 411-1 audit report prepared by a 
properly-qualified auditor, and that actively issues certificates to 
subordinate CAs that, in turn, actively issue certificates to Web servers that 
are openly accessible from the Internet, such certificates being treated as 
valid when using a browser created by a Certificate Consumer Member. Applicants 
that are not actively issuing certificates but otherwise meet membership 
criteria may be granted Associate Member status under Bylaw Sec. 3.1 for a 
period of time to be designated by the Forum.

 

(3) A Certificate Consumer can participate in this Working Group if it produces 
a software product intended for use by the general public for browsing the Web 
securely.

 

 

 

From: Ben Wilson [mailto:[email protected]] 
Sent: Friday, June 29, 2018 10:24 AM
To: CABFPub <[email protected] <mailto:[email protected]> >
Cc: Kirk Hall <[email protected] 
<mailto:[email protected]> >
Subject: [EXTERNAL]New Server Certificate Working Group

 

Hi All,

 

As Kirk mentioned during the teleconference call yesterday, we are in the 
process of spinning up the Server Certificate Working Group and will hold our 
first meeting on July 12.  Kirk and I will be sending out a more formal 
announcement of that meeting and solicitation for participation. 

 

However, given that the new Bylaws come into effect early next week, I felt it 
was important that we start the transition before then. I propose that the 
Forum’s mechanism for formally declaring participation in the Server 
Certificate Working Group be that existing members and interested parties (who 
have signed the Agreement for IPR Policy v. 1.3) send an email to Kirk and me, 
respectively as Chair and Vice-Chair of the WG, and formally declare their 
participation in the WG. (I had contemplated that everyone might send their 
email to the public list, but I felt that all of those emails might clutter 
your inboxes.) 

 

As a follow up task to this declaration, I’d ask that CABF members list the 
name of their organization here 
https://cabforum.org/wiki/Server%20Certificate%20Working%20Group.  If you are 
an interested party, we will add your name as a participant when we receive 
your email.

 

Also, everyone is welcome to subscribe to the WG’s mailing list here - 
https://cabforum.org/mailman/listinfo/servercert-wg.  

 

Thanks,

 

Ben






_______________________________________________
Public mailing list
[email protected] <mailto:[email protected]> 
https://cabforum.org/mailman/listinfo/public

 





_______________________________________________
Public mailing list
[email protected] <mailto:[email protected]> 
https://cabforum.org/mailman/listinfo/public

 

_______________________________________________
Public mailing list
[email protected] <mailto:[email protected]> 
https://cabforum.org/mailman/listinfo/public

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public

Reply via email to