Re: [cabfpub] [EXTERNAL] a softer, gentler approach

[Kirk Hall via Public]

 That makes no sense, and is not generally 
> how rule sets are amended and codified.
> 

I'm sorry this does not make sense to you. It's especially unfortunate, because 
as I pointed out, this is exactly what the Forum has done and continued to do.

As I mentioned to you on the call, we remain opposed to the very concept of 
reusing the validation status - rather than the validation data. This is in the 
effort of security.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://cabforum.org/pipermail/public/attachments/20170413/c68b2a6e/attachment-0001.html>

--

Message: 2
Date: Thu, 13 Apr 2017 20:52:42 -0400
From: Ryan Sleevi <sle...@google.com>
To: "CA/Browser Forum Public Discussion List" <public@cabforum.org>
Subject: Re: [cabfpub] [EXTERNAL]Re: Ballot 190: Domain Validation
Message-ID:

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

[Peter Bowen via Public]

Kirk,

I think there is confusion here between “validation” and “validation data” as 
Geoff calls out.  As I understand it, some trust anchor list maintainers are 
fine with CAs reusing the inputs to the validation check as long as they are 
still valid inputs.  

For example, under the pre-169 BRs, the BRs only required “Communicating with 
the Domain’s administrator using an email address […]”.  It might have be 
acceptable for a CA to send an email saying “Is this address active?” to the 
approved email addresses and if they got back “Yes” use that data to meet 
3.2.2.4(4).  In the new rules, the CA would need to confirm they send a 
specific Random Value to the email address and received the Random Value back 
in the confirming response.  “Yes” is not a Random Value, so the data is not 
acceptable.  However if a CA was already sending something that qualifies as a 
Random Value and recording that it came back within the time allotted in 
3.2.2.4.4, the could use this information to perform the validation.

Is the problem you are running into that you cannot easily identify which sets 
of validation data you already have can continue to be used versus which data 
needs to be moved to archived status?

Thanks,
Peter

> On Apr 13, 2017, at 4:58 PM, Kirk Hall via Public  wrote:
> 
> No, Geoff – Section 2 is not designed to say that a CAcan still use 
> validation data from before but only to the extent that it complies with the 
> new requirements.  It says that the CA can reuse validation data properly 
> collected during the validation process before the effective date of Ballot 
> 190 for the normal period for reuse of validation data.  The CA does not have 
> to revet Subscribers again until the prior data expires according to the 
> normal rules for re-use of data.
> 
>  
> 
> As Gerv said on the call today, it will be a disincentive for CAs ever to 
> vote for incremental change in validation methods if the changes always take 
> effect immediately, and wipe out the CA’s ability to re-use data that was 
> properly collected according to the prior rules and is still in the permitted 
> re-use period.  I don’t think anyone intended that result when we came up 
> with Ballot 169 and now Ballot 190.
> 
>  
> 
> From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Geoff Keating 
> via Public
> Sent: Thursday, April 13, 2017 4:50 PM
> To: CA/Browser Forum Public Discussion List 
> Cc: Geoff Keating 
> Subject: [EXTERNAL]Re: [cabfpub] Ballot 190: Domain Validation
> 
>  
> 
>  
> 
> On Apr 11, 2017, at 1:46 PM, Jeremy Rowley via Public  
> wrote:
> 
>  
> 
> This provisions of Ballot Section 1 will apply only to the validation of 
> domain names occurring after this Ballot 190’s effective date.  Validation of 
> domain names that occurs before this Ballot’s effective date and the 
> resulting validation data may continue to be used for the periods specified 
> in BR 4.2.1 and EVGL 11.14.3 so long as the validations were conducted in 
> compliance with the BR Section 3.2.2.4 validation methods in effect at the 
> time of each validation.
> 
>  
> 
> I have to say, I find this confusing too.  ‘validation data’ to me sounds 
> like not the same thing as ‘validation’—I would think ‘validation data’ is 
> the raw results of the validation (“The user clicked on a link with a code of 
>  which was the same code we sent the user”) and not the conclusion (“so 
> the user controls the domain”).
> 
>  
> 
> In any case what I think we would like is that, as of the effective date, you 
> can still use validation data from before but only to the extent that it 
> complies with the new requirements?
> 
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public

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

[cabfpub] a softer, gentler approach

[Virginia Fournier via Public]

 in
the effort of security.
-- next part ------
An HTML attachment was scrubbed...
URL: 
<http://cabforum.org/pipermail/public/attachments/20170413/c68b2a6e/attachment-0001.html>

--

Message: 2
Date: Thu, 13 Apr 2017 20:52:42 -0400
From: Ryan Sleevi <sle...@google.com>
To: "CA/Browser Forum Public Discussion List" <public@cabforum.org>
Subject: Re: [cabfpub] [EXTERNAL]Re: Ballot 190: Domain Validation
Message-ID:

[cabfpub] 答复: [cabfpub] Ballot 195 �C CAA Fixup is in the DISCUSSION period (ends April 10)

[xiongyuanyuan via Public]

SHECA votes YES on ballot 195.

 

Ruby Xiong

Shanghai Electronic Certification Authority co., ltd. 

18F, No.1717, North Sichuan Road, Shanghai, China

Tel：+86-21-36393197

Email：  xiongyuany...@sheca.com 





 

 

发件人: Public [mailto:public-boun...@cabforum.org] 代表 Kirk Hall via
Public
发送时间: Monday, April 10, 2017 7:30 AM
收件人: CA/Browser Forum Public Discussion List
抄送: Kirk Hall
主题: [cabfpub] Ballot 195 �C CAA Fixup is in the DISCUSSION period (ends
April 10)

 

Reminder: Ballot 195 �C CAA Fixup is in the discussion period (ends April
10)

 

Ballot 195 - CAA Fixup

Purpose of Ballot: The CAB Forum recently passed ballot 187 to make CAA
checking mandatory. This ballot corrects some wording issues in the text
added by that ballot. 

The following motion has been proposed by Gervase Markham of Mozilla and
endorsed by Ryan Sleevi of Google and Jeremy Rowley of DigiCert:

-- MOTION BEGINS -- 

Change the following in section 3.2.2.8 of the Baseline Requirements:

1) Add a carriage return after "any other time."

2) Replace the sentence:

"CAs MUST process the issue, issuewild, and iodef property tags as specified
in RFC 6844."

with:

"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."

3) Replace the sentence:

"CAs MUST respect the critical flag and reject any unrecognized properties
with this flag set."

with:

"CAs MUST respect the critical flag and not issue a certificate if they
encounter an unrecognized property with this flag set."

-- MOTION ENDS --

 

The procedure for approval of this Final Maintenance Guideline ballot is as
follows (exact start and end times may be adjusted to comply with applicable
Bylaws and IPR Agreement):

 


BALLOT 195

Status: Final Maintenance Guideline

Start time (23:00 UTC)

End time (23:00 UTC)


Discussion (7 to 14 days)

3rd April

10th April


Vote for approval (7 days)

10th April

17th April


If vote approves ballot: Review Period (Chair to send Review Notice) (30
days).  

If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be
created.

If no Exclusion Notices filed, ballot becomes effective at end of Review
Period.

Upon filing of Review Notice by Chair

30 days after filing of Review Notice by Chair

 

>From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final
Maintenance Guideline, such ballot will include a redline or comparison
showing the set of changes from the Final Guideline section(s) intended to
become a Final Maintenance Guideline, and need not include a copy of the
full set of guidelines.  Such redline or comparison shall be made against
the Final Guideline section(s) as they exist at the time a ballot is
proposed, and need not take into consideration other ballots that may be
proposed subsequently, except as provided in Bylaw Section 2.3(j).

 

Votes must be cast by posting an on-list reply to this thread on the Public
list.  A vote in favor of the motion must indicate a clear 'yes' in the
response. A vote against must indicate a clear 'no' in the response. A vote
to abstain must indicate a clear 'abstain' in the response. Unclear
responses will not be counted. The latest vote received from any
representative of a voting member before the close of the voting period will
be counted. Voting members are listed here:  
https://cabforum.org/members/ 

In order for the motion to be adopted, two thirds or more of the votes cast
by members in the CA category and greater than 50% of the votes cast by
members in the browser category must be in favor.  Quorum is shown on
CA/Browser Forum wiki.  Under Bylaw 2.2(g), at least the required quorum
number must participate in the ballot for the ballot to be valid, either by
voting in favor, voting against, or abstaining.

 

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

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

[xiongyuanyuan via Public]

SHECA votes ABSTAIN on ballot 194.

 

Ruby Xiong

Shanghai Electronic Certification Authority co., ltd. 

18F, No.1717, North Sichuan Road, Shanghai, China

Tel：+86-21-36393197

Email：  xiongyuany...@sheca.com 





 

 

发件人: Public [mailto:public-boun...@cabforum.org] 代表 Kirk Hall via
Public
发送时间: Monday, April 10, 2017 7:30 AM
收件人: CA/Browser Forum Public Discussion List
抄送: Kirk Hall
主题: [cabfpub] Ballot 194 - Effective Date of Ballot 193 Provisions is in
the VOTING period (ends April 16)

 

Reminder: Ballot 194 -  Effective Date of Ballot 193 Provisions is in the
voting period (ends April 16)

 

Ballot 194 �C Effective Date of Ballot 193 Provisions

 

Purpose of Ballot: Recent Ballot 193 reduced the maximum period for
certificates and for reuse of vetting data for DV and OV certificates from
39 months to 825 days.  The effective date for reducing the maximum validity
period of certificates was specified as March 1, 2018, but no effective date
was specified for when the reduction of the maximum period for reuse of
vetting data becomes effective.

 

It was the intention of the authors of Ballot 193 that the effective date
for reducing the maximum period for reuse of vetting data under BR 4.2.1
would also be March 1, 2018.  This ballot is intended to clarify that
intention.  The ballot also makes these changes retroactive to the effective
date of Ballot 193 so there is no gap period.

 

Ballot 193 is in the Review Period (which will end on April 22, 2017), and
has not yet taken effect.  Bylaw 2.3 states that Ballots should include a
“redline or comparison showing the set of changes from the Final Guideline
section(s) intended to become a Final Maintenance Guideline” and that
“[s]uch redline or comparison shall be made against the Final Guideline
section(s) as they exist at the time a ballot is proposed”.

 

To avoid confusion, this Ballot will show the proposed changes to BR 4.2.1
will be presented two ways: (1) a comparison of the changes to BR 4.2.1 as
it existed before Ballot 193 (which is as BR 4.2.1 exists at this time this
ballot is proposed), and also (2) a comparison of the changes to BR 4.2.1 as
it will exist after the Review Period for Ballot 193 is completed (assuming
no Exclusion Notices are filed).

 

The following motion has been proposed by Chris Bailey of Entrust Datacard
and endorsed by Ben Wilson of DigiCert, and Wayne Thayer of GoDaddy to
introduce new Final Maintenance Guidelines for the "Baseline Requirements
Certificate Policy for the Issuance and Management of Publicly-Trusted
Certificates" (Baseline Requirements) and the "Guidelines for the Issuance
and Management of Extended Validation Certificates" (EV Guidelines).

 

-- MOTION BEGINS -- 

 

Ballot Section 1

 

BR 4.2.1 is amended to read as follows:

 

[Ballot amendments shown against BR 4.2.1 as it currently exists without the
changes adopted in Ballot 193]

 

BR 4.2.1. Performing Identification and Authentication Functions

 

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 order to comply
with these Requirements and the CA’s Certificate Policy and/or
Certification Practice Statement. In cases where the certificate request
does not contain all the necessary information about the Applicant, the CA
SHALL obtain the remaining information from the Applicant or, having
obtained it from a reliable, independent, third�\party data source, confirm
it with the Applicant. The CA SHALL establish and follow a documented
procedure for verifying all data requested for inclusion in the Certificate
by the Applicant.

 

Applicant information MUST include, but not be limited to, at least one
Fully�\Qualified Domain Name or IP address to be included in the
Certificate’s SubjectAltName extension.

 

Section 6.3.2 limits the validity period of Subscriber Certificates. The CA
MAY use the documents and data provided in Section 3.2 to verify certificate
information, provided that: the CA obtained the data or document from a
source specified under Section 3.2 no more than thirty�\nine (39) months
prior to issuing the Certificate.

 

(1) Prior to March 1, 2018, the CA obtained the data or document from a
source specified under Section 3.2 no more than 39 months prior to issuing
the Certificate; and

 

(2) On or after March 1, 2018, the CA obtained the data or document from a
source specified under Section 3.2 no more than 825 days prior to issuing
the Certificate. 

 

The CA SHALL develop, maintain, and implement documented procedures that
identify and require additional verification activity for High Risk
Certificate Requests prior to the Certificate’s approval, as reasonably
necessary to ensure that such requests are properly verified under these
Requirements.

 

If a Delegated Third Party 

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

[Ryan Sleevi via Public]

On Thu, Apr 13, 2017 at 7:58 PM, Kirk Hall via Public 
wrote:

> The CA does not have to revet Subscribers again until the prior data
> expires according to the normal rules for re-use of data.
>

Kirk,

This is a misreading of the BRs. You do need to reverify the information,
using the existing data. This has been stated multiple times. If you're
doing something else, please stop, immediately.


>
>
> As Gerv said on the call today, it will be a disincentive for CAs ever to
> vote for incremental change in validation methods if the changes always
> take effect immediately, and wipe out the CA’s ability to re-use data that
> was properly collected according to the prior rules and is still in the
> permitted re-use period.  I don’t think anyone intended that result when we
> came up with Ballot 169 and now Ballot 190.
>

Yes. We did. Because the existing methods are insecure, have lead to known
issues, and for which absolutely should not be relied upon for another
three years before CAs take meaningful steps to address their insecure
practices.

I can understand that you may wish to continue insecure practices. The goal
was to clarify that CAs should have better security, and should do so
promptly, considering we spent two years discussing changes after a year of
reporting the security issue before CAs took that matter seriously. We
proposed a phase in to allow CAs to adopt that (March 1, 2017). At that
time, any information obtained using the old methods that is not
used/acceptable under the new methods MUST be reissued.

The goal was to improve security. Section 2 actively undoes those years of
progress.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

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

[Ryan Sleevi via Public]

On Thu, Apr 13, 2017 at 7:53 PM, Kirk Hall 
wrote:

> Ryan, you weaken your case when you are patronizing to people.  If you
> don’t want to respond to my question (why not include legislative Notes on
> transition rules to the BRs right where they apply, as is commonly done),
> that’s your right, but again you weaken your case.
>

Kirk,

If this was the ballot you were proposing, and I agreed with your goals, I
absolutely agree it would be useful to help you find the appropriate
language. Unfortunately, this is neither. Importantly for the discussion on
the list, it's not necessary to help you understand the issues, if other
people - such as Peter - clearly do. Importantly, if Jeremy understands
these issues, then it's sufficient. If you disagree with those changes,
which you have yet to address, and if your support for such changes was
necessary to adopt the ballot, then I agree, it'd be worthwhile to attempt
to explain to you again the nature of these issues.

I have tried a considerable number of ways to explain to you. It's clear
that, whether intentional or not, my explanations will not help you. Peter
clearly understands the set of concerns and issues, and so it's reasonable
to conclude at least some people find understanding on this issue, even if
you may not. That's sufficient to make progress, even if it may leave you
confused or unsatisfied. Given that your suggestions have, so far, been
unproductive, it doesn't seem worthwhile for you and I to continue
discussing this matter, other than to highlight to you, in your role as
Chair, the reminder that these are not legislative texts, but technical
specifications, and the need and importance of both precession and
capturing in the text.


> Yes, that will resolve ONE set of transition rules from ONE ballot – but
> what do we do when we have another ballot that amends the same section?
> And then another?  (Gerv gave a good example of this possibility this
> morning relating to the .well-known validation rule as you recall).  Do we
> keep adding transition rules and effective dates over and over again to the
> same section?  That makes no sense, and is not generally how rule sets are
> amended and codified.
>

I'm sorry this does not make sense to you. It's especially unfortunate,
because as I pointed out, this is exactly what the Forum has done and
continued to do.

As I mentioned to you on the call, we remain opposed to the very concept of
reusing the validation status - rather than the validation data. This is in
the effort of security.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

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

[Kirk Hall via Public]

Ryan, you weaken your case when you are patronizing to people.  If you don’t 
want to respond to my question (why not include legislative Notes on transition 
rules to the BRs right where they apply, as is commonly done), that’s your 
right, but again you weaken your case.

Peter made an interesting suggestion that we keep layering on transition rules 
into the BRs themselves – here is his example:


In section 7.1.4.2, replace the last sentence (which currently reads " CAs 
SHALL NOT include a Domain Name or IP Address in a Subject attribute except as 
specified in Sections 3.2.2.4 or 3.2.2.5.”) with something like:



“CAs MUST NOT include Domain Name or IP Address in a Subject Attribute unless 
it has been verified using a procedure covered in section 3.2.2.4 or 3.2.2.5 of 
the Baseline Requirements that were in effect at the time of verification,  
Such verification MUST have occurred no more than 39 months prior to 
certificate issuance if the issuance occurs before 1 March 2018.  Such 
verification MUST have occurred no more than 825 days prior to certificate 
issuance if the issuance occurs on or after 1 March 2018.”

Yes, that will resolve ONE set of transition rules from ONE ballot – but what 
do we do when we have another ballot that amends the same section?  And then 
another?  (Gerv gave a good example of this possibility this morning relating 
to the .well-known validation rule as you recall).  Do we keep adding 
transition rules and effective dates over and over again to the same section?  
That makes no sense, and is not generally how rule sets are amended and 
codified.

From: Ryan Sleevi [mailto:sle...@google.com]
Sent: Thursday, April 13, 2017 3:12 PM
To: Kirk Hall 
Cc: CA/Browser Forum Public Discussion List 
Subject: [EXTERNAL]Re: [cabfpub] Ballot 190: Domain Validation



On Thu, Apr 13, 2017 at 6:05 PM, Kirk Hall 
> wrote:
Can you explain why you oppose including Sec. 2 of Ballot 190 as a Note at the 
end of BR 3.2.2.4 as updated?  This is commonly done for rule sets around the 
world, and is the simplest and easiest way to proceed.

I thought your concern was making sure that someone who looked at the updated 
BRs would see what transition rules had been adopted, and would not have to go 
back to Ballot 190 to find out.  A Notice at the end of BR 3.2.2.4 would 
accomplish that.

It would be very helpful to the Forum if you would consider alternatives to the 
exact outcome you want, and evaluate other options that will meet your concerns 
and also the concerns and opinions of other members.  Right now, it’s hard to 
understand why you are not showing any flexibility.

Kirk,

Flexibility on ambiguity is not flexibility, it's foolishness. I can understand 
that it may be difficult for you to understand the set of concerns, but I think 
you're unduly offering suggestions on something that Jeremy is more than 
capable of addressing. It's unclear why you're attempting to propose a 
particular solution, rather than allow him, as the ballot author, to understand 
these concerns, as he no doubt does, and incorporate them.

If you're concerned about ballots you may propose running into the same issue, 
then if you were to propose a ballot that suffers from the same problem here, 
I'm more than happy to take the time with you, including on the phone if 
necessary and helpful for you, to explain these concerns to your satisfaction. 
However, I think you're unduly presenting a solution that is insufficient, but 
also irrelevant to the task at hand.

I think there's enough context on this list for Jeremy to understand the 
concerns and address them. And I'm sure you agree that making progress is more 
important than satisfying your understanding.

All the best
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] RFC5280-related Ballot - For Discussion

[Ryan Sleevi via Public]

On Thu, Apr 13, 2017 at 6:30 PM, Geoff Keating  wrote:
>
> Presumably the new OID would be used for EV, too.
>

If we still recognize EV by the time such an OID was deployed :)
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 190: Domain Validation

[Ryan Sleevi via Public]

On Thu, Apr 13, 2017 at 6:05 PM, Kirk Hall 
wrote:

> Can you explain why you oppose including Sec. 2 of Ballot 190 as a Note at
> the end of BR 3.2.2.4 as updated?  This is commonly done for rule sets
> around the world, and is the simplest and easiest way to proceed.
>
>
>
> I thought your concern was making sure that someone who looked at the
> updated BRs would see what transition rules had been adopted, and would not
> have to go back to Ballot 190 to find out.  A Notice at the end of BR
> 3.2.2.4 would accomplish that.
>
>
>
> It would be very helpful to the Forum if you would consider alternatives
> to the exact outcome you want, and evaluate other options that will meet
> your concerns and also the concerns and opinions of other members.  Right
> now, it’s hard to understand why you are not showing any flexibility.
>

Kirk,

Flexibility on ambiguity is not flexibility, it's foolishness. I can
understand that it may be difficult for you to understand the set of
concerns, but I think you're unduly offering suggestions on something that
Jeremy is more than capable of addressing. It's unclear why you're
attempting to propose a particular solution, rather than allow him, as the
ballot author, to understand these concerns, as he no doubt does, and
incorporate them.

If you're concerned about ballots you may propose running into the same
issue, then if you were to propose a ballot that suffers from the same
problem here, I'm more than happy to take the time with you, including on
the phone if necessary and helpful for you, to explain these concerns to
your satisfaction. However, I think you're unduly presenting a solution
that is insufficient, but also irrelevant to the task at hand.

I think there's enough context on this list for Jeremy to understand the
concerns and address them. And I'm sure you agree that making progress is
more important than satisfying your understanding.

All the best
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 190: Domain Validation

[Ryan Sleevi via Public]

On Thu, Apr 13, 2017 at 5:56 PM, Kirk Hall 
wrote:

> While I still disagree with your personal interpretation – why can’t we do
> things the way other deliberative bodies do? – as I said before, I have no
> problem including “Notes” at the end of provisions that are not part of the
> BRs, but which inform readers of what the transition rules for a particular
> ballot are.  The notes can then be dropped once they are no longer
> relevant.
>

You're again inventing a new process that is inconsistent with how we've
handled every other ballot, and introduces unnecessary ambiguity.

I would hope Jeremy would see how inadvisible this suggestion is. To save
trouble - We would vote No against the process you've described. Would you
vote No if we handled it like every other ballot?


> So we can include Section 2 of Ballot 190 as a “Note” after BR 3.2.2.4,
> which is the section affected by the transition rule, then remove it once
> the transition period is over – everyone will see that in the compiled
> version of the updated BRs.  Sounds like a solution we can all live with.
>

Unfortunately, it seems you continue to misunderstand the concerns, and I'm
not sure I can sufficiently explain them to you. Jeremy tends to understand
these issues, so I'm sure he would have no problem addressing these
concerns in a way that meaningfully work.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 190: Domain Validation

[Kirk Hall via Public]

While I still disagree with your personal interpretation – why can’t we do 
things the way other deliberative bodies do? – as I said before, I have no 
problem including “Notes” at the end of provisions that are not part of the 
BRs, but which inform readers of what the transition rules for a particular 
ballot are.  The notes can then be dropped once they are no longer relevant.

So we can include Section 2 of Ballot 190 as a “Note” after BR 3.2.2.4, which 
is the section affected by the transition rule, then remove it once the 
transition period is over – everyone will see that in the compiled version of 
the updated BRs.  Sounds like a solution we can all live with.

From: Ryan Sleevi [mailto:sle...@google.com]
Sent: Thursday, April 13, 2017 2:36 PM
To: Kirk Hall 
Cc: CA/Browser Forum Public Discussion List 
Subject: [EXTERNAL]Re: [cabfpub] Ballot 190: Domain Validation



On Thu, Apr 13, 2017 at 5:07 PM, Kirk Hall 
> wrote:
Can you explain what part of Ballot 190 (shown below) is not clear to you?  Do 
you have edits you would suggest that would “fix” the problem you see?

From my earlier message, as it looks like you may have missed it:

"If you want to accomplish this, however, you would need to update Section 
4.2.1 to specify how that process works. Otherwise, Section 4.2.1 will govern, 
and Section 2 of this ballot will have no effect due to its ambiguity and lack 
of modification to the document."

We have a section in the document that governs this. It's Section 4.2.1.
We have a section in the document that calls out effective dates. It's Section 
1.2.1 and 1.2.2.
We have a defined process in our bylaws to modify those sections. Let's follow 
it, and not invent new procedures ad hoc.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 190: Domain Validation

[Ryan Sleevi via Public]

On Thu, Apr 13, 2017 at 5:07 PM, Kirk Hall 
wrote:

> Can you explain what part of Ballot 190 (shown below) is not clear to
> you?  Do you have edits you would suggest that would “fix” the problem you
> see?
>
>
>
> *Ballot Section 1* [Readopts various domain validation methods of BR
> 3.2.2.4]
>
>
>
> *Ballot Section 2*
>
>
>
> The provisions of Ballot Section 1 will apply only to the validation of
> domain names occurring after this Ballot 190’s effective date.  Validation
> of domain names that occurs before this Ballot’s effective date and the
> resulting validation data may continue to be used for the periods specified
> in BR 4.2.1 and EVGL 11.14.3 so long as the validations were conducted in
> compliance with the BR Section 3.2.2.4 validation methods in effect at the
> time of each validation.
>

Sure. I download the BRs. Where do I find out about Section 2?
I'm an auditor. I'm examining the BRs. Where do I find out about Section 2?

Section 2 needs to be in the BRs.


>
>
> While the BRs may not be a legal document the same as a state or federal
> statute, it makes sense that we would follow the same procedures in their
> adoption and codification that are used by legislatures (county
> commissions, city halls, etc.) around the world.
>

Kirk, we discussed this at the Forum, and agreed that was an inappropriate
conclusion via consensus. This was during the talk about the role and
nature of the Forum, and there was broad consensus these were technical
documents, developed using technical document procedures.

We don't slip in hidden clauses outside that requires exceptional
knowledge. They go in the documents.


> Your interpretation is your own, but it’s not binding on the Forum, and
> it’s not correct.
>

Nothing is ever binding on the Forum. It's binding on the root store side,
and I'm more than happy to reject any audits that don't include this
interpretation. Let's avoid that and try to reach consensus by actually
codifying in the documents that are produced.

This is not the first time you've suggested these documents (and our
bylaws) are subject to interpretation. The only thing subject to contract
law is our IP policy. Everything else _has_ an interpretation, and it's not
defined by you.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 190: Domain Validation

[Kirk Hall via Public]

Can you explain what part of Ballot 190 (shown below) is not clear to you?  Do 
you have edits you would suggest that would “fix” the problem you see?

Ballot Section 1 [Readopts various domain validation methods of BR 3.2.2.4]

Ballot Section 2

The provisions of Ballot Section 1 will apply only to the validation of domain 
names occurring after this Ballot 190’s effective date.  Validation of domain 
names that occurs before this Ballot’s effective date and the resulting 
validation data may continue to be used for the periods specified in BR 4.2.1 
and EVGL 11.14.3 so long as the validations were conducted in compliance with 
the BR Section 3.2.2.4 validation methods in effect at the time of each 
validation.

While the BRs may not be a legal document the same as a state or federal 
statute, it makes sense that we would follow the same procedures in their 
adoption and codification that are used by legislatures (county commissions, 
city halls, etc.) around the world.

Your interpretation is your own, but it’s not binding on the Forum, and it’s 
not correct.

From: Ryan Sleevi [mailto:sle...@google.com]
Sent: Thursday, April 13, 2017 2:00 PM
To: Kirk Hall 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [EXTERNAL]Re: [cabfpub] Ballot 190: Domain Validation



On Thu, Apr 13, 2017 at 4:45 PM, Kirk Hall 
> wrote:
Your analysis below is not correct.   The “law” in the CA/Browser Forum is what 
is approved by the members in a Ballot (all of it – in Ballot 190, that 
includes both Section 1 and Section 2 – both sections have equal validity and 
applicability because both were adopted by the members at the same time.)

I'm sorry Kirk, but your analysis is not correct.

What suggestion of the documents are you suggesting Section 2 modifies? How are 
you suggesting members audit it, if not part of the document? How are you 
suggesting future Ballots reform it?


In contrast, the BRs are just a compilation of those portions of prior adopted 
Ballots that have long-term applicability to members.  It’s a mistake to junk 
up the BRs with lots of effective dates and transition rule that will expire, 
and it’s unnecessary.  Again, the adopted ballots of the Forum are the “law” – 
all sections of the ballots equally – and not the BR compilations themselves.  
I think Google’s Legal Department will agree.

Kirk, I will again emphasize to you the Baseline Requirements are not a legal 
document. Your legal analysis is appreciated, but not relevant. These are 
technical standards. They belong in the standards.

We could put ballot transition rules in BRs themselves (for Ballot 190, move 
from Section 2 to Section 1 and make part of BR 3.2.2.4), but I would rather 
not – then the transition rules are no longer relevant (because they are 
time-based and will expire), they have to be pulled out again by a later ballot 
– not useful.  The transition rules will exist in Section 2 of the adopted 
Ballot 190 itself, and that is sufficient.

I strongly disagree here.

Another option is to add transition rules like Ballot 190, Section 2 to the BRs 
as “Notes” to BR 3.2.2.4 that are not part of BR 3.2.2.4, and that can later be 
removed by the BRs compiler without a further ballot once the transition rules 
are no longer relevant (because all validation data from before the effective 
date of Ballot 190 will have expired).  That’s what some legislatures do, and I 
wouldn’t object to that.

They are either normative parts of the technical standards or they are not. If 
they want to have force, they are normative.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

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

[Ryan Sleevi via Public]

On Thu, Apr 13, 2017 at 4:45 PM, Kirk Hall 
wrote:

> Your analysis below is not correct.   The “law” in the CA/Browser Forum is
> what is approved by the members in a Ballot (all of it – in Ballot 190,
> that includes both Section 1 and Section 2 – both sections have equal
> validity and applicability because both were adopted by the members at the
> same time.)
>

I'm sorry Kirk, but your analysis is not correct.

What suggestion of the documents are you suggesting Section 2 modifies? How
are you suggesting members audit it, if not part of the document? How are
you suggesting future Ballots reform it?



> In contrast, the BRs are just a compilation of those portions of prior
> adopted Ballots that have long-term applicability to members.  It’s a
> mistake to junk up the BRs with lots of effective dates and transition rule
> that will expire, and it’s unnecessary.  Again, the adopted ballots of the
> Forum are the “law” – all sections of the ballots equally – and not the BR
> compilations themselves.  I think Google’s Legal Department will agree.
>

Kirk, I will again emphasize to you the Baseline Requirements are not a
legal document. Your legal analysis is appreciated, but not relevant. These
are technical standards. They belong in the standards.


> We could put ballot transition rules in BRs themselves (for Ballot 190,
> move from Section 2 to Section 1 and make part of BR 3.2.2.4), but I would
> rather not – then the transition rules are no longer relevant (because they
> are time-based and will expire), they have to be pulled out again by a
> later ballot – not useful.  The transition rules will exist in Section 2 of
> the adopted Ballot 190 itself, and that is sufficient.
>

I strongly disagree here.


> Another option is to add transition rules like Ballot 190, Section 2 to
> the BRs as “Notes” to BR 3.2.2.4 that are not part of BR 3.2.2.4, and that
> can later be removed by the BRs compiler without a further ballot once the
> transition rules are no longer relevant (because all validation data from
> before the effective date of Ballot 190 will have expired).  That’s what
> some legislatures do, and I wouldn’t object to that.
>

They are either normative parts of the technical standards or they are not.
If they want to have force, they are normative.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 189 (revised) - Amend Section 6.1.7 of Baseline Requirements

[Frank Corday via Public]

Trustwave votes Yes to 189

From: Public > 
on behalf of Dimitris Zacharopoulos via Public 
>
Reply-To: CA/Browser Forum Public Discussion List 
>
Date: Wednesday, 5 April, 2017 at 03:46
To: "public@cabforum.org" 
>
Cc: Dimitris Zacharopoulos >
Subject: [cabfpub] Ballot 189 (revised) - Amend Section 6.1.7 of Baseline 
Requirements


After the recent discussion, the ballot is now updated with simpler language. 
Voting starts tomorrow April 6th.

Dimitris.
Ballot 189 - Amend Section 6.1.7 of Baseline Requirements

The following motion has been proposed by Dimitris Zacharopoulos of HARICA and 
endorsed by Bruce Morton of Entrust and Jeremy Rowley of Digicert

Background:

Section 6.1.7 of the Baseline Requirements states that the Root CA Private Keys 
MUST NOT be used to sign end-entity certificates, with some exceptions. It is 
unclear if this exception list includes end-entity certificates with EKU 
id-kp-timeStamping. This ballot attempts to clarify two things:

  1.  that it affects Root Keys in a hierarchy that issues SSL Certificates and
  2.  that it does not include time stamping certificates in the exception list.

It also clears the exception language for 1024-bit RSA Subscriber Certificates 
and testing products with Certificates issued by a Root.

-- MOTION BEGINS --

Current section 6.1.7

Root CA Private Keys MUST NOT be used to sign Certificates except in the 
following cases:

  1.  Self-signed Certificates to represent the Root Certificate itself;
  2.  Certificates for Subordinate CAs and Cross Certificates;
  3.  Certificates for infrastructure purposes (e.g. administrative role 
certificates, internal CA operational device certificates, and OCSP Response 
verification Certificates);
  4.  Certificates issued solely for the purpose of testing products with 
Certificates issued by a Root CA; and
  5.  Subscriber Certificates, provided that:

 *   The Root CA uses a 1024-bit RSA signing key that was created prior to 
the Effective Date;
 *   The Applicant’s application was deployed prior to the Effective Date;
 *   The Applicant’s application is in active use by the Applicant or the 
CA uses a documented process to establish that the Certificate’s use is 
required by a substantial number of Relying Parties;
 *   The CA follows a documented process to determine that the Applicant’s 
application poses no known security risks to Relying Parties;
 *   The CA documents that the Applicant’s application cannot be patched or 
replaced without substantial economic outlay.
 *   The CA signs the Subscriber Certificate on or before June 30, 2016; and
 *   The notBefore field in the Subscriber Certificate has a date on or 
before June 30, 2016

Proposed section 6.1.7

Private Keys corresponding to Root Certificates MUST NOT be used to sign 
Certificates except in the following cases:

  1.  Self-signed Certificates to represent the Root CA itself;
  2.  Certificates for Subordinate CAs and Cross Certificates;
  3.  Certificates for infrastructure purposes (administrative role 
certificates, internal CA operational device certificates)
  4.  Certificates for OCSP Response verification;

These changes become Effective 30 days after the ballot passes.

-- MOTION ENDS --

The procedure for this ballot is as follows (exact start and end times may be 
adjusted to comply with applicable Bylaws and IPR Agreement):

BALLOT 189 Status: Amend BR 6.1.7


Start time (22:00 UTC)


End time (22:00 UTC)


Discussion (7 days)


30 March 2017


6 April 2017


Vote for approval (7 days)


6 April 2017


13 April 2017


If vote approves ballot: Review Period (Chair to send Review Notice) (30 days)
If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.
If no Exclusion Notices filed, ballot becomes effective at end of Review Period.
Votes must be cast by posting an on-list reply to this thread on the Public 
Mail List.


Upon filing of Review Notice by Chair


30 days after filing of Review Notice by Chair


From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
Guideline, such ballot will include a redline or comparison showing the set of 
changes from the Final Guideline section(s) intended to become a Final 
Maintenance Guideline, and need not include a copy of the full set of 
guidelines. Such redline or comparison shall be made against the Final 
Guideline section(s) as they exist at the time a ballot is proposed, and need 
not take into consideration other ballots that may be proposed subsequently, 
except as provided in Bylaw Section 2.3(j).

Votes must be cast by posting an on-list reply to this thread on the Public 
list. A vote in favor of the motion must indicate 

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

[Kirk Hall via Public]

Your analysis below is not correct.   The “law” in the CA/Browser Forum is what 
is approved by the members in a Ballot (all of it – in Ballot 190, that 
includes both Section 1 and Section 2 – both sections have equal validity and 
applicability because both were adopted by the members at the same time.)

In contrast, the BRs are just a compilation of those portions of prior adopted 
Ballots that have long-term applicability to members.  It’s a mistake to junk 
up the BRs with lots of effective dates and transition rule that will expire, 
and it’s unnecessary.  Again, the adopted ballots of the Forum are the “law” – 
all sections of the ballots equally – and not the BR compilations themselves.  
I think Google’s Legal Department will agree.

See the following concerning codification of US laws: 
https://en.wikipedia.org/wiki/United_States_Statutes_at_Large

*** Codification

Today, large portions of slip laws [for the Forum, our Ballots once they have 
been approved by the members] denominated as public laws are now drafted as 
amendments to the United States Code [for the Forum, the BRs and EVGL]. Once 
enacted into law, an Act will be published in the Statutes at Large [for the 
Forum, an updated version of the BRs or EVGL will be published] and will add 
to, modify, or delete some part of the United States Code [the BRs or EVGL]. 
Provisions of a public law [Ballot] that contains only enacting clauses, 
effective dates, and similar matters are not generally codified [i.e., those 
portions of a Forum Ballot such as Ballot 190, Section 2, would not be included 
in the BRs, but would still be valid and controlling]. ***

We could put ballot transition rules in BRs themselves (for Ballot 190, move 
from Section 2 to Section 1 and make part of BR 3.2.2.4), but I would rather 
not – then the transition rules are no longer relevant (because they are 
time-based and will expire), they have to be pulled out again by a later ballot 
– not useful.  The transition rules will exist in Section 2 of the adopted 
Ballot 190 itself, and that is sufficient.

Another option is to add transition rules like Ballot 190, Section 2 to the BRs 
as “Notes” to BR 3.2.2.4 that are not part of BR 3.2.2.4, and that can later be 
removed by the BRs compiler without a further ballot once the transition rules 
are no longer relevant (because all validation data from before the effective 
date of Ballot 190 will have expired).  That’s what some legislatures do, and I 
wouldn’t object to that.

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Thursday, April 13, 2017 10:02 AM
To: CA/Browser Forum Public Discussion List 
Cc: Ryan Sleevi 
Subject: [EXTERNAL]Re: [cabfpub] Ballot 190: Domain Validation



On Tue, Apr 11, 2017 at 4:46 PM, Jeremy Rowley via Public 
> wrote:

Ballot Section 2
This provisions of Ballot Section 1 will apply only to the validation of domain 
names occurring after this Ballot 190’s effective date.  Validation of domain 
names that occurs before this Ballot’s effective date and the resulting 
validation data may continue to be used for the periods specified in BR 4.2.1 
and EVGL 11.14.3 so long as the validations were conducted in compliance with 
the BR Section 3.2.2.4 validation methods in effect at the time of each 
validation.

As mentioned on today's call, this clause is not compatible with / creates a 
conflict with the Baseline Requirements.

Section 4.2.1 governs the reuse of previously obtained documents or data, but 
Section 3.2 explicitly requires that CAs validate and verify every certificate 
during issuance.

The clear intent from Section 2, as worded, is to extend this to allow CAs to 
not even verify the domains at the time of issuance. While understandable as to 
the goal, it's highly undesirable.

If you want to accomplish this, however, you would need to update Section 4.2.1 
to specify how that process works. Otherwise, Section 4.2.1 will govern, and 
Section 2 of this ballot will have no effect due to its ambiguity and lack of 
modification to the document.

I want to echo a strong opposition towards allowing the reuse of data or 
documents obtained under previous versions of the Baseline Requirements, much 
as in the discussion of Ballot 194. We are aware of multiple CAs who have 
relied on insecure methods here, and the idea that this information would be 
appropriate to continue issuing certificates for the next three years is an 
unacceptable security risk. We raised this issue to the Forum nearly three 
years ago at this point, and continuing for three more years is not good.

I encourage CAs to thoughtfully examine and articulate why they believe a 
phase-in is needed, on a per-section basis, so as to help better understand the 
impact relative to the security risk being introduced, and would encourage the 
ballot authors and co-sponsors to update Section 2 

Re: [cabfpub] [EXT] Ballot 189 - Amend Section 6.1.7 of Baseline Requirements

[Rick Andrews via Public]

Symantec votes YES

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Dimitris 
Zacharopoulos via Public
Sent: Thursday, March 30, 2017 9:23 AM
To: public@cabforum.org
Cc: Dimitris Zacharopoulos 
Subject: [EXT] [cabfpub] Ballot 189 - Amend Section 6.1.7 of Baseline 
Requirements

 

 

Ballot 189 - Amend Section 6.1.7 of Baseline Requirements 

The following motion has been proposed by Dimitris Zacharopoulos of HARICA and 
endorsed by Bruce Morton of Entrust and Jeremy Rowley of Digicert 

Background: 

Section 6.1.7 of the Baseline Requirements states that the Root CA Private Keys 
MUST NOT be used to sign end-entity certificates, with some exceptions. It is 
unclear if this exception list includes end-entity certificates with EKU 
id-kp-timeStamping. This ballot attempts to clarify two things: 

1.  that it affects Root Keys in a hierarchy that issues SSL Certificates 
and 

2.  that it does not include time stamping certificates in the exception 
list. 

It also clears the exception language for 1024-bit RSA Subscriber Certificates 
and testing products with Certificates issued by a Root. 

-- MOTION BEGINS -- 

Current section 6.1.7 

Root CA Private Keys MUST NOT be used to sign Certificates except in the 
following cases: 

1.  Self-signed Certificates to represent the Root Certificate itself; 

2.  Certificates for Subordinate CAs and Cross Certificates; 

3.  Certificates for infrastructure purposes (e.g. administrative role 
certificates, internal CA operational device certificates, and OCSP Response 
verification Certificates); 

4.  Certificates issued solely for the purpose of testing products with 
Certificates issued by a Root CA; and 

5.  Subscriber Certificates, provided that: 

a.   The Root CA uses a 1024-bit RSA signing key that was created prior to 
the Effective Date; 

b.  The Applicant’s application was deployed prior to the Effective Date; 

c.   The Applicant’s application is in active use by the Applicant or the 
CA uses a documented process to establish that the Certificate’s use is 
required by a substantial number of Relying Parties; 

d.  The CA follows a documented process to determine that the Applicant’s 
application poses no known security risks to Relying Parties; 

e.   The CA documents that the Applicant’s application cannot be patched or 
replaced without substantial economic outlay. 

f.   The CA signs the Subscriber Certificate on or before June 30, 2016; 
and 

g.  The notBefore field in the Subscriber Certificate has a date on or 
before June 30, 2016 

Proposed section 6.1.7 

Private Keys corresponding to Root Certificates that participate in a hierarchy 
that issues Certificates with an extKeyUsage extension that includes the value 
id-kp-serverAuth [RFC5280] MUST NOT be used to sign Certificates except in the 
following cases: 

1.  Self-signed Certificates to represent the Root CA itself; 

2.  Certificates for Subordinate CAs and Cross Certificates; 

3.  Certificates for infrastructure purposes (administrative role 
certificates, internal CA operational device certificates) 

4.  Certificates for OCSP Response verification; 

These changes become Effective 30 days after the ballot passes. 

-- MOTION ENDS -- 

The procedure for this ballot is as follows (exact start and end times may be 
adjusted to comply with applicable Bylaws and IPR Agreement): 


BALLOT 189 Status: Amend BR 6.1.7 

Start time (22:00 UTC) 

End time (22:00 UTC) 


Discussion (7 days) 

30 March 2017 

6 April 2017 


Vote for approval (7 days) 

6 April 2017 

13 April 2017 


If vote approves ballot: Review Period (Chair to send Review Notice) (30 days)
If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.
If no Exclusion Notices filed, ballot becomes effective at end of Review Period.
Votes must be cast by posting an on-list reply to this thread on the Public 
Mail List.

Upon filing of Review Notice by Chair

30 days after filing of Review Notice by Chair

>From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
>Guideline, such ballot will include a redline or comparison showing the set of 
>changes from the Final Guideline section(s) intended to become a Final 
>Maintenance Guideline, and need not include a copy of the full set of 
>guidelines. Such redline or comparison shall be made against the Final 
>Guideline section(s) as they exist at the time a ballot is proposed, and need 
>not take into consideration other ballots that may be proposed subsequently, 
>except as provided in Bylaw Section 2.3(j). 

Votes must be cast by posting an on-list reply to this thread on the Public 
list. A vote in favor of the motion must indicate a clear 'yes' in the 
response. A vote against must indicate a clear 'no' in the response. A vote to 
abstain must indicate a clear 'abstain' in the response. Unclear responses will 
not be counted. 

Re: [cabfpub] BR clarification re: test certificates

[Ryan Sleevi via Public]

On Thu, Apr 13, 2017 at 2:19 PM, Curt Spann via Public 
wrote:
>
> > * revoked = unexpired, and present in either/both of CRL and OCSP
> CES: Did you really intended for the ‘either/both’ instead of just ‘both'?
> I don’t think it would be a good idea to only have a certificate’s revoked
> status in one form the of the revocation data and not the other.
>

This mostly stems from the fact that 7.1.2.3 allows for omission of the
cRLDistributionPoints (Item b), but requires OCSP (Item c), unless the
server supports stapling.

7.1.2.2 requires the cRLDistributionPoints for sub-CAs (which can _also_ be
server certificates, since we don't restrict the subjectAltName on such
certificates), but also allows (strangely) the omission of OCSP for
stapling (I suppose it's presuming OCSP multi-staple)?

Happy to take a stab at correcting both of these via Ballot, since I
suspect the logical intent, as reflected in your question, is that:

1) CRLs MUST always be present on intermediates
2) OCSP MUST always be present on intermediates (or are we really
advocating for the terribad multi-staple?)
3) CRLs MAY be present on end-entity certificates
4) OCSP MUST be present on end-entity certificates, unless the server
supports stapling
5) CRLs and OCSP responses MUST return the same revocation status
information (presumably, either in Section 2.1 or Section 4.10.1 / 4.10.2)
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] BR clarification re: test certificates

[Curt Spann via Public]

Hi Gerv,

Comment inline below:
> On Apr 10, 2017, at 8:13 AM, Gervase Markham via Public  
> wrote:
> 
> Section 2.2 of the BRs says:
> 
> "The CA SHALL host test Web pages that allow Application Software
> Suppliers to test their software with Subscriber Certificates that chain
> up to each publicly trusted Root Certificate. At a minimum, the CA SHALL
> host separate Web pages using Subscriber Certificates that are
> (i) valid,
> (ii) revoked, and
> (iii) expired."
> 
> Mozilla requires these 3 URLs as part of the annual updates to the
> CCADB. We want to make it clear (and have done so on
> https://wiki.mozilla.org/CA:CommonCADatabase#How_To_Provide_Annual_Updates
> ) that we consider this requirement to be more fully specified as:
> 
> * valid   = unexpired and unrevoked
> * revoked = unexpired, and present in either/both of CRL and OCSP
CES: Did you really intended for the ‘either/both’ instead of just ‘both'? I 
don’t think it would be a good idea to only have a certificate’s revoked status 
in one form the of the revocation data and not the other.
> * expired = notAfter less than the current day, and unrevoked
> 
> In particular, please make sure your revoked certificate is _un_expired.
> 
> If people think the BRs need updating to clarify this, we could
> draft
> a
> ballot.
> 
> Gerv
> ___
> Public mailing list
> Public@cabforum.org
> https://angler.apple.com:443/proxy?url=gxCaAAV5X6eKqFUJxGfIVBNUhqhb82I06KhtC3s6mVaT7CnJeoQYl2Hw0Iz5OpBhU7whHXfQM6QxzlyxfKJd72IhNmeFA102UeUZvEL9%2BSA%3D=true=https%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fpublic

Cheers,
Curt
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 196: Define "Audit Period"

[Jos Purvis (jopurvis) via Public]

Cisco votes YES on 196.

 

-- 

Jos Purvis (jopur...@cisco.com)

.:|:.:|:. cisco systems | Cryptographic Services

PGP: 0xFD802FEE07D19105  | +1 919.991.9114 (desk)

 

 

From: Public  on behalf of Gervase Markham via 
Public 
Reply-To: CA/Browser Forum Public Discussion List 
Date: Monday, 3 April, 2017 at 14:05 
To: CABFPub 
Cc: Gervase Markham 
Subject: [cabfpub] Ballot 196: Define "Audit Period"

 

Ballot 196 - Define "Audit Period"

Purpose of Ballot: It appears that CAs are sometimes confused by the phrase 
Audit Period. This ballot adds a definition of that phrase to the BRs, in the 
hope of heading off any further misunderstandings. 

The following motion has been proposed by Gervase Markham of Mozilla and 
endorsed by Ryan Sleevi of Google and Jody Cloutier of Microsoft:


-- MOTION BEGINS -- 

Add the following definition to section 1.6.1 of the Baseline Requirements:

Audit Period: In a period-of-time audit, the period between the first day 
(start) and the last day of operations (end) covered by the auditors in their 
engagement. (This is not the same as the period of time when the auditors are 
on-site at the CA.) The coverage rules and maximum length of audit periods are 
defined in section 8.1.
-- MOTION ENDS -- 




The procedure for approval of this Final Maintenance Guideline ballot is as 
follows (exact start and end times may be adjusted to comply with applicable 
Bylaws and IPR Agreement):

 

BALLOT 196Status: Final Maintenance GuidelineStart time (23:00 UTC)End time 
(23:00 UTC)
Discussion (7 to 14 days)3rd April10th April
Vote for approval (7 days)10th April17th April
If vote approves ballot: Review Period (Chair to send Review Notice) (30 days). 
 If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.If no Exclusion Notices filed, ballot becomes effective at end of 
Review Period.Upon filing of Review Notice by Chair30 days after filing of 
Review Notice by Chair

 

>From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
>Guideline, such ballot will include a redline or comparison showing the set of 
>changes from the Final Guideline section(s) intended to become a Final 
>Maintenance Guideline, and need not include a copy of the full set of 
>guidelines.  Such redline or comparison shall be made against the Final 
>Guideline section(s) as they exist at the time a ballot is proposed, and need 
>not take into consideration other ballots that may be proposed subsequently, 
>except as provided in Bylaw Section 2.3(j).

 

Votes must be cast by posting an on-list reply to this thread on the Public 
list.  A vote in favor of the motion must indicate a clear 'yes' in the 
response. A vote against must indicate a clear 'no' in the response. A vote to 
abstain must indicate a clear 'abstain' in the response. Unclear responses will 
not be counted. The latest vote received from any representative of a voting 
member before the close of the voting period will be counted. Voting members 
are listed here: https://cabforum.org/members/ 

In order for the motion to be adopted, two thirds or more of the votes cast by 
members in the CA category and greater than 50% of the votes cast by members in 
the browser category must be in favor.  Quorum is shown on CA/Browser Forum 
wiki.  Under Bylaw 2.2(g), at least the required quorum number must participate 
in the ballot for the ballot to be valid, either by voting in favor, voting 
against, or abstaining.



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



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] RFC5280-related Ballot - For Discussion

[Ryan Sleevi via Public]

On Thu, Apr 13, 2017 at 12:58 PM, Ben Wilson via Public  wrote:

> I can do that for the longer names, but that takes time to implement and
> then for support in browsers to  develop.  I’ll look at our CABF OID tree
> and figure out how to  branch out an OID arc for these two (commonName and
> organizationName).
>

For what it's worth, we have no plans to support such newly-defined OIDs
within our Certificate Processing code (and have recently begun deprecating
support for commonName). It is correct that if CAs wish to use a longer
organizationName, creating a new Attribute OID with a defined value without
such an upper-bound is appropriate. However, as we do not afford special UI
treatment to organizationally-validated certificates, nor do we have plans
to do so, it would not be part of our development roadmap to afford any
special treatment to this UI.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

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

[Peter Miškovič via Public]

Disig votes „YES“.

Regards
Peter

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Chris Bailey via 
Public
Sent: Sunday, April 2, 2017 10:27 PM
To: public@cabforum.org
Cc: Chris Bailey 
Subject: [cabfpub] Ballot 194 – Effective Date of Ballot 193 Provisions

Ballot 194 – Effective Date of Ballot 193 Provisions

Purpose of Ballot: Recent Ballot 193 reduced the maximum period for 
certificates and for reuse of vetting data for DV and OV certificates from 39 
months to 825 days.  The effective date for reducing the maximum validity 
period of certificates was specified as March 1, 2018, but no effective date 
was specified for when the reduction of the maximum period for reuse of vetting 
data becomes effective.

It was the intention of the authors of Ballot 193 that the effective date for 
reducing the maximum period for reuse of vetting data under BR 4.2.1 would also 
be March 1, 2018.  This ballot is intended to clarify that intention.  The 
ballot also makes these changes retroactive to the effective date of Ballot 193 
so there is no gap period.

Ballot 193 is in the Review Period (which will end on April 22, 2017), and has 
not yet taken effect.  Bylaw 2.3 states that Ballots should include a “redline 
or comparison showing the set of changes from the Final Guideline section(s) 
intended to become a Final Maintenance Guideline” and that “[s]uch redline or 
comparison shall be made against the Final Guideline section(s) as they exist 
at the time a ballot is proposed”.

To avoid confusion, this Ballot will show the proposed changes to BR 4.2.1 will 
be presented two ways: (1) a comparison of the changes to BR 4.2.1 as it 
existed before Ballot 193 (which is as BR 4.2.1 exists at this time this ballot 
is proposed), and also (2) a comparison of the changes to BR 4.2.1 as it will 
exist after the Review Period for Ballot 193 is completed (assuming no 
Exclusion Notices are filed).

The following motion has been proposed by Chris Bailey of Entrust Datacard and 
endorsed by Ben Wilson of DigiCert, and Wayne Thayer of GoDaddy to introduce 
new Final Maintenance Guidelines for the "Baseline Requirements Certificate 
Policy for the Issuance and Management of Publicly-Trusted Certificates" 
(Baseline Requirements) and the "Guidelines for the Issuance and Management of 
Extended Validation Certificates" (EV Guidelines).

-- MOTION BEGINS --

Ballot Section 1

BR 4.2.1 is amended to read as follows:

[Ballot amendments shown against BR 4.2.1 as it currently exists without the 
changes adopted in Ballot 193]

BR 4.2.1. Performing Identification and Authentication Functions

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 order to comply with these 
Requirements and the CA’s Certificate Policy and/or Certification Practice 
Statement. In cases where the certificate request does not contain all the 
necessary information about the Applicant, the CA SHALL obtain the remaining 
information from the Applicant or, having obtained it from a reliable, 
independent, third‐party data source, confirm it with the Applicant. The CA 
SHALL establish and follow a documented procedure for verifying all data 
requested for inclusion in the Certificate by the Applicant.

Applicant information MUST include, but not be limited to, at least one 
Fully‐Qualified Domain Name or IP address to be included in the Certificate’s 
SubjectAltName extension.

Section 6.3.2 limits the validity period of Subscriber Certificates. The CA MAY 
use the documents and data provided in Section 3.2 to verify certificate 
information, provided that: the CA obtained the data or document from a source 
specified under Section 3.2 no more than thirty‐nine (39) months prior to 
issuing the Certificate.

(1) Prior to March 1, 2018, the CA obtained the data or document from a source 
specified under Section 3.2 no more than 39 months prior to issuing the 
Certificate; and

(2) On or after March 1, 2018, the CA obtained the data or document from a 
source specified under Section 3.2 no more than 825 days prior to issuing the 
Certificate.

The CA SHALL develop, maintain, and implement documented procedures that 
identify and require additional verification activity for High Risk Certificate 
Requests prior to the Certificate’s approval, as reasonably necessary to ensure 
that such requests are properly verified under these Requirements.

If a Delegated Third Party fulfills any of the CA’s obligations under this 
section, the CA SHALL verify that the process used by the Delegated Third Party 
to identify and further verify High Risk Certificate Requests provides at least 
the same level of assurance as the CA’s own processes.


[Ballot amendments shown against BR 4.2.1 as it existed after Ballot 193 was 
approved]

BR 4.2.1. Performing Identification and 

Re: [cabfpub] Ballot 190: Domain Validation

[Ryan Sleevi via Public]

On Tue, Apr 11, 2017 at 4:46 PM, Jeremy Rowley via Public <
public@cabforum.org> wrote:

>
> *Ballot Section 2*
>
> This provisions of Ballot Section 1 will apply only to the validation of
> domain names occurring after this Ballot 190’s effective date.  Validation
> of domain names that occurs before this Ballot’s effective date and the
> resulting validation data may continue to be used for the periods specified
> in BR 4.2.1 and EVGL 11.14.3 so long as the validations were conducted in
> compliance with the BR Section 3.2.2.4 validation methods in effect at the
> time of each validation.
>

As mentioned on today's call, this clause is not compatible with / creates
a conflict with the Baseline Requirements.

Section 4.2.1 governs the reuse of previously obtained documents or data,
but Section 3.2 explicitly requires that CAs validate and verify every
certificate during issuance.

The clear intent from Section 2, as worded, is to extend this to allow CAs
to not even verify the domains at the time of issuance. While
understandable as to the goal, it's highly undesirable.

If you want to accomplish this, however, you would need to update Section
4.2.1 to specify how that process works. Otherwise, Section 4.2.1 will
govern, and Section 2 of this ballot will have no effect due to its
ambiguity and lack of modification to the document.

I want to echo a strong opposition towards allowing the reuse of data or
documents obtained under previous versions of the Baseline Requirements,
much as in the discussion of Ballot 194. We are aware of multiple CAs who
have relied on insecure methods here, and the idea that this information
would be appropriate to continue issuing certificates for the next three
years is an unacceptable security risk. We raised this issue to the Forum
nearly three years ago at this point, and continuing for three more years
is not good.

I encourage CAs to thoughtfully examine and articulate why they believe a
phase-in is needed, on a per-section basis, so as to help better understand
the impact relative to the security risk being introduced, and would
encourage the ballot authors and co-sponsors to update Section 2 to
actually update the Baseline Requirements, if that is the goal.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] RFC5280-related Ballot - For Discussion

[Ben Wilson via Public]

I can do that for the longer names, but that takes time to implement and then 
for support in browsers to  develop.  I’ll look at our CABF OID tree and figure 
out how to  branch out an OID arc for these two (commonName and 
organizationName).

 

From: Carl Wallace [mailto:c...@redhoundsoftware.com] 
Sent: Thursday, April 13, 2017 10:56 AM
To: CA/Browser Forum Public Discussion List 
Cc: Ben Wilson 
Subject: Re: [cabfpub] RFC5280-related Ballot - For Discussion

 

Why don't you define new OIDs for the RDNs you want to change the definition 
of?  The spec provides extensibility mechanisms that allow you to do what you 
want without breaking compliant code. 


On Apr 13, 2017, at 12:42 PM, Ben Wilson via Public  > wrote:

Any endorsers?

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ben Wilson via 
Public
Sent: Wednesday, April 12, 2017 9:58 AM
To: Ryan Sleevi  >; CA/Browser 
Forum Public Discussion List  >
Cc: Ben Wilson  >
Subject: Re: [cabfpub] RFC5280-related Ballot - For Discussion

 

Thanks Ryan.  I can make that change.

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Tuesday, April 11, 2017 2:43 PM
To: CA/Browser Forum Public Discussion List  >
Cc: Ben Wilson  >
Subject: Re: [cabfpub] RFC5280-related Ballot - For Discussion

 

No, encoding it as a UTF8String is not valid in the subjectAltName (whose type 
dNSName is defined as IA5String)

 

On Tue, Apr 11, 2017 at 4:31 PM, Ben Wilson via Public  > wrote:

If the ballot were amended to address only underscore characters (and delete 
outdated content), would there be any endorsers?  See attached.

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

+1 801 701 9678  



 

From: Public [mailto:public-boun...@cabforum.org 
 ] On Behalf Of Peter Bowen via Public
Sent: Tuesday, April 11, 2017 10:23 AM
To: CA/Browser Forum Public Discussion List  >
Cc: Peter Bowen  >


Subject: Re: [cabfpub] RFC5280-related Ballot - For Discussion

 

I agree.  There seems to be quite a bit of opposition on the PKIX list to 
extending the length.  It was reasonably pointed out that things that process 
ASN.1 according to the schema will break.

 

However I would point out that this also rolls the other way — adding 
underscore should be safe, as the ASN.1 schema already allows this.

 

On Apr 10, 2017, at 12:33 PM, Ryan Sleevi via Public  > wrote:

 

That's an interesting take. I read the same discussions and took quite the 
opposite conclusion.

 

On Mon, Apr 10, 2017 at 3:23 PM, Ben Wilson via Public  > wrote:

All,

 

I’ve posted the proposal to the PKIX list and haven’t heard sufficient 
opposition on that list, IMHO, that would merit holding up this proposed 
revision to the Baseline Requirements.  I need two endorsers for a ballot.

 

Thanks,

 

Ben   

 

From: Ryan Sleevi [mailto:  sle...@google.com] 
Sent: Monday, April 3, 2017 9:59 AM
To: CA/Browser Forum Public Discussion List <  
public@cabforum.org>
Cc: Ben Wilson <  ben.wil...@digicert.com>
Subject: Re: [cabfpub] RFC5280-related Ballot - For Discussion

 

For those who want to understand why the IETF rejected this change, the thread 
begins at 

 

https://mailarchive.ietf.org/arch/msg/pkix/MJwKL1lqRDuEAhqQ1Ydb5eWBSIs/?qid=ace7ed4844045716922706d6a80b0747

 

You can also see https://datatracker.ietf.org/liaison/376/ and the discussion 
at https://www.ietf.org/mail-archive/web/pkix/current/msg02361.html

 

This was reviewed prior to the production of 5280 - that is, it was known at 
the time 5280 was produced, and was decided not to adopt - see 
https://www.ietf.org/mail-archive/web/pkix/current/msg02357.html and 
https://www.ietf.org/mail-archive/web/pkix/current/msg02336.html

 

On Mon, Apr 3, 2017 at 11:22 AM, Ben Wilson via Public  > wrote:

Here is a redlined version of sections 7.1.4.2.1 and 7.1.4.2.2 of the Baseline 
Requirements which proposes amendments to the way the Baseline Requirements 
handle the maximum length for subjectAltName, commonName and organizationName 
and also clarifies the use of the underscore character.

 

 

Ben Wilson, JD, CISA, CISSP

VP Compliance

  +1 801 701 9678



 


___
Public mailing list

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

[Gervase Markham via Public]

On 29/03/17 15:42, Gervase Markham via Public wrote:
> On 28/03/17 20:11, Peter Bowen wrote:
>> I think it would be good to clarify that this does not prevent using
>> contractors or third parties for domain validation, but rather requires
>> the CA not exclude it from their audit scope.  For example, a CA might
>> decide to use a service like https://www.whoisxmlapi.com/ to help get
>> and parse whois data.  This is clearly a third party involved in the
>> validation process.  The same would be true if the CA uses a service to
>> send emails.
>>
>> What is relevant is that the CA takes responsibility for the process.
> 
> Can you propose changes which would have this effect?

Discussion on the call today suggests that https://www.whoisxmlapi.com/
may or may not be a DTP.

Anyway, if you think changes are needed to meet this goal, please
propose them.

Gerv
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Require commonName in Root and Intermediate Certificates ballot draft (2)

[Patrick Tronnier via Public]

I will endorse.



Thanks

With kind regards,

Patrick Tronnier
Principal Security Architect &
Sr. Director of Quality Assurance & Customer Support
Phone: 763.201.2000
Fax: 763.201.5333
Direct Line: 763.201.2052
Open Access Technology International, Inc.
3660 Technology Drive NE, Minneapolis, MN 55418

“Human action can be modified to some extent, but human nature cannot be 
changed.” – Abraham Lincoln
CONFIDENTIAL INFORMATION: This email and any attachment(s) contain confidential 
and/or proprietary information of Open Access Technology International, Inc. Do 
not copy or distribute without the prior written consent of OATI. If you are 
not a named recipient to the message, please notify the sender immediately and 
do not retain the message in any form, printed or electronic.

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham 
via Public
Sent: Thursday, April 13, 2017 12:03 PM
To: CABFPub 
Cc: Gervase Markham 
Subject: [cabfpub] Require commonName in Root and Intermediate Certificates 
ballot draft (2)


{External email message: This email is from an external source. Please exercise 
caution prior to opening attachments, clicking on links, or providing any 
sensitive information.}
Hi everyone,

Here's an updated version with Peter's tweak to allow CN to be the same if the 
Name is different, and some clarifications requested by Kirk as to the scope of 
applicability time-wise.

Can I get a couple of endorsers?

Gerv

Ballot XXX - Require commonName in Root and Intermediate Certificates
Purpose of Ballot: Section 7.1.4.3 of the BRs, which deals with Subject 
Information for Subordinate CA Certificates, currently requires only that all 
information in a Subordinate CA Certificate is accurate; it does not say what 
information is required. Some of the necessary information is required 
elsewhere in the BRs, but it is not complete - commonName is missing. If 
commonName is omitted, DN clashes can more easily occur. So this motion 
centralises that information in the obvious place, and adds a commonName 
requirement.
The following motion has been proposed by Gervase Markham of Mozilla and 
endorsed by XXX of XXX and XXX of XXX:

-- MOTION BEGINS --

Section 1

Make the following changes to the Baseline Requirements:



* Delete 7.1.2.1 (e), which currently defines the Subject Information required 
in a Root CA Certificate.



* Delete 7.1.2.2 (h), which currently defines the Subject Information required 
in a Subordinate CA Certificate.



* Rename section 7.1.4.2, currently titled "Subject Information", to "Subject 
Information - Subscriber Certificates".



* Rename section 7.1.4.3, currently titled "Subject Information - Subordinate 
CA Certificates" to "Subject Information - Root Certificates and Subordinate CA 
Certificates".



* Based on the style used in 7.1.4.2.2 and the content from the now-deleted 
7.1.2.1 (e) and 7.1.2.2 (h), add the following section 7.1.4.3.1:



7.1.4.3.1 Subject Distinguished Name Fields



Certificate Field: subject:commonName (OID 2.5.4.3)

Required/Optional: Required

Contents: This field MUST be present and the contents MUST be an identifier

for the certificate such that the certificate's Name is unique across all

certificates issued by the issuing certificate.



b. Certificate Field: subject:organizationName (OID 2.5.4.10)

Required/Optional: Required

Contents: This field MUST be present and the contents MUST contain

either the Subject CA’s name or DBA as verified under Section 3.2.2.2.

The CA may include information in this field that differs slightly from

the verified name, such as common variations or abbreviations,  provided

that the CA documents the difference and any abbreviations used are

locally accepted abbreviations; e.g., if the official record shows

“Company Name Incorporated”, the CA MAY use “Company Name Inc.” or

“Company Name”.



c. Certificate Field: subject:countryName (OID: 2.5.4.6)

Required/Optional: Required

Contents: This field MUST contain the two‐letter ISO 3166‐1 country code

for the country in which the CA’s place of business is located.



Section 2



For the avoidance of doubt, these updated requirements apply only to root and 
intermediate certificates issued after the Effective Date of this ballot, which 
is upon approval (i.e. at the end of the IPR Review Period if no Exclusion 
Notices are filed).
-- MOTION ENDS --


The procedure for approval of this Final Maintenance Guideline ballot is as 
follows (exact start and end times may be adjusted to comply with applicable 
Bylaws and IPR Agreement):



BALLOT XXX

Status: Final Maintenance Guideline


Start time (23:00 UTC)


End time (23:00 UTC)


Discussion (7 to 14 days)


XXX

XXX


Vote for approval (7 days)

XXX

XXX


If vote approves ballot: Review Period (Chair to send Review Notice) (30 days).

If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.

If no Exclusion Notices 

Re: [cabfpub] Ballot 189 (revised) - Amend Section 6.1.7 of Baseline Requirements

[Jos Purvis (jopurvis) via Public]

Cisco votes YES.

 

-- 

Jos Purvis (jopur...@cisco.com)

.:|:.:|:. cisco systems | Cryptographic Services

PGP: 0xFD802FEE07D19105  | +1 919.991.9114 (desk)

 

 

From: Public  on behalf of Dimitris Zacharopoulos 
via Public 
Reply-To: CA/Browser Forum Public Discussion List 
Date: Wednesday, 5 April, 2017 at 03:46 
To: "public@cabforum.org" 
Cc: Dimitris Zacharopoulos 
Subject: [cabfpub] Ballot 189 (revised) - Amend Section 6.1.7 of Baseline 
Requirements

 


After the recent discussion, the ballot is now updated with simpler language. 
Voting starts tomorrow April 6th.

Dimitris.

Ballot 189 - Amend Section 6.1.7 of Baseline Requirements 

The following motion has been proposed by Dimitris Zacharopoulos of HARICA and 
endorsed by Bruce Morton of Entrust and Jeremy Rowley of Digicert 

Background: 

Section 6.1.7 of the Baseline Requirements states that the Root CA Private Keys 
MUST NOT be used to sign end-entity certificates, with some exceptions. It is 
unclear if this exception list includes end-entity certificates with EKU 
id-kp-timeStamping. This ballot attempts to clarify two things: 
that it affects Root Keys in a hierarchy that issues SSL Certificates and 
that it does not include time stamping certificates in the exception list. 
It also clears the exception language for 1024-bit RSA Subscriber Certificates 
and testing products with Certificates issued by a Root. 

-- MOTION BEGINS -- 

Current section 6.1.7 

Root CA Private Keys MUST NOT be used to sign Certificates except in the 
following cases: 
Self-signed Certificates to represent the Root Certificate itself; 
Certificates for Subordinate CAs and Cross Certificates; 
Certificates for infrastructure purposes (e.g. administrative role 
certificates, internal CA operational device certificates, and OCSP Response 
verification Certificates); 
Certificates issued solely for the purpose of testing products with 
Certificates issued by a Root CA; and 
Subscriber Certificates, provided that: 
The Root CA uses a 1024-bit RSA signing key that was created prior to the 
Effective Date; 
The Applicant’s application was deployed prior to the Effective Date; 
The Applicant’s application is in active use by the Applicant or the CA uses a 
documented process to establish that the Certificate’s use is required by a 
substantial number of Relying Parties; 
The CA follows a documented process to determine that the Applicant’s 
application poses no known security risks to Relying Parties; 
The CA documents that the Applicant’s application cannot be patched or replaced 
without substantial economic outlay. 
The CA signs the Subscriber Certificate on or before June 30, 2016; and 
The notBefore field in the Subscriber Certificate has a date on or before June 
30, 2016 
Proposed section 6.1.7 

Private Keys corresponding to Root Certificates MUST NOT be used to sign 
Certificates except in the following cases: 
Self-signed Certificates to represent the Root CA itself; 
Certificates for Subordinate CAs and Cross Certificates; 
Certificates for infrastructure purposes (administrative role certificates, 
internal CA operational device certificates) 
Certificates for OCSP Response verification; 
These changes become Effective 30 days after the ballot passes. 

-- MOTION ENDS -- 

The procedure for this ballot is as follows (exact start and end times may be 
adjusted to comply with applicable Bylaws and IPR Agreement): 

BALLOT 189 Status: Amend BR 6.1.7 Start time (22:00 UTC) End time (22:00 UTC) 
Discussion (7 days) 30 March 2017 6 April 2017 
Vote for approval (7 days) 6 April 2017 13 April 2017 
If vote approves ballot: Review Period (Chair to send Review Notice) (30 days)
If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.
If no Exclusion Notices filed, ballot becomes effective at end of Review Period.
Votes must be cast by posting an on-list reply to this thread on the Public 
Mail List.Upon filing of Review Notice by Chair30 days after filing of Review 
Notice by Chair
>From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
>Guideline, such ballot will include a redline or comparison showing the set of 
>changes from the Final Guideline section(s) intended to become a Final 
>Maintenance Guideline, and need not include a copy of the full set of 
>guidelines. Such redline or comparison shall be made against the Final 
>Guideline section(s) as they exist at the time a ballot is proposed, and need 
>not take into consideration other ballots that may be proposed subsequently, 
>except as provided in Bylaw Section 2.3(j). 

Votes must be cast by posting an on-list reply to this thread on the Public 
list. A vote in favor of the motion must indicate a clear 'yes' in the 
response. A vote against must indicate a clear 'no' in the response. A vote to 
abstain must indicate a clear 'abstain' in the 

Re: [cabfpub] Ballot 189 (revised) - Amend Section 6.1.7 of Base line Requirements

[realsky(CHT) via Public]

 Chunghwa Telecom Co., Ltd. votes Yes to ballot 189.

  Li-Chun Chen


-Original message-
From:Peter Miškovič via Public
To:CA/Browser Forum Public Discussion List
Cc:Peter Miškovič
Date: Thu, 13 Apr 2017 22:55:30
Subject: [外部郵件] Re: [cabfpub] Ballot 189 (revised) - Amend Section 6.1.7 of 
Baseline Requirements
Disig votes „YES“.
 
Regards
Peter
 
From: Public [mailto:public-boun...@cabforum.org]On Behalf Of Dimitris 
Zacharopoulos via Public
Sent: Wednesday, April 5, 2017 9:47 AM
To: public@cabforum.org
Cc: Dimitris Zacharopoulos 
Subject: [cabfpub] Ballot 189 (revised) - Amend Section 6.1.7 of Baseline 
Requirements

 

After the recent discussion, the ballot is now updated with simpler language. 
Voting starts tomorrow April 6th.

Dimitris.


Ballot 189 - Amend Section 6.1.7 of Baseline Requirements
The following motion has been proposed by Dimitris Zacharopoulos of HARICA and 
endorsed by Bruce Morton of Entrust and Jeremy Rowley of Digicert
Background: 
Section 6.1.7 of the Baseline Requirements states that the Root CA Private Keys 
MUST NOT be used to sign end-entity certificates, with some exceptions. It is 
unclear if this exception list includes end-entity certificates with EKU 
id-kp-timeStamping. This ballot attempts to clarify two things: 
that it affects Root Keys in a hierarchy that issues SSL Certificates and that 
it does not include time stamping certificates in the exception list. It also 
clears the exception language for 1024-bit RSA Subscriber Certificates and 
testing products with Certificates issued by a Root.
-- MOTION BEGINS -- 
Current section 6.1.7 
Root CA Private Keys MUST NOT be used to sign Certificates except in the 
following cases:
Self-signed Certificates to represent the Root Certificate itself; Certificates 
for Subordinate CAs and Cross Certificates; Certificates for infrastructure 
purposes (e.g. administrative role certificates, internal CA operational device 
certificates, and OCSP Response verification Certificates);Certificates issued 
solely for the purpose of testing products with Certificates issued by a Root 
CA; andSubscriber Certificates, provided that: The Root CA uses a 1024-bit RSA 
signing key that was created prior to the Effective Date;The Applicant’s 
application was deployed prior to the Effective Date; The Applicant’s 
application is in active use by the Applicant or the CA uses a documented 
process to establish that the Certificate’s use is required by a substantial 
number of Relying Parties;The CA follows a documented process to determine that 
the Applicant’s application poses no known security risks to Relying 
Parties;The CA documents that the Applicant’s application cannot be patched or 
replaced without substantial economic outlay.The CA signs the Subscriber 
Certificate on or before June 30, 2016; and The notBefore field in the 
Subscriber Certificate has a date on or before June 30, 2016Proposed section 
6.1.7 
Private Keys corresponding to Root Certificates MUST NOT be used to sign 
Certificates except in the following cases:
Self-signed Certificates to represent the Root CA itself; Certificates for 
Subordinate CAs and Cross Certificates; Certificates for infrastructure 
purposes (administrative role certificates, internal CA operational device 
certificates)Certificates for OCSP Response verification; These changes become 
Effective 30 days after the ballot passes.
-- MOTION ENDS -- 
The procedure for this ballot is as follows (exact start and end times may be 
adjusted to comply with applicable Bylaws and IPR Agreement):
BALLOT 189 Status: Amend BR 6.1.7 
Start time (22:00 UTC)
End time (22:00 UTC) 

Discussion (7 days) 
30 March 2017 
6 April 2017 

Vote for approval (7 days) 
6 April 2017 
13 April 2017 

If vote approves ballot: Review Period (Chair to send Review Notice) (30 days)
If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.
If no Exclusion Notices filed, ballot becomes effective at end of Review Period.
Votes must be cast by posting an on-list reply to this thread on the Public 
Mail List.
Upon filing of Review Notice by Chair
30 days after filing of Review Notice by Chair


From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
Guideline, such ballot will include a redline or comparison showing the set of 
changes from the Final Guideline section(s) intended to become a Final 
Maintenance Guideline, and need not include a copy of the full set of 
guidelines. Such redline or comparison shall be made against the Final 
Guideline section(s) as they exist at the time a ballot is proposed, and need 
not take into consideration other ballots that may be proposed subsequently, 
except as provided in Bylaw Section 2.3(j). 
Votes must be cast by posting an on-list reply to this thread on the Public 
list. A vote in favor of the motion must indicate a clear 'yes' in the 

Re: [cabfpub] Ballot 196: Define "Audit Period"

[realsky(CHT) via Public]

Chunghwa Telecom Co., Ltd. votes Yes to ballot 196 .

   Li-Chun Chen




 
From: Public [mailto:public-boun...@cabforum.org]On Behalf Of Gervase Markham 
via Public
Sent: Monday, April 3, 2017 2:06 PM
To: CABFPub 
Cc: Gervase Markham 
Subject: [cabfpub] Ballot 196: Define "Audit Period"

 
Ballot 196 - Define "Audit Period"
Purpose of Ballot: It appears that CAs are sometimes confused by the phrase 
Audit Period. This ballot adds a definition of that phrase to the BRs, in the 
hope of heading off any further misunderstandings.
The following motion has been proposed by Gervase Markham of Mozilla and 
endorsed by Ryan Sleevi of Google and Jody Cloutier of Microsoft:


-- MOTION BEGINS -- 
Add the following definition to section 1.6.1 of the Baseline Requirements:



Audit Period: In a period-of-time audit, the period between the first day 
(start) and the last day of operations (end) covered by the auditors in their 
engagement. (This is not the same as the period of time when the auditors are 
on-site at the CA.) The coverage rules and maximum length of audit periods are 
defined in section 8.1.
-- MOTION ENDS -- 



The procedure for approval of this Final Maintenance Guideline ballot is as 
follows (exact start and end times may be adjusted to comply with applicable 
Bylaws and IPR Agreement):
 
BALLOT 196
Status: Final Maintenance Guideline
Start time (23:00 UTC)
End time (23:00 UTC)

Discussion (7 to 14 days)
3rd April
10th April

Vote for approval (7 days)
10th April
17th April

If vote approves ballot: Review Period (Chair to send Review Notice) (30 days). 
If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.
If no Exclusion Notices filed, ballot becomes effective at end of Review Period.
Upon filing of Review Notice by Chair
30 days after filing of Review Notice by Chair

 
From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
Guideline, such ballot will include a redline or comparison showing the set of 
changes from the Final Guideline section(s) intended to become a Final 
Maintenance Guideline, and need not include a copy of the full set of 
guidelines.  Such redline or comparison shall be made against the Final 
Guideline section(s) as they exist at the time a ballot is proposed, and need 
not take into consideration other ballots that may be proposed subsequently, 
except as provided in Bylaw Section 2.3(j).
 
Votes must be cast by posting an on-list reply to this thread on the Public 
list.  A vote in favor of the motion must indicate a clear 'yes' in the 
response. A vote against must indicate a clear 'no' in the response. A vote to 
abstain must indicate a clear 'abstain' in the response. Unclear responses will 
not be counted. The latest vote received from any representative of a voting 
member before the close of the voting period will be counted. Voting members 
are listed here:https://cabforum.org/members/
In order for the motion to be adopted, two thirds or more of the votes cast by 
members in the CA category and greater than 50% of the votes cast by members in 
the browser category must be in favor.  Quorum is shown on CA/Browser Forum 
wiki.  Under Bylaw 2.2(g), at least the required quorum number must participate 
in the ballot for the ballot to be valid, either by voting in favor, voting 
against, or abstaining.





___

Public mailing list

Public@cabforum.org

https://cabforum.org/mailman/listinfo/public

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




本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 
如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. 
Please be advised that this email message (including any attachments) contains 
confidential information and may be legally privileged. If you are not the 
intended recipient, please destroy this message and all attachments from your 
system and do not further collect, process, or use them. Chunghwa Telecom and 
all its subsidiaries and associated companies shall not be liable for the 
improper or incomplete transmission of the information contained in this email 
nor for any delay in its receipt or damage to your system. If you are the 
intended recipient, please protect the confidential and/or personal information 
contained in this email with due care. Any unauthorized use, disclosure or 
distribution of this message in whole or in part is strictly prohibited. Also, 
please self-inspect attachments and hyperlinks contained in this email to 
ensure the information security and to protect personal information.


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

[cabfpub] Require commonName in Root and Intermediate Certificates ballot draft (2)

[Gervase Markham via Public]

Hi everyone,

Here's an updated version with Peter's tweak to allow CN to be the same
if the Name is different, and some clarifications requested by Kirk as
to the scope of applicability time-wise.

Can I get a couple of endorsers?

Gerv

*Ballot XXX - Require commonName in Root and Intermediate Certificates
*

*Purpose of Ballot: *Section 7.1.4.3 of the BRs, which deals with
Subject Information for Subordinate CA Certificates, currently requires
only that all information in a Subordinate CA Certificate is accurate;
it does not say what information is required. Some of the necessary
information is required elsewhere in the BRs, but it is not complete -
commonName is missing. If commonName is omitted, DN clashes can more
easily occur. So this motion centralises that information in the obvious
place, and adds a commonName requirement.

The following motion has been proposed by Gervase Markham of Mozilla and
endorsed by XXX of XXX and XXX of XXX:

-- MOTION BEGINS --


_*Section 1*_

Make the following changes to the Baseline Requirements:

* Delete 7.1.2.1 (e), which currently defines the Subject Information required 
in a Root CA Certificate.

* Delete 7.1.2.2 (h), which currently defines the Subject Information required 
in a Subordinate CA Certificate.

* Rename section 7.1.4.2, currently titled "Subject Information", to "Subject 
Information - Subscriber Certificates".

* Rename section 7.1.4.3, currently titled "Subject Information - Subordinate 
CA Certificates" to "Subject Information - Root Certificates and Subordinate CA 
Certificates".

* Based on the style used in 7.1.4.2.2 and the content from the now-deleted 
7.1.2.1 (e) and 7.1.2.2 (h), add the following section 7.1.4.3.1:

7.1.4.3.1 Subject Distinguished Name Fields

Certificate Field: subject:commonName (OID 2.5.4.3)
Required/Optional: Required
Contents: This field MUST be present and the contents MUST be an identifier 
for the certificate such that the certificate's Name is unique across all 
certificates issued by the issuing certificate.

b. Certificate Field: subject:organizationName (OID 2.5.4.10)
Required/Optional: Required
Contents: This field MUST be present and the contents MUST contain
either the Subject CA’s name or DBA as verified under Section 3.2.2.2.
The CA may include information in this field that differs slightly from
the verified name, such as common variations or abbreviations,  provided
that the CA documents the difference and any abbreviations used are
locally accepted abbreviations; e.g., if the official record shows
“Company Name Incorporated”, the CA MAY use “Company Name Inc.” or
“Company Name”.

c. Certificate Field: subject:countryName (OID: 2.5.4.6)
Required/Optional: Required
Contents: This field MUST contain the two‐letter ISO 3166‐1 country code
for the country in which the CA’s place of business is located.

_*Section 2*__**_
For the avoidance of doubt, these updated requirements apply only to root and 
intermediate certificates issued after the Effective Date of this ballot, which 
is upon approval (i.e. at the end of the IPR Review Period if no Exclusion 
Notices are filed). 

-- MOTION ENDS --

 

The procedure for approval of this Final Maintenance Guideline ballot is
as follows (exact start and end times may be adjusted to comply with
applicable Bylaws and IPR Agreement):

 

BALLOT XXX

Status: Final Maintenance Guideline



Start time (23:00 UTC)



End time (23:00 UTC)

Discussion (7 to 14 days)



XXX



XXX

Vote for approval (7 days)



XXX



XXX

If vote approves ballot: Review Period (Chair to send Review Notice) (30
days). 

If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be
created.

If no Exclusion Notices filed, ballot becomes effective at end of Review
Period.



Upon filing of Review Notice by Chair



30 days after filing of Review Notice by Chair

 

>From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final
Maintenance Guideline, such ballot will include a redline or comparison
showing the set of changes from the Final Guideline section(s) intended
to become a Final Maintenance Guideline, and need not include a copy of
the full set of guidelines.  Such redline or comparison shall be made
against the Final Guideline section(s) as they exist at the time a
ballot is proposed, and need not take into consideration other ballots
that may be proposed subsequently, except as provided in Bylaw Section
2.3(j).

 

Votes must be cast by posting an on-list reply to this thread on the
Public list.  A vote in favor of the motion must indicate a clear 'yes'
in the response. A vote against must indicate a clear 'no' in the
response. A vote to abstain must indicate a clear 'abstain' in the
response. Unclear responses will not be counted. The latest vote
received from any representative of a voting member before the close of
the voting period will be counted. Voting members are listed here:

Re: [cabfpub] [EXTERNAL] Brazilian bank DNS heist

[Rob Stradling via Public]

On 13/04/17 15:57, Ryan Sleevi wrote:

On Thu, Apr 13, 2017 at 10:47 AM, Rob Stradling wrote:

They _could_, for sure.

But "they should"?  Citation needed.  What root program(s) require
this today?


Microsoft's most recent policy update proposed adding this, but it was
pointed out that CAs are not presently doing that. I think that's a
reasonable statement for SHOULD, but not MUST, to borrow from RFC 2119.


You got a link for that?

On https://aka.ms/rootcert, the closest thing I see is...
"New intermediate CA certificates under root certificates submitted for 
distribution by the Program must separate Server Authentication, S/MIME, 
Code Signing and Time Stamping uses. This means that a single 
intermediate issuing CA must not be used to issue both server 
authentication, S/MIME, and code signing certificates. A separate 
intermediate must be used for each use case."

...which doesn't mention EV at all.


After all, by separating out unique issuance, CAs enable their customers
to improve their security stance. I should hope the position you're
advocating is not that the only things worth doing are those which are
required on CAs - that'd be a rather cynical take on the state of CA
security.


OK, so there are at least 3 groups of intermediates that issue EV certs:
  1. Issue EV certs, but also issue non-EV certs.
  2. Issue only EV certs, but not trusted for EV on all EV-capable
browsers.
  3. Issue only EV certs, and trusted for EV on all EV-capable browsers.

I agree that 'any site operator would need to know what constitutes
as "EV only"', so yes, there would need to be an official list of
"EV only" (group 3) intermediates/pins published somewhere, and
maintained. (Publication and maintenance of such a list could be
largely automated by adding a page to crt.sh or some other root
program aggregator service).


I disagree, and of course, do not support that. Group 2 is wholly
sufficient for the security needs of users,


Ah, you're right.  My mistake.

Group 2 is sufficient for the HPKP-based approach.  The "EV only" 
intermediates do need to only issue EV certs, but those intermediates 
don't need to be trusted-for-EV by all browsers.  (They do of course 
need to be trusted-for-serverAuth by all browsers though).


BTW, did your "not support that" comment also apply to the idea of 
adding a page to crt.sh (or some other root program aggregator service) 
that would automatically maintain the list of (group 2!) "EV only" 
intermediates?



and avoids introducing an
additional third party (browsers) into mediating that relationship. I
would be happy to point out a variety of CAs who have had difficulty in
having their roots or intermediates EV recognized, due to incomplete
audits or documentation. Were such an "EV only" policy implemented as
you've proposed, those CAs would find themselves unable to provide their
services to customers. I'm sure you can appreciate why CAs should find
that undesirable.

A cynical take would be to suggest that by defining it as Group 3, it
may be an attempt by CAs to "increase" the compatibility risk of
removing EV for a particular CA, thereby trying to capture more of the
market. Whether or not that is the intent, that would certainly be a
result, and as such, would be unquestionably unacceptable from the
browser side, and thus unlikely to ever be supported. By going through
Group 2, those issues are ameliorated regardless of whether or not the
browser supports or recognizes the CA's EV status, and Group 2 is fully
accomodated today by browsers via HPKP.


I like a good conspiracy theory as much as the next guy, but I'm afraid 
in this case it was just insufficient coffee.  :-)



Checking != Updating.

Both your HPKP-based approach and my HSTS-based approach would
require the site operator to regularly check that the EV
intermediate they currently use is still on the group 3 list.

However, your HPKP-based approach would also require the site
operator to add/remove a pin every time a different EV intermediate
is added/removed from the group 3 list.


Again, my proposal has nothing to do with Group 3 in order for site
operators to recognize the security benefits nominally afforded by the
enhanced vetting claimed by EV. It only requires that issuing CAs make a
distinction between Group 1 and Group 2, and to allow subscribers to
choose to pin to Group 2. It leaves the trust relationship solely
between the customer and the set of issuing CAs, and if a customer
cannot trust a CA to follow its own CP/CPS, well then, what good is
anything?


Not at all.  I was merely looking at the current landscape and
attempting to determine the path of least resistance towards a
maintainable solution.


Right, the HPKP solution can be implemented tomorrow, with the only
change being on CAs that don't already distinguish from EV capable
intermediates and non-EV capable intermediates. That is, 

[cabfpub] Membership-related clarifications ballot draft (2)

[Gervase Markham via Public]

Here's an updated draft with some changes prompted by Kirk's
suggestions. We now make it clear that proper recognition of
currently-issued certificates by at least one browser member is a
membership requirement. I've therefore also expanded the ways one can
lose membership to match. Also, for the avoidance of doubt, I've added
the definition of "Affiliate" from the IPR policy. 

Gerv

*Ballot XXX - Membership-related clarifications
*

*Purpose of Ballot: *The CAB Forum Bylaws define membership criteria,
but don't say what should happen when an existing member ceases to meet
those criteria. This ballot is intended to fix this, for the avoidance
of doubt and uncertainty. It also makes it clearer that proper
recognition of currently-issued certificates by at least one browser
member is a membership requirement, and adds the definition of
"Affiliate" from the IPR policy.

The following motion has been proposed by Gervase Markham of Mozilla and
endorsed by XXX of XXX and XXX of XXX:

-- MOTION BEGINS --

This motion changes the CAB Forum Bylaws.

___*Section 1*__*
*_
Add a new section between 2.1 ("Qualifying for Forum Membership") and
the following section, numbering the new section 2.2, and renumbering
following sections appropriately. The new section shall read:

*2.2 Ending Forum Membership*

Forum members may resign from the Forum at any time. Resignation does
not prevent a member potentially having continuing obligations, under
the Forum's IPR Policy or any other document.

(a) _Browser_: A Browser member's membership will automatically cease if
any of the following become true:

  * it stops providing updates for its membership-qualifying software
product; or
  * six months have elapsed since the last such published update.

(b) _Issuing CA_ or _Root CA_: An CA member's membership will be
suspended if any of the following become true:

  * it fails to pass its membership-qualifying audit;
  * its membership-qualifying audit is rescinded;
  * fifteen months have elapsed since the end of the Audit Period of its
last successful membership-qualifying audit;
  * it stops issuing certificates to Web servers that are openly
accessible from the Internet; or
  * it is no longer the case that its currently-issued certificates are
treated as valid by at least one Browser member.

A CA member's membership will automatically cease after a further six
months if it has not re-met the membership qualifications by that time.
While suspended, CAs may participate in meetings and on the Forum's
discussion lists, but not take part in any form of voting.

_*Section 2*__*
*_
Update both sections 2.1 (a) and (b) to insert words as follows:

"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 Browser member."

_*Section 3*__*

*_Update section 2.2 b) as follows:

Only one vote per Member company shall be accepted; representatives of
corporate affiliates_Affiliates_ shall not vote. 

Add to the Definitions section:

*Affiliate:* an entity that directly or indirectly controls, is
controlled by or is under common control with, a Member. Control for the
purposes of this Agreement shall mean direct or indirect beneficial
ownership of more than fifty percent of the voting stock, or
decision-making authority in the event that there is no voting stock, in
an entity.

-- MOTION ENDS --

 

The procedure for approval of this Final Maintenance Guideline ballot is
as follows:

 

BALLOT XXX

Status: Final Maintenance Guideline



Start time (23:00 UTC)



End time (23:00 UTC)

Discussion (7 to 14 days)



XXX



XXX

Vote for approval (7 days)



XXX



XXX

If vote approves ballot: Review Period (Chair to send Review Notice) (30
days). 

If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be
created.

If no Exclusion Notices filed, ballot becomes effective at end of Review
Period.



Upon filing of Review Notice by Chair



30 days after filing of Review Notice by Chair

 

>From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final
Maintenance Guideline, such ballot will include a redline or comparison
showing the set of changes from the Final Guideline section(s) intended
to become a Final Maintenance Guideline, and need not include a copy of
the full set of guidelines.  Such redline or comparison shall be made
against the Final Guideline section(s) as they exist at the time a
ballot is proposed, and need not take into consideration other ballots
that may be proposed subsequently, except as provided in Bylaw Section
2.3(j).

 

Votes must be cast by posting an on-list reply to this thread on the
Public list.  A vote in favor of the motion must indicate a clear 'yes'
in the response. A vote against must indicate a clear 'no' in the
response. A vote to abstain must indicate a clear 'abstain' in the
response. Unclear 

Re: [cabfpub] [EXTERNAL] Brazilian bank DNS heist

[Ryan Sleevi via Public]

On Thu, Apr 13, 2017 at 10:47 AM, Rob Stradling 
wrote:
>
> They _could_, for sure.
>
> But "they should"?  Citation needed.  What root program(s) require this
> today?


Microsoft's most recent policy update proposed adding this, but it was
pointed out that CAs are not presently doing that. I think that's a
reasonable statement for SHOULD, but not MUST, to borrow from RFC 2119.

After all, by separating out unique issuance, CAs enable their customers to
improve their security stance. I should hope the position you're advocating
is not that the only things worth doing are those which are required on CAs
- that'd be a rather cynical take on the state of CA security.


> OK, so there are at least 3 groups of intermediates that issue EV certs:
>   1. Issue EV certs, but also issue non-EV certs.
>   2. Issue only EV certs, but not trusted for EV on all EV-capable
> browsers.
>   3. Issue only EV certs, and trusted for EV on all EV-capable browsers.
>
> I agree that 'any site operator would need to know what constitutes as "EV
> only"', so yes, there would need to be an official list of "EV only" (group
> 3) intermediates/pins published somewhere, and maintained. (Publication and
> maintenance of such a list could be largely automated by adding a page to
> crt.sh or some other root program aggregator service).


I disagree, and of course, do not support that. Group 2 is wholly
sufficient for the security needs of users, and avoids introducing an
additional third party (browsers) into mediating that relationship. I would
be happy to point out a variety of CAs who have had difficulty in having
their roots or intermediates EV recognized, due to incomplete audits or
documentation. Were such an "EV only" policy implemented as you've
proposed, those CAs would find themselves unable to provide their services
to customers. I'm sure you can appreciate why CAs should find that
undesirable.

A cynical take would be to suggest that by defining it as Group 3, it may
be an attempt by CAs to "increase" the compatibility risk of removing EV
for a particular CA, thereby trying to capture more of the market. Whether
or not that is the intent, that would certainly be a result, and as such,
would be unquestionably unacceptable from the browser side, and thus
unlikely to ever be supported. By going through Group 2, those issues are
ameliorated regardless of whether or not the browser supports or recognizes
the CA's EV status, and Group 2 is fully accomodated today by browsers via
HPKP.


> Checking != Updating.
>
> Both your HPKP-based approach and my HSTS-based approach would require the
> site operator to regularly check that the EV intermediate they currently
> use is still on the group 3 list.
>
> However, your HPKP-based approach would also require the site operator to
> add/remove a pin every time a different EV intermediate is added/removed
> from the group 3 list.


Again, my proposal has nothing to do with Group 3 in order for site
operators to recognize the security benefits nominally afforded by the
enhanced vetting claimed by EV. It only requires that issuing CAs make a
distinction between Group 1 and Group 2, and to allow subscribers to choose
to pin to Group 2. It leaves the trust relationship solely between the
customer and the set of issuing CAs, and if a customer cannot trust a CA to
follow its own CP/CPS, well then, what good is anything?


> Not at all.  I was merely looking at the current landscape and attempting
> to determine the path of least resistance towards a maintainable solution.


Right, the HPKP solution can be implemented tomorrow, with the only change
being on CAs that don't already distinguish from EV capable intermediates
and non-EV capable intermediates. That is, quite literally, the path of
least resistance :)
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 189 (revised) - Amend Section 6.1.7 of Baseline Requirements

[Peter Miškovič via Public]

Disig votes „YES“.

Regards
Peter

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Dimitris 
Zacharopoulos via Public
Sent: Wednesday, April 5, 2017 9:47 AM
To: public@cabforum.org
Cc: Dimitris Zacharopoulos 
Subject: [cabfpub] Ballot 189 (revised) - Amend Section 6.1.7 of Baseline 
Requirements


After the recent discussion, the ballot is now updated with simpler language. 
Voting starts tomorrow April 6th.

Dimitris.

Ballot 189 - Amend Section 6.1.7 of Baseline Requirements

The following motion has been proposed by Dimitris Zacharopoulos of HARICA and 
endorsed by Bruce Morton of Entrust and Jeremy Rowley of Digicert

Background:

Section 6.1.7 of the Baseline Requirements states that the Root CA Private Keys 
MUST NOT be used to sign end-entity certificates, with some exceptions. It is 
unclear if this exception list includes end-entity certificates with EKU 
id-kp-timeStamping. This ballot attempts to clarify two things:

  1.  that it affects Root Keys in a hierarchy that issues SSL Certificates and
  2.  that it does not include time stamping certificates in the exception list.

It also clears the exception language for 1024-bit RSA Subscriber Certificates 
and testing products with Certificates issued by a Root.

-- MOTION BEGINS --

Current section 6.1.7

Root CA Private Keys MUST NOT be used to sign Certificates except in the 
following cases:

  1.  Self-signed Certificates to represent the Root Certificate itself;
  2.  Certificates for Subordinate CAs and Cross Certificates;
  3.  Certificates for infrastructure purposes (e.g. administrative role 
certificates, internal CA operational device certificates, and OCSP Response 
verification Certificates);
  4.  Certificates issued solely for the purpose of testing products with 
Certificates issued by a Root CA; and
  5.  Subscriber Certificates, provided that:

 *   The Root CA uses a 1024-bit RSA signing key that was created prior to 
the Effective Date;
 *   The Applicant’s application was deployed prior to the Effective Date;
 *   The Applicant’s application is in active use by the Applicant or the 
CA uses a documented process to establish that the Certificate’s use is 
required by a substantial number of Relying Parties;
 *   The CA follows a documented process to determine that the Applicant’s 
application poses no known security risks to Relying Parties;
 *   The CA documents that the Applicant’s application cannot be patched or 
replaced without substantial economic outlay.
 *   The CA signs the Subscriber Certificate on or before June 30, 2016; and
 *   The notBefore field in the Subscriber Certificate has a date on or 
before June 30, 2016

Proposed section 6.1.7

Private Keys corresponding to Root Certificates MUST NOT be used to sign 
Certificates except in the following cases:

  1.  Self-signed Certificates to represent the Root CA itself;
  2.  Certificates for Subordinate CAs and Cross Certificates;
  3.  Certificates for infrastructure purposes (administrative role 
certificates, internal CA operational device certificates)
  4.  Certificates for OCSP Response verification;

These changes become Effective 30 days after the ballot passes.

-- MOTION ENDS --

The procedure for this ballot is as follows (exact start and end times may be 
adjusted to comply with applicable Bylaws and IPR Agreement):

BALLOT 189 Status: Amend BR 6.1.7


Start time (22:00 UTC)


End time (22:00 UTC)


Discussion (7 days)


30 March 2017


6 April 2017


Vote for approval (7 days)


6 April 2017


13 April 2017


If vote approves ballot: Review Period (Chair to send Review Notice) (30 days)
If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.
If no Exclusion Notices filed, ballot becomes effective at end of Review Period.
Votes must be cast by posting an on-list reply to this thread on the Public 
Mail List.


Upon filing of Review Notice by Chair


30 days after filing of Review Notice by Chair


From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
Guideline, such ballot will include a redline or comparison showing the set of 
changes from the Final Guideline section(s) intended to become a Final 
Maintenance Guideline, and need not include a copy of the full set of 
guidelines. Such redline or comparison shall be made against the Final 
Guideline section(s) as they exist at the time a ballot is proposed, and need 
not take into consideration other ballots that may be proposed subsequently, 
except as provided in Bylaw Section 2.3(j).

Votes must be cast by posting an on-list reply to this thread on the Public 
list. A vote in favor of the motion must indicate a clear 'yes' in the 
response. A vote against must indicate a clear 'no' in the response. A vote to 
abstain must indicate a clear 'abstain' in the response. Unclear responses will 
not be counted. The latest vote received from any representative of a voting 
member before the 

Re: [cabfpub] [EXTERNAL] Brazilian bank DNS heist

[Rob Stradling via Public]

On 10/04/17 15:51, Ryan Sleevi wrote:

On Mon, Apr 10, 2017 at 10:36 AM, Rob Stradling wrote:

Not all CAs have chosen to use separate intermediate(s) to issue
only EV certs.

e.g., https://crt.sh/?Identity=%25=904


I didn't say they have - I said they should.


They _could_, for sure.

But "they should"?  Citation needed.  What root program(s) require this 
today?



Any CA who isn't using a distinct EV intermediate can, in the future, do
so for new certifictes, w/o any issue. That's not a hard blocker.


Whereas adding an "EV only" option to HSTS would...

1) avoid the need to coordinate and maintain a list of "EV only" pins.


That's not correct. It just outsources the problem back to the user and
the browsers - any site operator would need to know what constitutes as
"EV only". For example, if browsers don't all update their EV list on
the exact same day (and they don't), then you end up in a situation
where Browser A recognizes a site as EV-only and Browser B does not. The
implications of this are that the site would break in Browser B (if the
pin was noted).


OK, so there are at least 3 groups of intermediates that issue EV certs:
  1. Issue EV certs, but also issue non-EV certs.
  2. Issue only EV certs, but not trusted for EV on all EV-capable 
browsers.

  3. Issue only EV certs, and trusted for EV on all EV-capable browsers.

I agree that 'any site operator would need to know what constitutes as 
"EV only"', so yes, there would need to be an official list of "EV only" 
(group 3) intermediates/pins published somewhere, and maintained. 
(Publication and maintenance of such a list could be largely automated 
by adding a page to crt.sh or some other root program aggregator service).



2) avoid the need for site operators to update their local copies of
the list of "EV only" pins.


It doesn't. A site operator would constantly have to be checking what
sets of CAs the browser noted were for EV only, to make sure their CA
was providing that.


Checking != Updating.

Both your HPKP-based approach and my HSTS-based approach would require 
the site operator to regularly check that the EV intermediate they 
currently use is still on the group 3 list.


However, your HPKP-based approach would also require the site operator 
to add/remove a pin every time a different EV intermediate is 
added/removed from the group 3 list.



It's riskier for browsers to do so, because now there's zero
relationship with the customer (the site operator) and with the CA (to
make sure their PKI hierarchy is sane). As plenty of CAs in the Forum
can attest to, they have been bitten where cross-signs of their
intermediates lead to incorrect recognition of EV status. Or browser
bugs related to certificate policies.


This is a fair point.

https://bugs.chromium.org/p/chromium/issues/detail?id=705285 would've 
completely bricked (in Chrome) any site using an affected EV cert if my 
proposed HSTS-based "EV only" approach was in use.  Whereas with your 
HPKP-based approach, the sites would've still been accessible, albeit 
without the EV indicator (due to the bug).


It makes a nice change for HPKP to be the non-footgun approach to something!


This instead promotes a direct relationship between the customer and the
CA, which is the only relationship for which a reliable means of
communication exists (quite literally, in the case of EV!)


3) work even in the case of a CA that hasn't chosen to use "EV only"
intermediate(s).


Sounds like you're saying CAs are incapable of change? ;)


Not at all.  I was merely looking at the current landscape and 
attempting to determine the path of least resistance towards a 
maintainable solution.



More pragmatically, nothing about the proposed solution is blocked on
any new development, other than the CA needing to do something if the CA
wants to offer this service to its subscriber. That's quite literally
the exact place the cost of work should be borne. A CA can dedicate one
or more intermediates to EV and begin issuing _today_ (provided they've
got their ceremonies scripted and ready).


Fair enough.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

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

[Wayne Thayer via Public]

GoDaddy votes Yes.

As intended by the authors of ballot 193, we believe that more time is needed 
for CAs to properly implement this change.

Thanks,

Wayne

From: Public  on behalf of Kirk Hall via Public 

Reply-To: CA/Browser Forum Public Discussion List 
Date: Sunday, April 9, 2017 at 4:29 PM
To: CA/Browser Forum Public Discussion List 
Cc: Kirk Hall 
Subject: [cabfpub] Ballot 194 - Effective Date of Ballot 193 Provisions is in 
the VOTING period (ends April 16)

Reminder: Ballot 194 -  Effective Date of Ballot 193 Provisions is in the 
voting period (ends April 16)

Ballot 194 – Effective Date of Ballot 193 Provisions

Purpose of Ballot: Recent Ballot 193 reduced the maximum period for 
certificates and for reuse of vetting data for DV and OV certificates from 39 
months to 825 days.  The effective date for reducing the maximum validity 
period of certificates was specified as March 1, 2018, but no effective date 
was specified for when the reduction of the maximum period for reuse of vetting 
data becomes effective.

It was the intention of the authors of Ballot 193 that the effective date for 
reducing the maximum period for reuse of vetting data under BR 4.2.1 would also 
be March 1, 2018.  This ballot is intended to clarify that intention.  The 
ballot also makes these changes retroactive to the effective date of Ballot 193 
so there is no gap period.

Ballot 193 is in the Review Period (which will end on April 22, 2017), and has 
not yet taken effect.  Bylaw 2.3 states that Ballots should include a “redline 
or comparison showing the set of changes from the Final Guideline section(s) 
intended to become a Final Maintenance Guideline” and that “[s]uch redline or 
comparison shall be made against the Final Guideline section(s) as they exist 
at the time a ballot is proposed”.

To avoid confusion, this Ballot will show the proposed changes to BR 4.2.1 will 
be presented two ways: (1) a comparison of the changes to BR 4.2.1 as it 
existed before Ballot 193 (which is as BR 4.2.1 exists at this time this ballot 
is proposed), and also (2) a comparison of the changes to BR 4.2.1 as it will 
exist after the Review Period for Ballot 193 is completed (assuming no 
Exclusion Notices are filed).

The following motion has been proposed by Chris Bailey of Entrust Datacard and 
endorsed by Ben Wilson of DigiCert, and Wayne Thayer of GoDaddy to introduce 
new Final Maintenance Guidelines for the "Baseline Requirements Certificate 
Policy for the Issuance and Management of Publicly-Trusted Certificates" 
(Baseline Requirements) and the "Guidelines for the Issuance and Management of 
Extended Validation Certificates" (EV Guidelines).

-- MOTION BEGINS --

Ballot Section 1

BR 4.2.1 is amended to read as follows:

[Ballot amendments shown against BR 4.2.1 as it currently exists without the 
changes adopted in Ballot 193]

BR 4.2.1. Performing Identification and Authentication Functions

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 order to comply with these 
Requirements and the CA’s Certificate Policy and/or Certification Practice 
Statement. In cases where the certificate request does not contain all the 
necessary information about the Applicant, the CA SHALL obtain the remaining 
information from the Applicant or, having obtained it from a reliable, 
independent, third‐party data source, confirm it with the Applicant. The CA 
SHALL establish and follow a documented procedure for verifying all data 
requested for inclusion in the Certificate by the Applicant.

Applicant information MUST include, but not be limited to, at least one 
Fully‐Qualified Domain Name or IP address to be included in the Certificate’s 
SubjectAltName extension.

Section 6.3.2 limits the validity period of Subscriber Certificates. The CA MAY 
use the documents and data provided in Section 3.2 to verify certificate 
information, provided that: the CA obtained the data or document from a source 
specified under Section 3.2 no more than thirty‐nine (39) months prior to 
issuing the Certificate.

(1) Prior to March 1, 2018, the CA obtained the data or document from a source 
specified under Section 3.2 no more than 39 months prior to issuing the 
Certificate; and

(2) On or after March 1, 2018, the CA obtained the data or document from a 
source specified under Section 3.2 no more than 825 days prior to issuing the 
Certificate.

The CA SHALL develop, maintain, and implement documented procedures that 
identify and require additional verification activity for High Risk Certificate 
Requests prior to the Certificate’s approval, as reasonably necessary to ensure 
that such requests are properly verified under these Requirements.

If a Delegated Third Party 

Re: [cabfpub] Ballot 196: Define "Audit Period"

[Doug Beattie via Public]

GlobalSign votes Yes to ballot 196.


From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham 
via Public
Sent: Monday, April 3, 2017 2:06 PM
To: CABFPub 
Cc: Gervase Markham 
Subject: [cabfpub] Ballot 196: Define "Audit Period"

Ballot 196 - Define "Audit Period"
Purpose of Ballot: It appears that CAs are sometimes confused by the phrase 
Audit Period. This ballot adds a definition of that phrase to the BRs, in the 
hope of heading off any further misunderstandings.
The following motion has been proposed by Gervase Markham of Mozilla and 
endorsed by Ryan Sleevi of Google and Jody Cloutier of Microsoft:

-- MOTION BEGINS --
Add the following definition to section 1.6.1 of the Baseline Requirements:


Audit Period: In a period-of-time audit, the period between the first day 
(start) and the last day of operations (end) covered by the auditors in their 
engagement. (This is not the same as the period of time when the auditors are 
on-site at the CA.) The coverage rules and maximum length of audit periods are 
defined in section 8.1.
-- MOTION ENDS --



The procedure for approval of this Final Maintenance Guideline ballot is as 
follows (exact start and end times may be adjusted to comply with applicable 
Bylaws and IPR Agreement):



BALLOT 196

Status: Final Maintenance Guideline


Start time (23:00 UTC)


End time (23:00 UTC)


Discussion (7 to 14 days)


3rd April

10th April


Vote for approval (7 days)

10th April

17th April


If vote approves ballot: Review Period (Chair to send Review Notice) (30 days).

If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.

If no Exclusion Notices filed, ballot becomes effective at end of Review Period.

Upon filing of Review Notice by Chair

30 days after filing of Review Notice by Chair




From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
Guideline, such ballot will include a redline or comparison showing the set of 
changes from the Final Guideline section(s) intended to become a Final 
Maintenance Guideline, and need not include a copy of the full set of 
guidelines.  Such redline or comparison shall be made against the Final 
Guideline section(s) as they exist at the time a ballot is proposed, and need 
not take into consideration other ballots that may be proposed subsequently, 
except as provided in Bylaw Section 2.3(j).



Votes must be cast by posting an on-list reply to this thread on the Public 
list.  A vote in favor of the motion must indicate a clear 'yes' in the 
response. A vote against must indicate a clear 'no' in the response. A vote to 
abstain must indicate a clear 'abstain' in the response. Unclear responses will 
not be counted. The latest vote received from any representative of a voting 
member before the close of the voting period will be counted. Voting members 
are listed here: https://cabforum.org/members/
In order for the motion to be adopted, two thirds or more of the votes cast by 
members in the CA category and greater than 50% of the votes cast by members in 
the browser category must be in favor.  Quorum is shown on CA/Browser Forum 
wiki.  Under Bylaw 2.2(g), at least the required quorum number must participate 
in the ballot for the ballot to be valid, either by voting in favor, voting 
against, or abstaining.



___

Public mailing list

Public@cabforum.org

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

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

[Rich Smith via Public]

Comodo votes YES

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Chris Bailey via 
Public
Sent: Sunday, April 2, 2017 3:27 PM
To: public@cabforum.org
Cc: Chris Bailey 
Subject: [cabfpub] Ballot 194 – Effective Date of Ballot 193 Provisions

 

Ballot 194 – Effective Date of Ballot 193 Provisions

 

Purpose of Ballot: Recent Ballot 193 reduced the maximum period for 
certificates and for reuse of vetting data for DV and OV certificates from 39 
months to 825 days.  The effective date for reducing the maximum validity 
period of certificates was specified as March 1, 2018, but no effective date 
was specified for when the reduction of the maximum period for reuse of vetting 
data becomes effective.

 

It was the intention of the authors of Ballot 193 that the effective date for 
reducing the maximum period for reuse of vetting data under BR 4.2.1 would also 
be March 1, 2018.  This ballot is intended to clarify that intention.  The 
ballot also makes these changes retroactive to the effective date of Ballot 193 
so there is no gap period.

 

Ballot 193 is in the Review Period (which will end on April 22, 2017), and has 
not yet taken effect.  Bylaw 2.3 states that Ballots should include a “redline 
or comparison showing the set of changes from the Final Guideline section(s) 
intended to become a Final Maintenance Guideline” and that “[s]uch redline or 
comparison shall be made against the Final Guideline section(s) as they exist 
at the time a ballot is proposed”.

 

To avoid confusion, this Ballot will show the proposed changes to BR 4.2.1 will 
be presented two ways: (1) a comparison of the changes to BR 4.2.1 as it 
existed before Ballot 193 (which is as BR 4.2.1 exists at this time this ballot 
is proposed), and also (2) a comparison of the changes to BR 4.2.1 as it will 
exist after the Review Period for Ballot 193 is completed (assuming no 
Exclusion Notices are filed).

 

The following motion has been proposed by Chris Bailey of Entrust Datacard and 
endorsed by Ben Wilson of DigiCert, and Wayne Thayer of GoDaddy to introduce 
new Final Maintenance Guidelines for the "Baseline Requirements Certificate 
Policy for the Issuance and Management of Publicly-Trusted Certificates" 
(Baseline Requirements) and the "Guidelines for the Issuance and Management of 
Extended Validation Certificates" (EV Guidelines).

 

-- MOTION BEGINS -- 

 

Ballot Section 1

 

BR 4.2.1 is amended to read as follows:

 

[Ballot amendments shown against BR 4.2.1 as it currently exists without the 
changes adopted in Ballot 193]

 

BR 4.2.1. Performing Identification and Authentication Functions

 

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 order to comply with these 
Requirements and the CA’s Certificate Policy and/or Certification Practice 
Statement. In cases where the certificate request does not contain all the 
necessary information about the Applicant, the CA SHALL obtain the remaining 
information from the Applicant or, having obtained it from a reliable, 
independent, third‐party data source, confirm it with the Applicant. The CA 
SHALL establish and follow a documented procedure for verifying all data 
requested for inclusion in the Certificate by the Applicant.

 

Applicant information MUST include, but not be limited to, at least one 
Fully‐Qualified Domain Name or IP address to be included in the Certificate’s 
SubjectAltName extension.

 

Section 6.3.2 limits the validity period of Subscriber Certificates. The CA MAY 
use the documents and data provided in Section 3.2 to verify certificate 
information, provided that: the CA obtained the data or document from a source 
specified under Section 3.2 no more than thirty‐nine (39) months prior to 
issuing the Certificate.

 

(1) Prior to March 1, 2018, the CA obtained the data or document from a source 
specified under Section 3.2 no more than 39 months prior to issuing the 
Certificate; and

 

(2) On or after March 1, 2018, the CA obtained the data or document from a 
source specified under Section 3.2 no more than 825 days prior to issuing the 
Certificate. 

 

The CA SHALL develop, maintain, and implement documented procedures that 
identify and require additional verification activity for High Risk Certificate 
Requests prior to the Certificate’s approval, as reasonably necessary to ensure 
that such requests are properly verified under these Requirements.

 

If a Delegated Third Party fulfills any of the CA’s obligations under this 
section, the CA SHALL verify that the process used by the Delegated Third Party 
to identify and further verify High Risk Certificate Requests provides at least 
the same level of assurance as the CA’s own processes.

 

 

[Ballot amendments shown against BR 4.2.1 as it existed after Ballot 193 was 

Re: [cabfpub] Ballot 196: Define "Audit Period"

[Rich Smith via Public]

Comodo votes YES

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham 
via Public
Sent: Monday, April 3, 2017 1:06 PM
To: CABFPub 
Cc: Gervase Markham 
Subject: [cabfpub] Ballot 196: Define "Audit Period"

 

Ballot 196 - Define "Audit Period"

Purpose of Ballot: It appears that CAs are sometimes confused by the phrase 
Audit Period. This ballot adds a definition of that phrase to the BRs, in the 
hope of heading off any further misunderstandings. 

The following motion has been proposed by Gervase Markham of Mozilla and 
endorsed by Ryan Sleevi of Google and Jody Cloutier of Microsoft:



-- MOTION BEGINS -- 

Add the following definition to section 1.6.1 of the Baseline Requirements:



Audit Period: In a period-of-time audit, the period between the first day 
(start) and the last day of operations (end) covered by the auditors in their 
engagement. (This is not the same as the period of time when the auditors are 
on-site at the CA.) The coverage rules and maximum length of audit periods are 
defined in section 8.1.

-- MOTION ENDS -- 





The procedure for approval of this Final Maintenance Guideline ballot is as 
follows (exact start and end times may be adjusted to comply with applicable 
Bylaws and IPR Agreement):

 


BALLOT 196

Status: Final Maintenance Guideline

Start time (23:00 UTC)

End time (23:00 UTC)


Discussion (7 to 14 days)

3rd April

10th April


Vote for approval (7 days)

10th April

17th April


If vote approves ballot: Review Period (Chair to send Review Notice) (30 days). 
 

If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.

If no Exclusion Notices filed, ballot becomes effective at end of Review Period.

Upon filing of Review Notice by Chair

30 days after filing of Review Notice by Chair

 

>From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
>Guideline, such ballot will include a redline or comparison showing the set of 
>changes from the Final Guideline section(s) intended to become a Final 
>Maintenance Guideline, and need not include a copy of the full set of 
>guidelines.  Such redline or comparison shall be made against the Final 
>Guideline section(s) as they exist at the time a ballot is proposed, and need 
>not take into consideration other ballots that may be proposed subsequently, 
>except as provided in Bylaw Section 2.3(j).

 

Votes must be cast by posting an on-list reply to this thread on the Public 
list.  A vote in favor of the motion must indicate a clear 'yes' in the 
response. A vote against must indicate a clear 'no' in the response. A vote to 
abstain must indicate a clear 'abstain' in the response. Unclear responses will 
not be counted. The latest vote received from any representative of a voting 
member before the close of the voting period will be counted. Voting members 
are listed here:   https://cabforum.org/members/ 

In order for the motion to be adopted, two thirds or more of the votes cast by 
members in the CA category and greater than 50% of the votes cast by members in 
the browser category must be in favor.  Quorum is shown on CA/Browser Forum 
wiki.  Under Bylaw 2.2(g), at least the required quorum number must participate 
in the ballot for the ballot to be valid, either by voting in favor, voting 
against, or abstaining.





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

Re: [cabfpub] Ballot 195: CAA Fixup

[Rich Smith via Public]

Comodo votes YES

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham 
via Public
Sent: Monday, April 3, 2017 12:58 PM
To: CABFPub 
Cc: Gervase Markham 
Subject: [cabfpub] Ballot 195: CAA Fixup

 

Ballot 195 - CAA Fixup

Purpose of Ballot: The CAB Forum recently passed ballot 187 to make CAA 
checking mandatory. This ballot corrects some wording issues in the text added 
by that ballot. 

The following motion has been proposed by Gervase Markham of Mozilla and 
endorsed by Ryan Sleevi of Google and Jeremy Rowley of DigiCert:



-- MOTION BEGINS -- 

Change the following in section 3.2.2.8 of the Baseline Requirements:

1) Add a carriage return after "any other time."

2) Replace the sentence:

"CAs MUST process the issue, issuewild, and iodef property tags as specified in 
RFC 6844."

with:

"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."

3) Replace the sentence:

"CAs MUST respect the critical flag and reject any unrecognized properties with 
this flag set."

with:

"CAs MUST respect the critical flag and not issue a certificate if they 
encounter an unrecognized property with this flag set."

-- MOTION ENDS --

 

The procedure for approval of this Final Maintenance Guideline ballot is as 
follows (exact start and end times may be adjusted to comply with applicable 
Bylaws and IPR Agreement):

 


BALLOT 195

Status: Final Maintenance Guideline

Start time (23:00 UTC)

End time (23:00 UTC)


Discussion (7 to 14 days)

3rd April

10th April


Vote for approval (7 days)

10th April

17th April


If vote approves ballot: Review Period (Chair to send Review Notice) (30 days). 
 

If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.

If no Exclusion Notices filed, ballot becomes effective at end of Review Period.

Upon filing of Review Notice by Chair

30 days after filing of Review Notice by Chair

 

>From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
>Guideline, such ballot will include a redline or comparison showing the set of 
>changes from the Final Guideline section(s) intended to become a Final 
>Maintenance Guideline, and need not include a copy of the full set of 
>guidelines.  Such redline or comparison shall be made against the Final 
>Guideline section(s) as they exist at the time a ballot is proposed, and need 
>not take into consideration other ballots that may be proposed subsequently, 
>except as provided in Bylaw Section 2.3(j).

 

Votes must be cast by posting an on-list reply to this thread on the Public 
list.  A vote in favor of the motion must indicate a clear 'yes' in the 
response. A vote against must indicate a clear 'no' in the response. A vote to 
abstain must indicate a clear 'abstain' in the response. Unclear responses will 
not be counted. The latest vote received from any representative of a voting 
member before the close of the voting period will be counted. Voting members 
are listed here:   https://cabforum.org/members/ 

In order for the motion to be adopted, two thirds or more of the votes cast by 
members in the CA category and greater than 50% of the votes cast by members in 
the browser category must be in favor.  Quorum is shown on CA/Browser Forum 
wiki.  Under Bylaw 2.2(g), at least the required quorum number must participate 
in the ballot for the ballot to be valid, either by voting in favor, voting 
against, or abstaining.





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

Re: [cabfpub] Ballot 189 (revised) - Amend Section 6.1.7 of Baseline Requirements

[Rich Smith via Public]

Comodo votes YES

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Dimitris 
Zacharopoulos via Public
Sent: Wednesday, April 5, 2017 2:47 AM
To: public@cabforum.org
Cc: Dimitris Zacharopoulos 
Subject: [cabfpub] Ballot 189 (revised) - Amend Section 6.1.7 of Baseline 
Requirements

 


After the recent discussion, the ballot is now updated with simpler language. 
Voting starts tomorrow April 6th.

Dimitris.



Ballot 189 - Amend Section 6.1.7 of Baseline Requirements 

The following motion has been proposed by Dimitris Zacharopoulos of HARICA and 
endorsed by Bruce Morton of Entrust and Jeremy Rowley of Digicert 

Background: 

Section 6.1.7 of the Baseline Requirements states that the Root CA Private Keys 
MUST NOT be used to sign end-entity certificates, with some exceptions. It is 
unclear if this exception list includes end-entity certificates with EKU 
id-kp-timeStamping. This ballot attempts to clarify two things: 

1.  that it affects Root Keys in a hierarchy that issues SSL Certificates 
and 
2.  that it does not include time stamping certificates in the exception 
list. 

It also clears the exception language for 1024-bit RSA Subscriber Certificates 
and testing products with Certificates issued by a Root. 

-- MOTION BEGINS -- 

Current section 6.1.7 

Root CA Private Keys MUST NOT be used to sign Certificates except in the 
following cases: 

1.  Self-signed Certificates to represent the Root Certificate itself; 
2.  Certificates for Subordinate CAs and Cross Certificates; 
3.  Certificates for infrastructure purposes (e.g. administrative role 
certificates, internal CA operational device certificates, and OCSP Response 
verification Certificates); 
4.  Certificates issued solely for the purpose of testing products with 
Certificates issued by a Root CA; and 
5.  Subscriber Certificates, provided that: 

a.  The Root CA uses a 1024-bit RSA signing key that was created prior to 
the Effective Date; 
b.  The Applicant’s application was deployed prior to the Effective Date; 
c.  The Applicant’s application is in active use by the Applicant or the CA 
uses a documented process to establish that the Certificate’s use is required 
by a substantial number of Relying Parties; 
d.  The CA follows a documented process to determine that the Applicant’s 
application poses no known security risks to Relying Parties; 
e.  The CA documents that the Applicant’s application cannot be patched or 
replaced without substantial economic outlay. 
f.  The CA signs the Subscriber Certificate on or before June 30, 2016; and 
g.  The notBefore field in the Subscriber Certificate has a date on or 
before June 30, 2016 

Proposed section 6.1.7 

Private Keys corresponding to Root Certificates MUST NOT be used to sign 
Certificates except in the following cases: 

1.  Self-signed Certificates to represent the Root CA itself; 
2.  Certificates for Subordinate CAs and Cross Certificates; 
3.  Certificates for infrastructure purposes (administrative role 
certificates, internal CA operational device certificates) 
4.  Certificates for OCSP Response verification; 

These changes become Effective 30 days after the ballot passes. 

-- MOTION ENDS -- 

The procedure for this ballot is as follows (exact start and end times may be 
adjusted to comply with applicable Bylaws and IPR Agreement): 


BALLOT 189 Status: Amend BR 6.1.7 

Start time (22:00 UTC) 

End time (22:00 UTC) 


Discussion (7 days) 

30 March 2017 

6 April 2017 


Vote for approval (7 days) 

6 April 2017 

13 April 2017 


If vote approves ballot: Review Period (Chair to send Review Notice) (30 days)
If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.
If no Exclusion Notices filed, ballot becomes effective at end of Review Period.
Votes must be cast by posting an on-list reply to this thread on the Public 
Mail List.

Upon filing of Review Notice by Chair

30 days after filing of Review Notice by Chair

>From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
>Guideline, such ballot will include a redline or comparison showing the set of 
>changes from the Final Guideline section(s) intended to become a Final 
>Maintenance Guideline, and need not include a copy of the full set of 
>guidelines. Such redline or comparison shall be made against the Final 
>Guideline section(s) as they exist at the time a ballot is proposed, and need 
>not take into consideration other ballots that may be proposed subsequently, 
>except as provided in Bylaw Section 2.3(j). 

Votes must be cast by posting an on-list reply to this thread on the Public 
list. A vote in favor of the motion must indicate a clear 'yes' in the 
response. A vote against must indicate a clear 'no' in the response. A vote to 
abstain must indicate a clear 'abstain' in the response. Unclear responses will 
not be counted. The latest vote received from 

Re: [cabfpub] Ballot 196: Define "Audit Period"

[Peter Miškovič via Public]

Disig votes „YES“.

Regards
Peter

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham 
via Public
Sent: Monday, April 3, 2017 8:06 PM
To: CABFPub 
Cc: Gervase Markham 
Subject: [cabfpub] Ballot 196: Define "Audit Period"

Ballot 196 - Define "Audit Period"
Purpose of Ballot: It appears that CAs are sometimes confused by the phrase 
Audit Period. This ballot adds a definition of that phrase to the BRs, in the 
hope of heading off any further misunderstandings.
The following motion has been proposed by Gervase Markham of Mozilla and 
endorsed by Ryan Sleevi of Google and Jody Cloutier of Microsoft:

-- MOTION BEGINS --
Add the following definition to section 1.6.1 of the Baseline Requirements:


Audit Period: In a period-of-time audit, the period between the first day 
(start) and the last day of operations (end) covered by the auditors in their 
engagement. (This is not the same as the period of time when the auditors are 
on-site at the CA.) The coverage rules and maximum length of audit periods are 
defined in section 8.1.
-- MOTION ENDS --



The procedure for approval of this Final Maintenance Guideline ballot is as 
follows (exact start and end times may be adjusted to comply with applicable 
Bylaws and IPR Agreement):



BALLOT 196

Status: Final Maintenance Guideline


Start time (23:00 UTC)


End time (23:00 UTC)


Discussion (7 to 14 days)


3rd April

10th April


Vote for approval (7 days)

10th April

17th April


If vote approves ballot: Review Period (Chair to send Review Notice) (30 days).

If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.

If no Exclusion Notices filed, ballot becomes effective at end of Review Period.

Upon filing of Review Notice by Chair

30 days after filing of Review Notice by Chair




From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
Guideline, such ballot will include a redline or comparison showing the set of 
changes from the Final Guideline section(s) intended to become a Final 
Maintenance Guideline, and need not include a copy of the full set of 
guidelines.  Such redline or comparison shall be made against the Final 
Guideline section(s) as they exist at the time a ballot is proposed, and need 
not take into consideration other ballots that may be proposed subsequently, 
except as provided in Bylaw Section 2.3(j).



Votes must be cast by posting an on-list reply to this thread on the Public 
list.  A vote in favor of the motion must indicate a clear 'yes' in the 
response. A vote against must indicate a clear 'no' in the response. A vote to 
abstain must indicate a clear 'abstain' in the response. Unclear responses will 
not be counted. The latest vote received from any representative of a voting 
member before the close of the voting period will be counted. Voting members 
are listed here: https://cabforum.org/members/
In order for the motion to be adopted, two thirds or more of the votes cast by 
members in the CA category and greater than 50% of the votes cast by members in 
the browser category must be in favor.  Quorum is shown on CA/Browser Forum 
wiki.  Under Bylaw 2.2(g), at least the required quorum number must participate 
in the ballot for the ballot to be valid, either by voting in favor, voting 
against, or abstaining.



___

Public mailing list

Public@cabforum.org

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

Re: [cabfpub] Ballot 195: CAA Fixup

[Peter Miškovič via Public]

Disig votes „YES“ .



Regards

Peter



From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham 
via Public
Sent: Monday, April 3, 2017 7:58 PM
To: CABFPub 
Cc: Gervase Markham 
Subject: [cabfpub] Ballot 195: CAA Fixup



Ballot 195 - CAA Fixup

Purpose of Ballot: The CAB Forum recently passed ballot 187 to make CAA 
checking mandatory. This ballot corrects some wording issues in the text added 
by that ballot.

The following motion has been proposed by Gervase Markham of Mozilla and 
endorsed by Ryan Sleevi of Google and Jeremy Rowley of DigiCert:



-- MOTION BEGINS --

Change the following in section 3.2.2.8 of the Baseline Requirements:

1) Add a carriage return after "any other time."

2) Replace the sentence:

"CAs MUST process the issue, issuewild, and iodef property tags as specified in 
RFC 6844."

with:

"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."

3) Replace the sentence:

"CAs MUST respect the critical flag and reject any unrecognized properties with 
this flag set."

with:

"CAs MUST respect the critical flag and not issue a certificate if they 
encounter an unrecognized property with this flag set."

-- MOTION ENDS --



The procedure for approval of this Final Maintenance Guideline ballot is as 
follows (exact start and end times may be adjusted to comply with applicable 
Bylaws and IPR Agreement):



BALLOT 195

Status: Final Maintenance Guideline

Start time (23:00 UTC)

End time (23:00 UTC)

Discussion (7 to 14 days)

3rd April

10th April

Vote for approval (7 days)

10th April

17th April

If vote approves ballot: Review Period (Chair to send Review Notice) (30 days).

If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.

If no Exclusion Notices filed, ballot becomes effective at end of Review Period.

Upon filing of Review Notice by Chair

30 days after filing of Review Notice by Chair



From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
Guideline, such ballot will include a redline or comparison showing the set of 
changes from the Final Guideline section(s) intended to become a Final 
Maintenance Guideline, and need not include a copy of the full set of 
guidelines.  Such redline or comparison shall be made against the Final 
Guideline section(s) as they exist at the time a ballot is proposed, and need 
not take into consideration other ballots that may be proposed subsequently, 
except as provided in Bylaw Section 2.3(j).



Votes must be cast by posting an on-list reply to this thread on the Public 
list.  A vote in favor of the motion must indicate a clear 'yes' in the 
response. A vote against must indicate a clear 'no' in the response. A vote to 
abstain must indicate a clear 'abstain' in the response. Unclear responses will 
not be counted. The latest vote received from any representative of a voting 
member before the close of the voting period will be counted. Voting members 
are listed here: https://cabforum.org/members/

In order for the motion to be adopted, two thirds or more of the votes cast by 
members in the CA category and greater than 50% of the votes cast by members in 
the browser category must be in favor.  Quorum is shown on CA/Browser Forum 
wiki.  Under Bylaw 2.2(g), at least the required quorum number must participate 
in the ballot for the ballot to be valid, either by voting in favor, voting 
against, or abstaining.





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

Re: [cabfpub] Ballot 195: CAA Fixup

[Adriano Santoni via Public]

  
  
Actalis votes "yes".





  



  

  

   
  
  

  From:
  Public [mailto:public-boun...@cabforum.org]
  On Behalf Of Gervase Markham via
  Public
  Sent: Monday, April 3, 2017 11:58 AM
  To: CABFPub 
  Cc: Gervase Markham 
  Subject: [cabfpub] Ballot 195: CAA
  Fixup

  
   
  

  Ballot 195 - CAA Fixup
  Purpose of
  Ballot: The CAB Forum recently passed
ballot 187 to make CAA checking mandatory. This
ballot corrects some wording issues in the text
added by that ballot.

  The following
motion has been proposed by Gervase Markham of
Mozilla and endorsed by Ryan Sleevi of Google
and Jeremy Rowley of DigiCert:


  -- MOTION BEGINS
-- 
  Change
the following in section 3.2.2.8 of the Baseline
Requirements:
  1)
Add a carriage return after "any other time."
  2)
Replace the sentence:
  "CAs
MUST process the issue, issuewild, and iodef
property tags as specified in RFC 6844."
  with:
  "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."
  3)
Replace the sentence:
  "CAs
MUST respect the critical flag and reject any
unrecognized properties with this flag set."
  with:
  "CAs
MUST respect the critical flag and not issue a
certificate if they encounter an unrecognized
property with this flag set."
  --
MOTION ENDS --
   
  The
  procedure for approval of this Final
  Maintenance Guideline ballot is as follows
  (exact start and end times may be adjusted to
  comply with applicable Bylaws and IPR
  Agreement):
   
  

  

  BALLOT
  195
  Status:
  Final Maintenance Guideline


  
Start
  time (23:00 UTC)


  
End
  time (23:00 UTC)

  
  

  Discussion
  (7 to 14 days)


  
3rd
  April


  
10th April

  
  

  Vote
  for approval (7 days)


  
10th April


  
17th April

  
  

  If
  

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

[LEROY Franck via Public]

Hello

Certinomis votes yes for Ballot 194.

Franck
Certinomis  CTO

De : Public [mailto:public-boun...@cabforum.org] De la part de zhangyq via 
Public
Envoyé : jeudi 13 avril 2017 07:36
À : CA/Browser Forum Public Discussion List 
Cc : zhangyq 
Objet : Re: [cabfpub] Ballot 194 - Effective Date of Ballot 193 Provisionsis in 
the VOTING period (ends April 16)


GDCA votes Yes to ballot 194.

 原始邮件
发件人: Doug Beattie via Public>
收件人: CA/Browser Forum Public Discussion 
List>
抄送: Doug 
Beattie>
发送时间: 2017年4月11日(周二) 01:26
主题: Re: [cabfpub] Ballot 194 - Effective Date of Ballot 193 Provisionsis in the 
VOTING period (ends April 16)

GlobalSign votes Yes to ballot 194.


From: Public 
[mailto:public-boun...@cabforum.org] On 
Behalf Of Kirk Hall via Public
Sent: Sunday, April 9, 2017 7:30 PM
To: CA/Browser Forum Public Discussion List 
>
Cc: Kirk Hall 
>
Subject: [cabfpub] Ballot 194 - Effective Date of Ballot 193 Provisions is in 
the VOTING period (ends April 16)

Reminder: Ballot 194 -  Effective Date of Ballot 193 Provisions is in the 
voting period (ends April 16)

Ballot 194 – Effective Date of Ballot 193 Provisions

Purpose of Ballot: Recent Ballot 193 reduced the maximum period for 
certificates and for reuse of vetting data for DV and OV certificates from 39 
months to 825 days.  The effective date for reducing the maximum validity 
period of certificates was specified as March 1, 2018, but no effective date 
was specified for when the reduction of the maximum period for reuse of vetting 
data becomes effective.

It was the intention of the authors of Ballot 193 that the effective date for 
reducing the maximum period for reuse of vetting data under BR 4.2.1 would also 
be March 1, 2018.  This ballot is intended to clarify that intention.  The 
ballot also makes these changes retroactive to the effective date of Ballot 193 
so there is no gap period.

Ballot 193 is in the Review Period (which will end on April 22, 2017), and has 
not yet taken effect.  Bylaw 2.3 states that Ballots should include a “redline 
or comparison showing the set of changes from the Final Guideline section(s) 
intended to become a Final Maintenance Guideline” and that “[s]uch redline or 
comparison shall be made against the Final Guideline section(s) as they exist 
at the time a ballot is proposed”.

To avoid confusion, this Ballot will show the proposed changes to BR 4.2.1 will 
be presented two ways: (1) a comparison of the changes to BR 4.2.1 as it 
existed before Ballot 193 (which is as BR 4.2.1 exists at this time this ballot 
is proposed), and also (2) a comparison of the changes to BR 4.2.1 as it will 
exist after the Review Period for Ballot 193 is completed (assuming no 
Exclusion Notices are filed).

The following motion has been proposed by Chris Bailey of Entrust Datacard and 
endorsed by Ben Wilson of DigiCert, and Wayne Thayer of GoDaddy to introduce 
new Final Maintenance Guidelines for the "Baseline Requirements Certificate 
Policy for the Issuance and Management of Publicly-Trusted Certificates" 
(Baseline Requirements) and the "Guidelines for the Issuance and Management of 
Extended Validation Certificates" (EV Guidelines).

-- MOTION BEGINS --

Ballot Section 1

BR 4.2.1 is amended to read as follows:

[Ballot amendments shown against BR 4.2.1 as it currently exists without the 
changes adopted in Ballot 193]

BR 4.2.1. Performing Identification and Authentication Functions

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 order to comply with these 
Requirements and the CA’s Certificate Policy and/or Certification Practice 
Statement. In cases where the certificate request does not contain all the 
necessary information about the Applicant, the CA SHALL obtain the remaining 
information from the Applicant or, having obtained it from a reliable, 
independent, third‐party data source, confirm it with the Applicant. The CA 
SHALL establish and follow a documented procedure for verifying all data 
requested for inclusion in the Certificate by the Applicant.

Applicant information MUST include, but not be limited to, at least one 
Fully‐Qualified Domain Name or IP address to be included in the Certificate’s 
SubjectAltName extension.

Section 6.3.2 limits the validity period of Subscriber Certificates. The CA MAY 
use the documents and data provided in Section 3.2 to verify certificate 
information, provided that: the CA obtained the data or document from a source 
specified under Section 3.2 no more than 

Re: [cabfpub] Ballot 195: CAA Fixup

[zhangyq via Public]

GDCA votes Yes to ballot 195.

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham 
via Public
 Sent: Monday, April 3, 2017 11:58 AM
 To: CABFPub public@cabforum.org
 Cc: Gervase Markham g...@mozilla.org
 Subject: [cabfpub] Ballot 195: CAA Fixup

Ballot 195 - CAA Fixup
Purpose of Ballot: The CAB Forum recently passed ballot 187 to make CAA 
checking mandatory. This ballot corrects some wording issues in the text added 
by that ballot.
The following motion has been proposed by Gervase Markham of Mozilla and 
endorsed by Ryan Sleevi of Google and Jeremy Rowley of DigiCert:
 

-- MOTION BEGINS --
Change the following in section 3.2.2.8 of the Baseline Requirements:
1) Add a carriage return after "any other time."
2) Replace the sentence:
"CAs MUST process the issue, issuewild, and iodef property tags as specified in 
RFC 6844."
with:
"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."
3) Replace the sentence:
"CAs MUST respect the critical flag and reject any unrecognized properties with 
this flag set."
with:
"CAs MUST respect the critical flag and not issue a certificate if they 
encounter an unrecognized property with this flag set."
-- MOTION ENDS --

The procedure for approval of this Final Maintenance Guideline ballot is as 
follows (exact start and end times may be adjusted to comply with applicable 
Bylaws and IPR Agreement):

BALLOT 195
Status: Final Maintenance Guideline
Start time (23:00 UTC)
End time (23:00 UTC)
Discussion (7 to 14 days)
3rd April
10th April
Vote for approval (7 days)
10th April
17th April
If vote approves ballot: Review Period (Chair to send Review Notice) (30 days).
If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to be 
created.
If no Exclusion Notices filed, ballot becomes effective at end of Review Period.
Upon filing of Review Notice by Chair
30 days after filing of Review Notice by Chair

From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final Maintenance 
Guideline, such ballot will include a redline or comparison showing the set of 
changes from the Final Guideline section(s) intended to become a Final 
Maintenance Guideline, and need not include a copy of the full set of 
guidelines. Such redline or comparison shall be made against the Final 
Guideline section(s) as they exist at the time a ballot is proposed, and need 
not take into consideration other ballots that may be proposed subsequently, 
except as provided in Bylaw Section 2.3(j).

Votes must be cast by posting an on-list reply to this thread on the Public 
list. A vote in favor of the motion must indicate a clear 'yes' in the 
response. A vote against must indicate a clear 'no' in the response. A vote to 
abstain must indicate a clear 'abstain' in the response. Unclear responses will 
not be counted. The latest vote received from any representative of a voting 
member before the close of the voting period will be counted. Voting members 
are listed here: https://cabforum.org/members/
In order for the motion to be adopted, two thirds or more of the votes cast by 
members in the CA category and greater than 50% of the votes cast by members in 
the browser category must be in favor. Quorum is shown on CA/Browser Forum 
wiki. Under Bylaw 2.2(g), at least the required quorum number must participate 
in the ballot for the ballot to be valid, either by voting in favor, voting 
against, or abstaining.

 

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

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

[Dimitris Zacharopoulos via Public]

HARICA votes "abstain" to ballot 194.


Dimitris.

On 2/4/2017 11:26 μμ, Chris Bailey via Public wrote:


*Ballot 194 – Effective Date of Ballot 193 Provisions*

*Purpose of Ballot:*Recent Ballot 193 reduced the maximum period for 
certificates and for reuse of vetting data for DV and OV certificates 
from 39 months to 825 days.  The effective date for reducing the 
maximum validity period of certificates was specified as March 1, 
2018, but no effective date was specified for when the reduction of 
the maximum period for reuse of vetting data becomes effective.


It was the intention of the authors of Ballot 193 that the effective 
date for reducing the maximum period for reuse of vetting data under 
BR 4.2.1 would also be March 1, 2018.  This ballot is intended to 
clarify that intention.  The ballot also makes these changes 
retroactive to the effective date of Ballot 193 so there is no gap period.


Ballot 193 is in the Review Period (which will end on April 22, 2017), 
and has not yet taken effect.  Bylaw 2.3 states that Ballots should 
include a “redline or comparison showing the set of changes from the 
Final Guideline section(s) intended to become a Final Maintenance 
Guideline” and that “[s]uch redline or comparison shall be made 
against the Final Guideline section(s) as they exist at the time a 
ballot is proposed”.


To avoid confusion, this Ballot will show the proposed changes to BR 
4.2.1 will be presented two ways: (1) a comparison of the changes to 
BR 4.2.1 as it existed before Ballot 193 (which is as BR 4.2.1 exists 
at this time this ballot is proposed), and also (2) a comparison of 
the changes to BR 4.2.1 as it will exist after the Review Period for 
Ballot 193 is completed (assuming no Exclusion Notices are filed).


The following motion has been proposed by Chris Bailey of Entrust 
Datacard and endorsed by Ben Wilson of DigiCert, and Wayne Thayer of 
GoDaddy to introduce new Final Maintenance Guidelines for the 
"Baseline Requirements Certificate Policy for the Issuance and 
Management of Publicly-Trusted Certificates" (Baseline Requirements) 
and the "Guidelines for the Issuance and Management of Extended 
Validation Certificates" (EV Guidelines).


-- MOTION BEGINS --

*_Ballot Section 1_*

**

BR 4.2.1 is amended to read as follows:

/[Ballot amendments shown against BR 4.2.1 _as it currently exists 
without the changes adopted in Ballot 193_]/


*BR 4.2.1. Performing Identification and Authentication Functions*

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 
order to comply with these Requirements and the CA’s Certificate 
Policy and/or Certification Practice Statement. In cases where the 
certificate request does not contain all the necessary information 
about the Applicant, the CA SHALL obtain the remaining information 
from the Applicant or, having obtained it from a reliable, 
independent, third‐party data source, confirm it with the Applicant. 
The CA SHALL establish and follow a documented procedure for verifying 
all data requested for inclusion in the Certificate by the Applicant.


Applicant information MUST include, but not be limited to, at least 
one Fully‐Qualified Domain Name or IP address to be included in the 
Certificate’s SubjectAltName extension.


Section 6.3.2 limits the validity period of Subscriber Certificates. 
The CA MAY use the documents and data provided in Section 3.2 to 
verify certificate information, provided that*_:_* /the CA obtained 
the data or document from a source specified under Section 3.2 no more 
than thirty//‐//nine (39) months prior to issuing the Certificate./


*_(1) Prior to March 1, 2018, the CA obtained the data or document 
from a source specified under Section 3.2 no more than 39 months prior 
to issuing the Certificate; and_*


*_(2) On or after March 1, 2018, the CA obtained the data or document 
from a source specified under Section 3.2 no more than 825 days prior 
to issuing the Certificate. _*


**

The CA SHALL develop, maintain, and implement documented procedures 
that identify and require additional verification activity for High 
Risk Certificate Requests prior to the Certificate’s approval, as 
reasonably necessary to ensure that such requests are properly 
verified under these Requirements.


If a Delegated Third Party fulfills any of the CA’s obligations under 
this section, the CA SHALL verify that the process used by the 
Delegated Third Party to identify and further verify High Risk 
Certificate Requests provides at least the same level of assurance as 
the CA’s own processes.


/[Ballot amendments shown against BR 4.2.1 _as it existed after Ballot 
193 was approved_]/


*BR 4.2.1. Performing Identification and Authentication Functions*

The certificate request MAY include all factual information about the 
Applicant to be included in the 

Re: [cabfpub] Ballot 195: CAA Fixup

[Dimitris Zacharopoulos via Public]

HARICA votes "yes" to ballot 195.

Dimitris.


On 3/4/2017 8:58 μμ, Gervase Markham via Public wrote:


*Ballot 195 - CAA Fixup
*

*Purpose of Ballot: *The CAB Forum recently passed ballot 187 to make 
CAA checking mandatory. This ballot corrects some wording issues in 
the text added by that ballot.


The following motion has been proposed by Gervase Markham of Mozilla 
and endorsed by Ryan Sleevi of Google and Jeremy Rowley of DigiCert:


-- MOTION BEGINS --

Change the following in section 3.2.2.8 of the Baseline Requirements:

1) Add a carriage return after "any other time."

2) Replace the sentence:

"CAs MUST process the issue, issuewild, and iodef property tags as 
specified in RFC 6844."


with:

"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."


3) Replace the sentence:

"CAs MUST respect the critical flag and reject any unrecognized 
properties with this flag set."


with:

"CAs MUST respect the critical flag and not issue a certificate if 
they encounter an unrecognized property with this flag set."


-- MOTION ENDS --

The procedure for approval of this Final Maintenance Guideline ballot 
is as follows (exact start and end times may be adjusted to comply 
with applicable Bylaws and IPR Agreement):


BALLOT 195

Status: Final Maintenance Guideline



Start time (23:00 UTC)



End time (23:00 UTC)

Discussion (7 to 14 days)



3rd April



10th April

Vote for approval (7 days)



10th April



17th April

If vote approves ballot: Review Period (Chair to send Review Notice) 
(30 days).


If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to 
be created.


If no Exclusion Notices filed, ballot becomes effective at end of 
Review Period.




Upon filing of Review Notice by Chair



30 days after filing of Review Notice by Chair

From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final 
Maintenance Guideline, such ballot will include a redline or 
comparison showing the set of changes from the Final Guideline 
section(s) intended to become a Final Maintenance Guideline, and need 
not include a copy of the full set of guidelines.  Such redline or 
comparison shall be made against the Final Guideline section(s) as 
they exist at the time a ballot is proposed, and need not take into 
consideration other ballots that may be proposed subsequently, except 
as provided in Bylaw Section 2.3(j).


Votes must be cast by posting an on-list reply to this thread on the 
Public list.  A vote in favor of the motion must indicate a clear 
'yes' in the response. A vote against must indicate a clear 'no' in 
the response. A vote to abstain must indicate a clear 'abstain' in the 
response. Unclear responses will not be counted. The latest vote 
received from any representative of a voting member before the close 
of the voting period will be counted. Voting members are listed here: 
https://cabforum.org/members/


In order for the motion to be adopted, two thirds or more of the votes 
cast by members in the CA category and greater than 50% of the votes 
cast by members in the browser category must be in favor. Quorum is 
shown on CA/Browser Forum wiki.  Under Bylaw 2.2(g), at least the 
required quorum number must participate in the ballot for the ballot 
to be valid, either by voting in favor, voting against, or abstaining.




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


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


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

Re: [cabfpub] Ballot 189 (revised) - Amend Section 6.1.7 of Baseline Requirements

[Adriano Santoni via Public]

  
  
Actalis votes "yes"


Il 12/04/2017 17:49, Ben Wilson via
  Public ha scritto:


  
  
  
  
DigiCert
  votes “Yes”
 


  
From:
Public [mailto:public-boun...@cabforum.org]
On Behalf Of Dimitris Zacharopoulos via Public
Sent: Wednesday, April 5, 2017 1:47 AM
To: public@cabforum.org
Cc: Dimitris Zacharopoulos

Subject: [cabfpub] Ballot 189 (revised) - Amend
Section 6.1.7 of Baseline Requirements
  

 

  After the recent discussion, the ballot is now updated with
  simpler language. Voting starts tomorrow April 6th.
  
  Dimitris.
  
  

  Ballot 189 - Amend Section 6.1.7
  of Baseline Requirements

  The following motion has been proposed by
Dimitris Zacharopoulos of HARICA and endorsed by Bruce
Morton of Entrust and Jeremy Rowley of Digicert

  Background: 
  Section 6.1.7 of the Baseline Requirements
states that the Root CA Private Keys MUST NOT be used to
sign end-entity certificates, with some exceptions. It is
unclear if this exception list includes end-entity
certificates with EKU id-kp-timeStamping. This ballot
attempts to clarify two things: 
  

  that it affects Root Keys in a hierarchy that issues SSL
  Certificates and 

  that it does not include time stamping certificates in the
  exception list. 
  
  It also clears the exception language for
1024-bit RSA Subscriber Certificates and testing products
with Certificates issued by a Root.

  -- MOTION BEGINS -- 
  Current section 6.1.7 
  Root CA Private Keys MUST NOT be used to
sign Certificates except in the following cases:

  

  Self-signed Certificates to represent the Root Certificate
  itself; 

  Certificates for Subordinate CAs and Cross Certificates; 

  Certificates for infrastructure purposes (e.g.
  administrative role certificates, internal CA operational
  device certificates, and OCSP Response verification
  Certificates);
  

  Certificates issued solely for the purpose of testing
  products with Certificates issued by a Root CA; and
  

  Subscriber Certificates, provided that: 
  
  

  
The Root CA uses a 1024-bit RSA signing key that was
created prior to the Effective Date;

  
The Applicant’s application was deployed prior to the
Effective Date; 
  
The Applicant’s application is in active use by the
Applicant or the CA uses a documented process to
establish that the Certificate’s use is required by a
substantial number of Relying Parties;

  
The CA follows a documented process to determine that
the Applicant’s application poses no known security
risks to Relying Parties;

  
The CA documents that the Applicant’s application cannot
be patched or replaced without substantial economic
outlay.

  
The CA signs the Subscriber Certificate on or before
June 30, 2016; and 
  
The notBefore field in the Subscriber Certificate has a
date on or before June 30, 2016


  
  Proposed section 6.1.7 
  Private Keys corresponding to Root
Certificates MUST NOT be used to sign Certificates except in
the following cases:

  

  Self-signed Certificates to represent the Root CA itself;
  

  Certificates for Subordinate CAs and Cross Certificates; 

  Certificates for infrastructure purposes (administrative
  role certificates, internal CA operational device
  certificates)
  

  Certificates for OCSP Response verification; 
  
  These changes become Effective 30
  days after the ballot passes.

  -- MOTION ENDS --