That’s a good report Richard and it shows there is an ongoing need for
customers to obtain 2 and 3 year certificates. If we’re going to impact such a
large customer set we should have a solid reason for doing so.
I don’t understand this how this is the “single greatest impediment towards

Hi Kirk,
There is a copy/paste issue with the patent numbers in the table below. The
first GlobalSign patent is actually a Symantec patent. It should be this one:
- https://www.google.com/patents/US8250361
Doug
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Kirk

Gerv,
I’d like to propose a more detailed ballot for making CAA mandatory. I worked
on this with a couple of the CAs in CA Security Council and there is general
consensus that we can support this ballot. The intent is to be as clear as
possible because CAs will be audited against this -

> For example, the addition of "If a CNAME or DNAME record is found, then the
> CAA check will start
> over using the returned value as the new input to the CAA check." is
> introducing ambiguity, because
> it's incompatible with the algorithm described - namely, the CAA check does
> not

Ryan,
I believe that my recommendation and your implied functional agreement with it
could be wrong. Let me ask the question another way
1. If CAA(X) is not empty, R(X) = CAA (X), otherwise
2. If A(X) is not null (i.e, there is a CNAME or DNAME record for X), and
R(A(X)) is not

Hi Gerv,
I have some input and recommendations…..
I’ve attached an updated version of the ballot for your consideration with
these comments (and maybe others, this has been a work-in-progress for a while
and maybe some other changes crept in, sorry in advance)
I think we need to talk about

I say go ahead and block them, they’ve all been warned and should be prepared
for the consequences.
Doug
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via
Public
Sent: Thursday, February 9, 2017 3:44 PM
To: CA/Browser Forum Public Discussion List

I know GlobalSign has SHA-1 certs that expire in the future, I still stay block
them. There should not that many and one would hope that they are not even
being used (much). The browsers have been conveying degraded UI on these for a
long time, so blocking them is the next logical step. I

Starting a new thread where web site administrators can post their questions
regarding 13 month TLS certificates.
Posted with permission
Hi,
the reasons to shorten the lifetime makes no sense. His argument was about
faster phasing out SHA1, but as the CA side for the major CAs by paining them

Gerv,
What did you intend by “adverse CAA records”? If a CA runs across a CAA
record that identifies other CAs that are authorized to issue but not them, I
don’t see a reason to report on that to CABF as you suggested in the proposed
ballot. But, I think CAs SHOULD log and then report

raft CAA motion (3)
>
> On 19/01/17 13:25, Doug Beattie via Public wrote:
> > What did you intend by “adverse CAA records”? If a CA runs across a
> > CAA record that identifies other CAs that are authorized to issue but
> > not them, I don’t see a reason to report on th

>
> On 22/02/17 22:32, Doug Beattie wrote:
> > I think we need to talk about negative caching TTL. I recommend we add:
> >
> > -In the event there were no CAA records found, the CA may cache
> > the result for 24-hours or the value of the negative caching TTL.
>
> Hi Doug,
>
> I

I'd like to remain a member of the Validation WG.
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley
via Public
Sent: Monday, November 7, 2016 11:46 AM
To: CA/Browser Forum Public Discussion List
Cc: Jeremy Rowley
Subject: [cabfpub] Validation WG
During the

Gerv,
I have a few comments:
1) We’ve gone from at the time of validation (up to 39 months, which I
agree is unreasonable) to a few days (I think Ryan suggested this) to 10
minutes. I recommend we increase this back to a few days (let’s say 3). This
will allow more flexibility in the

On Wed, Nov 9, 2016 at 11:28 AM, Bruce Morton
>
wrote:
I would prefer if we started CAA with minimum requirements and then make these
requirements more strict over time, rather than creating a policy which is very

I’d be OK with doing a CAA check at the time the contract is signed if that
helps. The case is really the one Jeremy mentioned where the same customer
needs to issue millions/thousands of certificates to the same domain (different
FQDNs) and a well-defined contractual relationship exists. Is

Jeremy,
I agree - For the Managed service model where CAs pre-vet domains we’d like to
check CAA at the domain level and re-use that for all subdomains. Maybe we can
tie CAA into the domain validation process and allow the application of CAA and
domain validation to the same Authorization

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
> [DB] I'm still confused on this and think there is a difference
> between what a CA cert can sign and what a Certification Authority can
> sign. We should try to place requirements on Certificates (and
> identify

Hi Gerv,
I agree that trying to quantity which type of contract is acceptable is
problematic.
We'd like to avoid a requirement to check every FQDN (and especially at the
time of issuance) and check only a higher level FQDN (or Domain Name) on a
"regular" basis by following an approved,

> * The issuing CA and the certificate itself both have a critical EKU
> extension with a single key purpose, which is not id-kp-serverAuth or
> anyExtendedKeyUsage; [DB] I think we should allow multiple EKUs so we
> can support SMIME & Client auth (for example) in one CA.
I would be open to

Gerv,
Are you specifically concerned about the id-kp-emailProtection and what needs
to be combined with that, or is the issue what's the total set of EKUs that
might be needed? In other words, do you care less if a CA has all of the below
except id-kp-emailProtection?
id-kp-clientAuth

Gerv,
While I agree that technically constraining CAs not intended to issue BR
certificates is a good goal, it gets complicated, and limiting those CAs to a
single EKU is essentially impossible. For one, it's very common to have Client
auth and SMIME in one cert.
Why is it so hard? Well,

Gerv,
You sent out a draft ballot, received a bunch of comments, listed some updates
you "agreed to", got more comments, and on and on. Would you be able to send
out an updated ballot which incorporates the comments you're received and which
you feel comfortable accepting so we can continue

g section?
Thanks,
Peter
On Jan 12, 2017, at 4:37 AM, Doug Beattie via Public
<public@cabforum.org<mailto:public@cabforum.org>> wrote:
Kirk,
Carolyn Oldenburg of GlobalSign would like to volunteer to be on the PAG
assuming there is not a conflict because we filed an exclusi

> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org]
>
> On 13/01/17 13:13, Doug Beattie wrote:
> > As it stands, this means that CAs must support Issuer Critical, issue
> > and issuewild today and then to support other Property Tags as they
> > are added (without an

Kirk,
Carolyn Oldenburg of GlobalSign would like to volunteer to be on the PAG
assuming there is not a conflict because we filed an exclusion notice.
Doug
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Kirk Hall via
Public
Sent: Tuesday, January 3, 2017 4:49 PM
To: CA/Browser

Gerv,
Do we need to add any clarification to this statement:
…CA must check for a CAA record for each dNSName in the subjectAltName
extension of the certificate to be issued, according to the procedure in RFC
6844.
As it stands, this means that CAs must support Issuer Critical, issue and

Gerv,
Is there a provision for signing SHA-1 OCSP signing certificates? Perhaps this
is covered in #1, but specifically allowing SHA-1 OCSP Signing certificates
(under SHA-1 CAs which have active SHA-1 TLS certificates) would be a good idea
for clarity.
For #2:
- Can roots issue SHA-1 signed

Ryan,
Ballot 194 allow for a temporary roll-back on the use of certificate data (back
to 39 months) until March 1, 2018. No other changes are being included. The
“security” reverts back to what it was prior to the ballot and we’re not
introducing any loopholes or new Renewal processing.
Here

GlobalSign votes Yes.
It’s not a perfect ballot as I’ve commented on prior, but making CAA checking
mandatory is the only way to add any security value for all domain owners. I
hope we can discuss and work through the challenges as they arise when this
becomes effective later this year.
Doug

Kirk,
This is very comprehensive and detailed, nice work to those involved!. I have
two minor questions.
Item 4.5.13 says: "The CA follows a CA key destruction script for key
destruction ceremonies that includes the following:" (then lists 8 numbered
items).
-Are all 8 of these items

GlobalSign votes No.
I’m sorry I didn’t spend more time on this during the review period, but I
think it’s a mistake to define Domain Name to include wildcard values. I
understand the issues with saying “Domain Name and Wildcard FQDN ”
everywhere in the spec, but I’m sure we could have come

Peter,
It seems strange to include Wildcard Domain Names within the definition of
Domain Name. Calling “*.example.net” a Domain Name doesn’t seen accurate.
Yes, it’s a SAN value but it’s not really a “Domain Name” because you can’t
look it up and access the site “*.example.com”.
Also, your

Gerv,
I realize I just missed the review period, but I wanted to ask a question
anyway.
Regarding this statement:
"The CA SHALL confirm that, as of the date the Certificate issues, the CA has
validated each Fully‐Qualified Domain Name (FQDN) listed in the Certificate
using at least one of

Kirk,
Three things I wanted to comment on.
1) The second paragraph in 3.2.2.4 the statement “as of the date the
Certificate issues” doesn’t make sense. Should this be “as of the date the
Certificate is issued”?
-The CA SHALL confirm that, as of the date the Certificate issues,

Ryan,
Would CAs be able to add additional subsections to their CP and CPS under your
proposal? If so, GlobalSign is OK with the proposed ballot and timeline.
Doug
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via
Public
Sent: Tuesday, April 25, 2017 10:12 PM
To:

Hi Kirk and Ryan,
I think this points out a couple of important changes we should make to the BRs:
1) We should clarify which fields can’t have just meta data characters. The
statement is currently ambiguous in 2 ways:
1.1) It’s listed under “Other Subject Attributes” which implies it’s OK in

There are CAs that are kept off-line other than roots, so perhaps the
requirement should apply to all "off-line" CAs, assuming we can come to
agreement on what that means.
Doug
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Peter Bowen via
Public
Sent: Wednesday, May 10, 2017

n
Name that is one of the values contained in the Certificate’s subjectAltName
extension (see
Section 7.1.4.2.1).
Il 10/05/2017 14:36, Doug Beattie via Public ha scritto:
In reading the BRs, I see the requirement that the SAN must contain at least
one value (7.1.4.2.1), but I can’t find a ref

In reading the BRs, I see the requirement that the SAN must contain at least
one value (7.1.4.2.1), but I can't find a reference that the value in the CN
needs to be in the SAN. Am I missing that link somewhere, or can the value in
the CN be omitted from the SAN? With Chrome depreciating use

I think we should focus on the core changes to remove “any other method” before
we start adding more changes to indicate the version of the BRs that were used,
so I would recommend not including this in ballot 190. We have enough
discussion points now, especially if we’re considering anything

Ryan,
Is this a current summary of the options:
1) Set a date way out in the future for allowing certificates to be issued
using deprecated domain validation methods:
a. Not secure, Browser reject
b. CA like it
2) Set a date within the next 3-6 months for requiring only

Rolling out a new extension and tying the value to the vetting level isn’t
trivial to implement in some of the products, unfortunately. DV is easy
because we verify the domain upon issuance, so those have all been compliant
with the 10 methods as of March. The issue is with the managed PKI

Ballot 187 makes CAA mandatory starting September 8th and there are 3
exceptions listed which make CAA optional. Not all of these are clear to me,
so I'm looking guidance:
1) CAA checking is optional for certificates for which a Certificate
Transparency pre-certificate was created and logged

Hi Peter,
I understand how NC values for domain names relate to CA certificates that have
ServerAuth or Secure email, but I’m not sure about Code Signing, client auth,
document signing and time stamping.
- Is the list of required DN fields listed anywhere for these types to
be

I understand the need to reject CAA lookups if there is DNSSEC on the zone and
if you run into timeout/SERVFAIL/etc errors at any level in the RFC 6844
processing (www.example.com or example.com). Hopefully everyone has
interpreted look up failure and DNSSEC this way.
NSEC/NSEC3 records are

Oct 4, 2017, at 12:01 AM, Doug Beattie via Public <public@cabforum.org
<mailto:public@cabforum.org> > wrote:
The BRs say if a lookup has been retried at least once that is permission to
issue. Does this mean doing
- a full CAA lookup, or
- re-doing o

The BR requirement for retrying failed lookups is ambiguous and we'd like to
receive some clarification, and eventually a ballot to help clarify the BRs.
The BRs stay this:
CAs are permitted to treat a record lookup failure as permission to issue if:
- the failure is outside the CA's

Should we have SSL or TLS in the name of the document since this does not apply
to “All” publicly trusted certificates?
'The Baseline Requirements for the Issuance and Management of Publicly-Trusted
SSL Certificates'
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi

Yes, I agree that it seems IETF has left portions of the spec under defined,
for example how to look up and validate CAA records given all of the types of
errors that could be encountered. Do we expect the IETF WG to focus more
heavily on those, or should this be done in CABForum? I think a

Hi Devon,
Are you planning to change the 27-month references to 825 days at some point?
In some cases, 825 days might exceed 27 months but it’s our understanding that
this would still only require 3 SCTs.
Doug
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Devon O'Brien
via