[cabfpub] Development and deployment working group

[Jeremy Rowley via Public]

Hey Dimitris,

Can you add a spot during the face to face to talk about software deployment 
and development? I thought a working group on that topic may be beneficial 
given the number of software issues reported on Mozilla. I can present on what 
I'm thinking there, but the goal would be to talk about best practices in 
development and deployment of pki software and some of the unique challenges 
associated with doing so as a CA.

Thanks,
Jeremy

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

[cabfpub] Audits and RAs

[Jeremy Rowley via Public]

I think I heard the WebTrust auditors say last week that they have finished
or nearly finished the WebTrust for RAs criteria. The language from Section
8.4 of the guidelines reads:

 

"For Delegated Third Parties which are not Enterprise RAs,, then the CA
SHALL obtain an audit report, issued under the auditing standards that
underlie the accepted audit schemes found in Section 8.1, that provides an
opinion whether the Delegated Third Party's performance complies with either
the Delegated Third Party's practice statement or the CA's Certificate
Policy and/or Certification Practice Statement. If the opinion is that the
Delegated Third Party does not comply, then the CA SHALL not allow the
Delegated Third Party to continue performing delegated functions."

 

We know some CAs use RAs that are not audited under WebTrust/ETSI because
"there is no appropriate audit standard". Now that there is an audit
standards, it seems to me this criteria goes into effect immediately and any
RA not audited would cause the CA to be out of compliance with the BRs. No
additional ballot required since the concept is already baked into the BRs. 

 

Anyone have a different interpretation?  If not, when is the exact date that
the audits should be done? Already? 

 

Jeremy



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

Re: [cabfpub] P-521 Certificates

[Jeremy Rowley via Public]

I don't think so. Microsoft specifically allows them. There are probably use
cases for MS only roots where trust in the OS is needed but not trust in
Mozilla.

-Original Message-
From: Public  On Behalf Of Doug Beattie via
Public
Sent: Tuesday, January 8, 2019 11:53 AM
To: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] P-521 Certificates

Should we update the BRs to forbid P-521 given Mozilla root program forbids
them?

-Original Message-
From: dev-security-policy  On
Behalf Of Jonathan Rudenberg via dev-security-policy
Sent: Tuesday, January 8, 2019 1:31 PM
To: dev-security-pol...@lists.mozilla.org
Subject: Re: P-521 Certificates

On Mon, Jan 7, 2019, at 21:26, Corey Bonnell via dev-security-policy wrote:
> (Posting in a personal capacity as I am no longer employed by
> Trustwave)
> 
> Mozilla Root Store Policy section 5.1
> (https://www.mozilla.org/en-US/about/governance/policies/security-grou
> p/certs/policy/) prohibits the use of P-521 keys in root certificates 
> included in the Mozilla trust store, as well as in any certificates 
> chaining to these roots. This prohibition was made very clear in the 
> discussion on this list in 2017 at
>
https://groups.google.com/forum/#!msg/mozilla.dev.security.policy/7O34-DmZeC
8/fsKobHABAwAJ.
> 
> Below is a list of unexpired, unrevoked certificates which contain
> P-521 public keys (grouped by CA Owner and ordered by notBefore):

I've created https://misissued.com/batch/43/ to track these.
___
dev-security-policy mailing list
dev-security-pol...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

Re: [cabfpub] Audit of RAs

[Jeremy Rowley via Public]

Thanks Ryan. I think your analysis reflects my own thoughts. Particularly I 
appreciate you bringing up this point because it’s the crux of the argument:

 

- DTPs are defined in Section 1.6.1 - any function or requirement under the BRs 
that is performed by an entity not in scope of the CA's audit

 

The difficulty is determining whether something is in the scope of the CA’s 
audit. For example, CAs generally fall along the following lines with respect 
to third party delegation:

 

1.  No audit required of DTP because they audit criteria doesn’t exist 
(which is the argument below) 
2.  No audit required if the DTP provides the information to the CA in a 
repository because the information rests with the CA at this point. No 
requirement for the CA to review the documentation, but the document is 
available to the auditor.

a.  Relies on the interpretation that only certificates are covered by the 
audit, not the party gathering information or providing the services
b.  DTP is considered within the CA audit because the information is 
covered by the audit

3.  No audit required if the DTP provides the information and the CA 
reviews the information

a.  Still ignores the DTP infrastructure
b.  CA is governing use of the data so the DTP is already in scope of the 
CA audit

4.  No audit required if the DTP gathers information and the CA 
independently confirms the information or operates the service 

a.  Full disclosure, this is where I’ve always thought the audit 
requirement stopped
b.  The CA is performing al operations. The DTP is just providing 
information related to the request. 

5.  Audits required of all DTPs if they are providing any information or 
services required under the BRs

a.  This one is more problematic as it starts to include data sources in 
the CA’s audit
b.  Could this also include the cert requester? 

 

Despite the argument I presented below, the entire question relies on 
underlying confusion in the DTP definition (Section 1.6.1) and when exactly a 
DTP applies because their activities are “within the scope of the CA audits”. 

 

 

 

 

From: Ryan Sleevi  
Sent: Wednesday, November 7, 2018 11:54 AM
To: Jeremy Rowley ; CABFPub 
Subject: Re: [cabfpub] Audit of RAs

 

 

On Wed, Nov 7, 2018 at 1:04 PM Jeremy Rowley via Public mailto:public@cabforum.org> > wrote:

I would like to discuss whether unaudited Delegated Third Parties are permitted 
under the BRs. My reading of the BRs (combined with what happened to Symantec) 
is that unaudited RAs are, at least mildly, frowned upon by the browsers. 
However, I think the BRs may be unclear on this point which is leading to an 
increased delegation of responsibilities to unaudited third parties. If there 
is confusion, could we pass a ballot to rule one way or another?

 

I think in order to get a ballot, we need to make sure we understand what is 
causing people's confusion - so this will presumably require those advocating 
such interpretations (whether CAs or auditors) to clarify their positions.

 

Section 8.1 – Certificates Only

“Certificates that are capable of being used to issue new certificates MUST 
either be Technically Constrained in line with section 7.1.5 and audited in 
line with section 8.7 only, or Unconstrained and fully audited in line with all 
remaining requirements from this section. A Certificate is deemed as capable of 
being used to issue new certificates if it contains an X.509v3 basicConstraints 
extension, with the cA boolean set to true and is therefore by definition a 
Root CA Certificate or a Subordinate CA Certificate”

 

Note that certificates all covered by the audit, not Delegated Third Parties. 
The audit for an R/A is “error: no such audit exists”. 

 

So, I think framing it like this naturally leads to confusion. Let's not speak 
about RAs yet - hopefully there's clear consensus that certificates (including 
roots) need to be audited or technically constrained. Audited includes all the 
performance of activities under the rest of the BRs.

 

There's nothing in here to support 'excluding' any activities. This is just a 
basic statement about what's required. A CA issues certificates, everything 
that causes issuance must be audited - including that of third-parties.

  

Section 8.4 – Inapplicable Audit Schemes 

“For Delegated Third Parties which are not Enterprise RAs,, then the CA SHALL 
obtain an audit report, issued under the auditing standards that underlie the 
accepted audit schemes found in Section 8.1, that provides an opinion whether 
the Delegated Third Party’s performance complies with either the Delegated 
Third Party’s practice statement or the CA’s Certificate Policy and/or 
Certification Practice Statement. If the opinion is that the Delegated Third 
Party does not comply, then the CA SHALL not allow the Delegated Third Party to 
continue performing delegated functions.” 

 

Again, the issue is the lack of a

[cabfpub] Audit of RAs

[Jeremy Rowley via Public]

I would like to discuss whether unaudited Delegated Third Parties are
permitted under the BRs. My reading of the BRs (combined with what happened
to Symantec) is that unaudited RAs are, at least mildly, frowned upon by the
browsers. However, I think the BRs may be unclear on this point which is
leading to an increased delegation of responsibilities to unaudited third
parties. If there is confusion, could we pass a ballot to rule one way or
another? 

 

This is not a hypothetical issue as at least two CAs are permitting
unaudited Delegated Third Parties using logic similar to the following:

 

Section 8.1 - Certificates Only

"Certificates that are capable of being used to issue new certificates MUST
either be Technically Constrained in line with section 7.1.5 and audited in
line with section 8.7 only, or Unconstrained and fully audited in line with
all remaining requirements from this section. A Certificate is deemed as
capable of being used to issue new certificates if it contains an X.509v3
basicConstraints extension, with the cA boolean set to true and is therefore
by definition a Root CA Certificate or a Subordinate CA Certificate"

 

Note that certificates all covered by the audit, not Delegated Third
Parties. The audit for an R/A is "error: no such audit exists".  As long as
the certificates (ie, the issuing CA) is covered by a WebTrust/ETSI audit,
there is no requirement for the Delegated Third Party to be covered. If I
include the certs validated by the RA in my random sample, then the RA is
effectively covered by the audit.sort of? Assuming the number of certs the
RA issues is small (1000s compared to 100s), the chance of a sample cert
appearing in the 3% is small.

 

Section 8.4 - Inapplicable Audit Schemes 

"For Delegated Third Parties which are not Enterprise RAs,, then the CA
SHALL obtain an audit report, issued under the auditing standards that
underlie the accepted audit schemes found in Section 8.1, that provides an
opinion whether the Delegated Third Party's performance complies with either
the Delegated Third Party's practice statement or the CA's Certificate
Policy and/or Certification Practice Statement. If the opinion is that the
Delegated Third Party does not comply, then the CA SHALL not allow the
Delegated Third Party to continue performing delegated functions."

 

Again, the issue is the lack of a audit of the RA, which amounts to the CA
giving a statement to the auditor that the RA totally complies with the CA
policies. No real check because the auditor is only looking at the CA, not
the RA. Also, the section refers to 8.1 which covers certificates, not
operations or process. See the previous argument that there is no audit for
RAs, meaning the only check on the RA is the random sample of certificates
reviewed by the auditor. 

 

Section 8.7 - Overriding the Audit 

This is where the primary  main control and where the override comes from:

Except for Delegated Third Parties that undergo an annual audit that meets
the criteria specified in Section 8.1, the CA SHALL strictly control the
service quality of Certificates issued or containing information verified by
a Delegated Third Party by having a Validation Specialist employed by the CA
perform ongoing quarterly audits against a randomly selected sample of at
least the greater of one certificate or three percent of the Certificates
verified by the Delegated Third Party in the period beginning immediately
after the last sample was taken. The CA SHALL review each Delegated Third
Party's practices and procedures to ensure that the Delegated Third Party is
in compliance with these Requirements and the relevant Certificate Policy
and/or Certification Practice Statemen

 

So there is a case where Delegated Third Parties are not audited under 8.1.
What are these? The only thing that makes sense are RAs. This means the CA
can take full ownership of all audit and communication to the RA as long as
they look at 3% (and provide the certs to the auditor of they are included
in the audit by the auditor) and review the practices and procedures. This
places all trust in the CA to ensure these entities are compliance. 

 

1.3.2 - The Exception

This is where the exception comes into play:

With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the
performance of all, or any part, of Section 3.2 requirements to a Delegated
Third Party, provided that the process as a whole fulfills all of the
requirements of Section 3.2. Before the CA authorizes a Delegated Third
Party to perform a delegated function, the CA SHALL contractually require
the Delegated Third Party to: (1) Meet the qualification requirements of
Section 5.3.1, when applicable to the delegated function; (2) Retain
documentation in accordance with Section 5.5.2; (3) Abide by the other
provisions of these Requirements that are applicable to the delegated
function; and (4) Comply with (a) the CA's Certificate Policy/Certification
Practice Statement or (b) the 

Re: [cabfpub] Issuance of certificates for keys reported as compromised

[Jeremy Rowley via Public]

I think Tim is proposing the CA should check their own database of keys revoked 
for compromise to make sure they don’t issue a cert with the same key. For 
example, we re-issued the Blizzard cert that was revoked when the key was 
posted online. We’ve found that regardless of the reason for revocation pretty 
much every CA will issue a cert with a previous key.

 

If the key is compromised, eventually you just get it revoked with enough CAs 
that people don’t use that same key. It’s not exactly hard to generate a new 
end entity key.

 

 

From: Public  On Behalf Of Ryan Sleevi via Public
Sent: Tuesday, August 21, 2018 1:34 PM
To: Tim Hollebeek ; CABFPub 
Subject: Re: [cabfpub] Issuance of certificates for keys reported as compromised

 

I seem to recall we've discussed this before. There are a number of practical 
challenges with this, and that any reasonable proposal would need to provide 
interoperable guidance for. In short, it was substantial work, for questionable 
gain, and while it sounds sensible, the devil is in the details.

 

We need to define what a compromised key is, how it was reported, and how it 
was determined. Without these basic things, you have the potential for 
malicious DoS. For example, we know of some CAs that revoke certificates as 
compromised even with faulty demonstration of proof, or insufficient proof. 
We've had substantial discussions about what counts as reasonable proof versus 
not - e.g. the signing of nonces or the like.

 

You then have to have CAs consistently reporting (e.g. through CRLs and OCSP) 
the reason for revocation. All CAs would need to check all other CAs, or there 
would need to be some meta-service to aggregate. If there is an aggregated 
metaservice, you have to determine how to authenticate that metaservice and its 
information - it becomes a single point of attack for DoS.

 

Once you've built a system that allows revoking an entire key off the Internet, 
you then have to deal with the policy ramifications of such a centralized risk, 
such as giving a single avenue for political or external attacks, such as 
revoking keys as 'compromised' if, for example, they are used to host 
'objectionable' content.

 

As you can see, these are just a few of the issues that present themselves.

 

On Tue, Aug 21, 2018 at 2:42 PM Tim Hollebeek via Public mailto:public@cabforum.org> > wrote:

 

Should we update the BRs to disallow issuance of certificates for key pairs 
that have been previously reported as compromised?

 

I’m not aware of any CAs that currently do that check today, but it’s not that 
difficult to do.  It might be a sensible thing to add in the future.  However 
it only works if all CAs do it, otherwise subscribers will just get their 
compromised key signed by a different CA.

 

-Tim

___
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] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Jeremy Rowley via Public]

Lack of evidence sometimes, to provide notice others. Sometimes its getting 
ahold of the person requesting revocation for some reason. Here are the reasons 
and some of the things we’ve seen. Sometimes we can tell just by looking but a 
lot of allegations we get involve a more thorough investigation: 

 

1. The Subscriber requests in writing that the CA revoke the Certificate; 

- Need to contact the subscriber to confirm this was indeed requested. 
Sometimes these just come through a general alias so figuring out if it was the 
subscriber takes a bit of work. 

 

2. The Subscriber notifies the CA that the original certificate request was not 
authorized and does not retroactively grant authorization; 

-  Again, need to contact the subscriber to confirm. Especially if this was 
alleged somewhere on a website rather than the through the designated channels. 

 

3. The CA obtains evidence that the Subscriber’s Private Key corresponding to 
the Public Key in the Certificate suffered a Key Compromise or no longer 
complies with the requirements of Sections 6.1.5 and 6.1.6; 

- TBH, this one is the easiest to confirm as it requires evidence of the key 
compromise. Investigations on this one are doable in a shorter time period.

 

4. The CA obtains evidence that the Certificate was misused; 

- Misuse depends on the circumstances. Usually requires investigation about the 
use with the subscriber.

 

5. The CA is made aware that a Subscriber has violated one or more of its 
material obligations under the Subscriber Agreement or Terms of Use; 

- Again, requires investigation on what is actually being done. What section 
did they breach? Usually this involves legal on both sides and is a pain in the 
butt. It never concludes within 24 hours (or even 5 days).

 

6. The CA is made aware of any circumstance indicating that use of a 
Fully-Qualified Domain Name or IP address in the Certificate is no longer 
legally permitted (e.g. a court or arbitrator has revoked a Domain Name 
Registrant’s right to use the Domain Name, a relevant licensing or services 
agreement between the Domain Name Registrant and the Applicant has terminated, 
or the Domain Name Registrant has failed to renew the Domain Name); 

- Requires confirmation with the court/licensing service. If this is a 
registrar, expect a super long response time. 7 days would be a boon.

 

7. The CA is made aware that a Wildcard Certificate has been used to 
authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name; 

- Requires involvement of the subscriber to see what happened.

 

8. The CA is made aware of a material change in the information contained in 
the Certificate; 

- We’re made aware of this a lot (change in name, address, etc). Usually it 
requires investigation with a government entity or with the company itself.

 

9. The CA is made aware that the Certificate was not issued in accordance with 
these Requirements or the CA’s Certificate Policy or Certification Practice 
Statement; 

- Often straight-forward but sometimes it can involve a good deal of 
investigation into logs. This one usually doesn’t take us more than a couple of 
hours though.

 

10. The CA determines that any of the information appearing in the Certificate 
is inaccurate or misleading; 

- This is hard one to determine sometimes but it doesn’t often involve the 
customer.

 

11. The CA ceases operations for any reason and has not made arrangements for 
another CA to provide revocation support for the Certificate;

- Never see this happen

 

12. The CA’s right to issue Certificates under these Requirements expires or is 
revoked or terminated, unless the CA has made arrangements to continue 
maintaining the CRL/OCSP Repository; 

- Sort of happened with Symantec. However they made arrangements to continue 
maintaining the repository.

 

13. The CA is made aware of a possible compromise of the Private Key of the 
Subordinate CA used for issuing the Certificate; 

- This hasn’t happened in my experience

 

14. Revocation is required by the CA’s Certificate Policy and/or Certification 
Practice Statement; or 

- I don’t know of any CPS that goes beyond these requirements for TLS certs. 

 

15. The technical content or format of the Certificate presents an unacceptable 
risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser 
Forum might determine that a deprecated cryptographic/signature algorithm or 
key size presents an unacceptable risk and that such Certificates should be 
revoked and replaced by CAs within a given period of time).

- This one isn’t an issue either. By the time something passes with the BRs, 
every CA is well aware of the need to migrate. 

 

From: Ryan Sleevi  
Sent: Tuesday, August 21, 2018 1:44 PM
To: Jeremy Rowley 
Cc: CABFPub ; Bruce Morton 
; servercert...@cabforum.org
Subject: Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation 
Timeline Extension

 

This is where the reporting 

Re: [cabfpub] [EXTERNAL]Re: Issuance of certificates for keys reported as compromised

[Jeremy Rowley via Public]

We’re talking the former (re-signing a key used in a previous cert that was 
revoked by the CA itself for key compromise).  There isn’t an obligation for a 
CA to check to see if a key is compromised. The current process just kicks off 
a perpetual 24 hour revocation period as long as the public can find the 
compromised key. 

 

“Thus, I would expect that CAs are checking for reuse of compromised private 
keys prior to issuance.”

This is definitely not happening. 

“My assumption is a certificate which has been revoked due to compromise has a 
“weak Private Key.” As such, based on the current BRs, a CA should reject 
certificate requests using a key from a certificate that they revoked due to 
compromise.”This also doesn’t happen across CAs. Too ambiguous on what is a 
“weak Private Key”, although this is mixed results (all CAs seem to prevent 
1024 bit certs but not all fail for Heartbleed issues) 

 

From: Wayne Thayer  
Sent: Tuesday, August 21, 2018 3:56 PM
To: Bruce Morton ; CA/Browser Forum Public 
Discussion List 
Cc: Tim Hollebeek ; Jeremy Rowley 
; Ryan Sleevi 
Subject: Re: [cabfpub] [EXTERNAL]Re: Issuance of certificates for keys reported 
as compromised

 

On Tue, Aug 21, 2018 at 2:15 PM Bruce Morton via Public mailto:public@cabforum.org> > wrote:

BR 6.1.1.3 states “The CA SHALL reject a certificate request if the requested 
Public Key does not meet the requirements set forth in Sections 6.1.5 and 6.1.6 
or if it has a known weak Private Key (such as a Debian weak key, see 
http://wiki.debian.org/SSLkeys).” 

 

My assumption is a certificate which has been revoked due to compromise has a 
“weak Private Key.” As such, based on the current BRs, a CA should reject 
certificate requests using a key from a certificate that they revoked due to 
compromise.

 

If we're talking about the same CA re-signing a key previously used in a 
certificate that the CA revoked due to key compromise, then [if nothing else] 
the CA must revoke the new certificate within 24 hours per 4.9.1.1(3). Thus, I 
would expect that CAs are checking for reuse of compromised private keys prior 
to issuance.

 

If we're talking about other CAs rejecting the compromised key, then I have to 
question whether there is enough benefit to offset the substantial effort 
involved in designing and running a system that isn't susceptible to the 
concerns Ryan raised. It'd be interesting to see a proposal.

 

Bruce.

 

From: Public [mailto:public-boun...@cabforum.org 
 ] On Behalf Of Tim Hollebeek via Public
Sent: August 21, 2018 4:55 PM
To: Jeremy Rowley mailto:jeremy.row...@digicert.com> >; Ryan Sleevi mailto:sle...@google.com> >; CA/Browser Forum Public Discussion List 
mailto:public@cabforum.org> >
Subject: [EXTERNAL]Re: [cabfpub] Issuance of certificates for keys reported as 
compromised

 

Yes, certainly, at a minimum, CAs should not be issuing new certificates for 
keys they themselves have previously determined to be compromised.

 

As you correctly note, this is currently a fairly common occurrence.

 

-Tim

 



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

Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension

[Jeremy Rowley via Public]

I’m surprised no one has given any examples yet. There are a lot of them if you 
go through the revocation requests:

1.  Certs reported on a long weekend where we can’t reach anyone at the 
organization. You’re looking at 4 days there in the US sometimes. Outside of 
the US there can be up to a week or so where response are difficult (especially 
in Europe and China)
2.  See the Blizzard cert that we had to revoke. (Although this mixes 
investigation with revocation timelines)
3.  Sometimes we get requests for revocation through third parties alleging 
key compromise without proof. Takes a while for them to generate a CSR and send 
it over.
4.  Emails about cert misuse on sites that contain wares or similar items 
can take 7 days to figure out whether it is indeed  phishing or something 
similar. 

 

I’d have to dig out the exact emails on each off these to send over, but 7 days 
for investigation is pretty short unless we get a copy of the private key in 
the first go-around from the reporting entity. 

 

 

From: Public  On Behalf Of Ryan Sleevi via Public
Sent: Tuesday, August 21, 2018 11:08 AM
To: Bruce Morton ; servercert...@cabforum.org
Cc: CABFPub 
Subject: Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation 
Timeline Extension

 

 

On Tue, Aug 21, 2018 at 1:01 PM Bruce Morton via Servercert-wg 
mailto:servercert...@cabforum.org> > wrote:

Per Mike’s items:

 

1.  7 days would be preferable as this would provide a “business week” for 
the CA to investigate the issue. It will also provide 2 extra days to have 
reach and discuss the issue with the Reporter and the Subscriber.

As Mike summarized correctly, Google felt and feels that 7 days is too long. We 
repeatedly asked for specific examples and details of where the additional time 
would be valuable, and to date, no CA has provided them. We had previously 
proposed that anything longer should require a mandatory public, unredacted 
incident report from the CA, and the concession to avoid such a requirement was 
to find a balance, while also ensuring that CAs were gathering and collecting 
concrete reports to provide that.

 

2.  Given the examples for unacceptable risk, I would assume that this item 
would have a deadline set in the BRs. We have done this before with 
non-registered domain name certificates. So if the certificate has not been 
revoked by the deadline, then it must be revoked immediately. As such, perhaps 
this requirement should be better defined and also moved to the 24 hour section.

3.  I do agree that the CA should work with both the Reporter and the 
Subscriber; however, please note that the investigation may mean that the 
certificate will not be revoked. Also, having a preliminary report within 24 
hours may not be feasible to have a report with substantial substance as there 
may not be time to discuss with the Subscriber. I do suggest that within 24 
hours the CA should advise the Reporter and the Subscriber that an 
investigation has started which may result in the certificate being revoked.

I don't think this is something we'd agree on. As noted above, our goal is to 
improve the transparency. There are some who've said that the best solution to 
these issues is to know what it's like by going to work for a CA. Absent 
changing employers, the next best thing is going to be to improve the 
transparency of the ecosystem, which will improve the trust overall. CAs are 
already required to conduct their activities within 24 hours - this doesn't 
relax that particular item, but allows them to make it available as a report, 
while offering greater flexibility. That seems a meaningful compromise to 
balance the need for transparency while providing CAs and Subscribers some 
degree of flexibility.

 

 

 

Thanks, Bruce.

 

From: Servercert-wg [mailto:servercert-wg-boun...@cabforum.org 
 ] On Behalf Of Mike Reilly (GRC) 
via Servercert-wg
Sent: August 21, 2018 12:17 PM
To: Doug Beattie mailto:doug.beat...@globalsign.com> >; CA/B Forum Server Certificate WG Public 
Discussion List mailto:servercert...@cabforum.org> 
>; Tim Hollebeek mailto:tim.holleb...@digicert.com> >; Wayne Thayer mailto:wtha...@mozilla.com> >
Cc: CA/Browser Forum Public Discussion List mailto:public@cabforum.org> >
Subject: [EXTERNAL]Re: [Servercert-wg] [cabfpub] Ballot SC6 - Revocation 
Timeline Extension

 

Hi all.  Some areas of clarification requested from the Microsoft team:

 

*   I don’t remember why 5 days was chosen vs. 7 or 3 days.  I believe it 
was we felt 7 days was too long but 5 days was reasonable.  I believe we also 
considered the scenario where an incident occurs on a Friday evening of a three 
day weekend and the difficulty of the CA dealing with a subscriber who may be 
unavailable over a weekend for a non-urgent revocation requirement.  5 days 
covered that scenario without being too far past 24 hours.  3 days was felt to 
be too short 

Re: [cabfpub] How do you handle mass revocation requests?

[Jeremy Rowley via Public]

Here’s 10 CSRs that people can correlate with the CT logs. I’ll create another 
100 or so to dispel any doubt. 

 

-BEGIN CERTIFICATE REQUEST-

MIICwDCCAagCAQAwezELMAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxEDAOBgNV

BAcTB05ld2J1cnkxDzANBgNVBAoTBkplcmVteTEgMB4GA1UECxMXUHJvb2Ygb2Yg

a2V5IGNvbXByb21pc2UxGDAWBgNVBAMTD3d3dy5leGFtcGxlLmNvbTCCASIwDQYJ

KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMamagziY67jAV1XWBT2UBudz8leqPeZ

nMGCP9Sct2qc5tDDLz34QIMFO9mv4eDRduMOTG7rwQygKPvI0mAKzKDJCxUvKLYJ

Th/IALgkHfSvv7UzXUxF2kxviuvTCoP0Oee3DUJl4V614R2BnEtEpjEC4WNZglIU

ytQiX36u4WQEbU1LGxp16+Rqz55TOnqRaUNlCCVjB99A3dvxYxpa+6qUHt2aeEyW

WBguBq4sDzOeeLCcnfiCywbDKD4YeqQxvn1EJGBrCQnOf5UdHidJB3ZKKngYWKaZ

48nYK2CqM1dq44vIH6EezGq+0Xs8EFJfi2mjDghfziiX1UtpUt2/vUcCAwEAAaAA

MA0GCSqGSIb3DQEBCwUAA4IBAQA/HM907Hc/rV+olpHW8n1N0UkhfbVHjSegFhQZ

2Wn4jFKAargvOCGDChThcnUbquptKpTFVaKJap0JB2T+fCI3WAMPG8CJKakcOjG/

ZKheN3fNGUiaNk/Wyh/f6XnhWbchIK2OpcsSUAA5ju14bqs2epWl17c0MBPVY5sJ

wFIBrNVjqji3Zkf7aE9GSMx36d8swfhqwomvFvO5SGKspPm2eRpBPwi8lRORDxz3

cAoG4TU3/7xs2XAyTE27UQwdrUo7jkVUlCFoWf6DySHEy7CKTz3Vwu9ABtNdBtG9

oEnWxhIhBPcYOwCrGkiJGuRImFAfLifHWvLUNqGKpz/nEr+c

-END CERTIFICATE REQUEST-

-BEGIN CERTIFICATE REQUEST-

MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxEDAOBgNV

BAcTB05ld2J1cnkxDzANBgNVBAoTBkplcmVteTEcMBoGA1UECxMTUHJvb2Ygb2Yg

Y29tcHJvbWlzZTEYMBYGA1UEAxMPd3d3LmV4YW1wbGUuY29tMIIBIjANBgkqhkiG

9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqS0TSQbsGiJdAYfhuNrGzvXX4XvwToLBq+Hx

trxKq8zoWIRtimRuH66uRmVy0I/lR78u4FEewAjblaS+v1jTLNopik+taBiFHudn

/RGliOcKFohp4BYZuSZRRt3uLN5z8Jr5VbRMzZy6SNp3wX3f+Ie/XsAV04TXmbSv

+V8ZUjxzj1448DsCFL1NNDUcoic/MUcW+fsu9VuxhdETOwrf7CgJ91FgzwHHSMKL

Mq6DwY6xF90KQ5vInhYhRQ447zoSW1ABnmF+gPxDjXXb5pCh4aua8wOv3AmiZbbn

Nnkv9y1YXIeBJ1o1zbTt51v62Qu4LeRYVfWjhI1sn8k96DH8mQIDAQABoAAwDQYJ

KoZIhvcNAQELBQADggEBADgA4tGSyIpAA9uXooQivo9NH7lZH+M4bXpn+nOmNxn/

aRzmbg9NksRKrQoN0/CkWpiu6vwp31gAG2eIpnvNX9ltzPD2/yHAQCLUZmiGZnUP

fUdV1t7Z1EZ9Mj7YmlAN5NuQPAu7SL5fZ8UJSzzY1H7AuECU29j81dK2jLxRR1p6

PaajUGPAvraVTZND4JGQJpIazrF+mVDADdt1aOntr6lj+CC92E5oQxCWtU8uUX7Y

k5OJdewmNlVIk7wtcuVA2ju3jFlNtHP66DE/UDlcx5X5vE2qFq3aZFAqUAf0XXWW

bagqqjxfHSQaNVGlWBkJb0eCdD+DW8IK0nuw5GP2rzY=

-END CERTIFICATE REQUEST-

-BEGIN CERTIFICATE REQUEST-

MIICwDCCAagCAQAwezELMAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxEDAOBgNV

BAcTB05ld2J1cnkxDzANBgNVBAoTBkplcmVteTEgMB4GA1UECxMXUHJvb2Ygb2Yg

a2V5IGNvbXByb21pc2UxGDAWBgNVBAMTD3d3dy5leGFtcGxlLmNvbTCCASIwDQYJ

KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfZnCmYERBmZPEMdK5yvvC0QXjB1FQo

bu4IC9W1ThdFySkJL6t2MeoxbaTW8hwdATf8JHlRnrpevXStUsYDZShxpsQePZk8

LUW5OHQ6W/XDbGo4tC69Q3XTYvLeX+3q971mbiyFpBondTKZaKZYAR5omV7e/Olt

ZzN1yqyX551NsSwDGTrgBqCU2XQzYu9Tl9Nibjl4yCKCG9/JbgGa+gy8j1eKWxIt

lW7jmJID8s0N2v0ed1lvxr7A3oCiYef4TSi2RjLyZThGw1a7j3QqlBeGIqo89XtG

8GxA2nNSGx7gnIceMGGUd0q9iGQl1gc+FOI5oBbyjLcMCty2YInMQucCAwEAAaAA

MA0GCSqGSIb3DQEBCwUAA4IBAQBQyDCiBYXRMOryHhVVW52kY6wvsgWsPXLR0piQ

FJKP/drPdqgs/uxY6Nx163sNaiWPEI0tUWSmnuPe43qAyIqJXmnd/C6EqGy+ZI1Y

lf0XAfqVzJ+tc9639pSkGfeGxU75qdPwWqbwzEEdNZCDR/4QqzhGgMLyvH7icoc0

7ikxxwyUiKpP4h3nAV7Fg4EMKeEn/3m+vM0aGnZNx16WHpQF/VnyBM8NimADmO/u

vywC2TbLNBYYYG7dlLUk7fYfoFY5okel4z2fjmaNhuQQEpffJ366DC41A3fWDgp8

j1Ok8PfhiVySEwdSCNgpZbHnSwxodk4E3aZ22kCa2f7nOzDd

-END CERTIFICATE REQUEST-

-BEGIN CERTIFICATE REQUEST-

MIICwDCCAagCAQAwezELMAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxEDAOBgNV

BAcTB05ld2J1cnkxDzANBgNVBAoTBkplcmVteTEgMB4GA1UECxMXUHJvb2Ygb2Yg

a2V5IGNvbXByb21pc2UxGDAWBgNVBAMTD3d3dy5leGFtcGxlLmNvbTCCASIwDQYJ

KoZIhvcNAQEBBQADggEPADCCAQoCggEBALjEWXaHdMifi0LbL0GrnYV6uoltTicU

ywDOkSz/cReCI6gzxb1jpuQu1iVAkmiZUmPk4sPjc4e/OvAo0IyXgVEqBVcB4cmB

JTdWFj4fde8G9/NWoKIHIRVS4envx4jjRFEh6uDI9o4pDcpfvjh59s1RCjqU9EqX

DueUoKCk7eynjBxePNYZtZL5xBbBRIeqkjtBALtdnQdkbMTBAHJT4WvK2y9ExtWY

aJAoAf0ZYmQOeqzXZC4w1FKs7/GEa1qaPjyxe596LvZvOMZbB49gUYou6lhmG+ga

PaJIGm53/A4PgLnCisEjrVL46YB/k/EzTQtwq5jRg5usIL0/YCJlvCkCAwEAAaAA

MA0GCSqGSIb3DQEBCwUAA4IBAQCgCziprbbD+aS22QHBMOnjy5r7iYiteKO1uB1o

zdaKpNBg32+tNyYsNazijAb0rcyFLGAeTfjbWQ5YDbK44qGmKxhO5nyeUkb9/ulI

scT94Trwu8j77DTxaFNTziETbw5KIBfiC7M5cD+vQ2UexJ8giv9s7ZchXY/hK8TA

IPY1jfEzioEgjap2bXhZ7GGHhjNg/3DIHCy2dD+eDeTsHhZQ+4ndfMeydg9fn6se

20A73X5rFGYKtp3z19stTDjXFDVyf/ngXtyti830ebQgmxRLJRAKV+MSHrdxW4Jj

qkuW6fmTj2s3x8iTKecd5Q/NOKt2XjOMldc6eKA4VSi3QNuc

-END CERTIFICATE REQUEST-

-BEGIN CERTIFICATE REQUEST-

MIICwDCCAagCAQAwezELMAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxEDAOBgNV

BAcTB05ld2J1cnkxDzANBgNVBAoTBkplcmVteTEgMB4GA1UECxMXUHJvb2Ygb2Yg

a2V5IGNvbXByb21pc2UxGDAWBgNVBAMTD3d3dy5leGFtcGxlLmNvbTCCASIwDQYJ

KoZIhvcNAQEBBQADggEPADCCAQoCggEBALlY3wwEZcO3U4HGuYE6atvaG3vOiOGq

y1W1Nwv4xVCiVkTECgbumYZyBjq1XxVKC1dNJ2nzxDSIhPNxnJZHA7v5SvSf60+Z

1W+QmvznlRfqptKNt9L26LCRAFppjfT5Z0F0fw300e7NawkWKxNyujDsltpFrkNP

72SvHWizvMpySx5aclAb/TD6iAY1NQh1PUVdeCJZMtZreD+v3UOKPsnztdRgYe/f

FbPRYQaxAaKYm0oYUZ0x0kurTjDdGQHtm/0H253KPDFHiC9bWCqljFTqUFT2v2TG

2m04pv+wMLFIt8FpQwzi7M7v0O1TD4hBLswUGSAmCxu6fOaMJFUAM1ECAwEAAaAA

MA0GCSqGSIb3DQEBCwUAA4IBAQCnl8UUGLPd76FgaBtwZo9cktY1reJtImP8/613

[cabfpub] How do you handle mass revocation requests?

[Jeremy Rowley via Public]

I posted this on the Mozilla dev list but it also impacts the Baseline
requirements.  I realize the list is mostly duplicative but thought I'd
share here as well so we can discuss clarification around "subscriber"

 

 

Hi everyone,

 

I wanted to share an incident report regarding the revocation of certain
certificates ordered through a reseller.

 

On February 2nd, 2018, we received a request from Trustico to mass revoke
all certificates that had been ordered by end users through Trustico.
Unfortunately, the email was not sent to the appropriate certificate problem
reporting channels and did not surface immediately so we're delayed in
sharing the concerns and information. Once we were alerted, the team kicked
off a debate that I wanted to bring to the CAB Forum. Basically, our
position is that resellers do not constitute subscribers under the Baseline
Requirement's definitions (Section 1.6.1). As such, we needed to confirm
that either the key was compromised or that they revocation was authorized
by the domain holder (the subscriber) prior to revoking the certificate. The
certificates were not alleged as compromised at that time.  

 

Later, the company shared with us that they held the private keys and the
certificates were compromised, trying to trigger the BR's 24-hour revocation
requirement.  However, we insisted that the subscriber must confirm the
revocation request or there must be evidence of the private key compromise. 

 

Normally, we permit partners to revoke and manage the certificates freely on
behalf of their customer, with DigiCert providing all validation and
issuance services. However, the sheer number of revocation requests (50k)
and allegation of compromise triggered concerns around the impact to the web
and browser users. Therefore, this was categorized as high risk, especially
considering the relationship between the reseller and DigiCert is
terminating.

 

On 2/27/2018, at my request for proof of compromise, we received a file with
23k private keys matched to specific Trustico customers. This definitely
triggered our 24-hour revocation processing requirement under 4.9.1.1.3.
Once we received the keys, we confirmed that these were indeed the matching
private keys for the reported certificates. We will be revoking these
certificates today (February 28th, 2018).

 

At this time, Trustico has not provided any information about how these
certificates were compromised or how they acquired the private keys. As is
standard practice for a Certificate Authority, DigiCert never had possession
of these private keys.

 

Currently, we are only revoking the certificates if we received the private
keys. There are additional certificates the reseller requested to have
revoked, but DigiCert has decided to disregard that request until we receive
proof of compromise or more information about the cause of this incident.

 

DigiCert sent out emails to the affected customers in order to notify them
that their certificate(s) are being revoked. This revocation only affects
those customers and there is no additional exposure that we are aware of at
this time, nor any reason to believe there is.  

 

This raises a question about the MDSP policy and CAB Forum requirements. Who
is the subscriber in the reseller relation?  We believe this to be the key
holder. However, the language is unclear. I think we followed the letter and
spirit of the BRs here, but I'd like feedback, perhaps leading to a ballot
that clarifies the subscriber in a reseller relationship.

 

This also brings up a ballot about the level of due diligence required for
cert revocation. We generally believe that the private key or demonstration
of domain control is sufficient to request revocation. Others are at the CAs
discretion. Should we clarify what the due diligence looks like? Are there
other things we should have done or been doing? 

 

What kind of transparency would the Mozilla community like around this
issue? There aren't many more facts than I shared above, but there is a lot
of speculation. Let me know what I can share to help alleviate confusion and
answer questions.

 

Jeremy

 

 

 



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

Re: [cabfpub] [EXTERNAL]Re: Ballot 218: Remove validation methods #1 and #5

[Jeremy Rowley via Public]

3. BR 3.2.2.4.1 is performed using registrar information to confirm the 
organization has registered the domain name. The QIIS is used to identify 
relationships if the domain is registered to a parent or subsidiary.

- This is the hand-wavy part. Looking in WHOIS to see some org listed does not 
tie the org to the domain. Anyone can list anything in the WHOIS corporate 
details.  

 

4.BR 3.2.5 is performed by finding contact information for the organization 
using a QIIS. The authorization contact is called at the organization using 
this information. The authorization contact is asked to confirm that a 
certificate with the organization name, using the domain name(s) requested, can 
be issued to the certificate requester. 

- Do you do this step for every domain? I’m guessing it’s done once every 825 
days when you verify the org to confirm the account is controlled by that org.  
Is there any tie between the person called and the domain name other than that 
the person called requested the certificate for the domain? 

 

What’s missing from this process is any awareness of the domain owner that a 
certificate is being requested by Company ABC.  Because WHOIS is unverified 
information with respect to company info, there’s no actual technical tie 
between the org and the domain. Because names are not globally unique, there’s 
no determination whether the correct entity applied for the certificate (ie - 
DigiCert, Inc. a Utah corp and DigiCert, Inc. a Malaysian entity). 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Bruce Morton via 
Public
Sent: Thursday, January 4, 2018 7:49 AM
To: Ryan Sleevi 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] [EXTERNAL]Re: Ballot 218: Remove validation methods #1 
and #5

 

Hi Ryan,

 

Here are some details on how we perform this method.

 

For an OV certificate, we perform method #1 as follows:

 

1.  Order is received with the subject name, SANs, a certificate requester 
and an authorization contact. The authorization contact must be employed by the 
organization in the subject name.
2.  BR 3.2.2.1 is performed to confirm the identity of the organization. 
This task is done with using a QIIS.
3.  BR 3.2.2.4.1 is performed using registrar information to confirm the 
organization has registered the domain name. The QIIS is used to identify 
relationships if the domain is registered to a parent or subsidiary.
4.  BR 3.2.5 is performed by finding contact information for the 
organization using a QIIS. The authorization contact is called at the 
organization using this information. The authorization contact is asked to 
confirm that a certificate with the organization name, using the domain name(s) 
requested, can be issued to the certificate requester. 

 

 

Thanks, Bruce.

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: January 4, 2018 12:09 AM
To: Bruce Morton  >
Cc: Rich Smith  >; 
CA/Browser Forum Public Discussion List  >; Kirk Hall  >
Subject: Re: [EXTERNAL]Re: [cabfpub] Ballot 218: Remove validation methods #1 
and #5

 

 

 

On Wed, Jan 3, 2018 at 5:27 PM, Bruce Morton  > wrote:

I disagree.

 

Removing, changing and adding back in method #1 is not a productive exercise. 
This method has been used for probably 20 years and yet we never see any 
notifications, articles, alerts, etc. of how this method was defeated by an 
attacker.

 

I think it's exceptionally dangerous to rest on that, particularly since CAs 
such as Entrust don't make available to the public their processes and controls 
to inspect whether or not they're vulnerable. I am greatly appreciative to 
Jeremy sharing the case of customers from a CA they acquired not being 
validated to the level that DigiCert holds itself - but that's hardly to be 
expected, unless we are to suggest DigiCert should buy out every other CA.

 

It was this philosophical opposition that resulted in MD5 being exploited 'in 
the wild' - CAs ignoring the literature and research and demanding 'proof it 
applied'

 

Does Entrust (or the CAs it has acquired) use this method? Can you share the 
details that are used to do this?

 

I stand by the assertion that while it may be possible to restrict what is done 
under 3.2.2.4.1 to be 'secure', that is not what it is in the language, and 
what is presently executed is demonstrably insecure. If we are to suggest that 
we, as an industry, care about security of our users, then we should make 
tradeoffs that favor security.

 

 

Note, I agree that method #1 can be approved in the BRs, but please advise 
which CAs have not already improved 

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Jeremy Rowley via Public]

The attack vector is easier than that. 

1.  I use very stringent processes to verify that Google, Inc. is a legit 
company in Utah.
2.  I verify that Jeremy did indeed incorporate Google, Inc. 
3.  I call Jeremy at the phone listed for Google, Inc., the Utah corporation
4.  The domain information shows Google, Inc. as owning google.com
5.  Certificate issues.

 

Obviously this would be caught in every CA’s high risk checks, but the point 
remains valid. Regardless of the expertise and thoroughness of the org check, 
the specs lack any time between the verified org and the actual domain because 
orgs are not unique on a global basis.

 

Jeremy

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Thursday, December 21, 2017 9:58 AM
To: Adriano Santoni <adriano.sant...@staff.aruba.it>; CA/Browser Forum Public 
Discussion List <public@cabforum.org>
Subject: Re: [cabfpub] Verification of Domain Contact and Domain Authorization 
Document

 

Adriano,

 

Do you have an example of how you believe 3.2.2.4.1 can be used correctly? 

 

Specifically, it does not describe the process for validating that the 
Applicant is the Domain Contact with the Registrar - this isn't equivalent to 
using WHOIS.

 

Here's just one scenario:

- I ("Ryan Sleevi") apply to Foo CA for example.com <http://example.com> , 
which is owned by "Andriano Santoni's Lightly Validated Certificates" - you.

- Foo CA decides to employ 3.2.2.4.1, using 3.2.2.4(1)

  - Note, as worded, all of 3.2.2.1 can be read as 'optional' for DV certs, 
thus automatically met, but lets pretend its OV

  - They verify "Andriano Santoni's Lightly Validated Certificates" is a real 
company with a real existence using a QGIS. That's all that's needed - there's 
no binding to the Applicant, just an existence proof of the data.

  - Alternatively, I send a photoshopped letter claiming your company exists, 
valid under 3.2.2.1(4)

  - Alternatively, the CA declares that "Google Maps" is a Reliable Data Source 
(it isn't, but again, underspecified), and verifies that there's an entry under 
3.2.2.1(2) - despite the fact I just added the entry

- They then need to verify whether or not I'm authorized to speak for your 
company.

  - The information used in 3.2.2.1 doesn't have to be used ("the CA MAY use 
..."), but remember, I may have made it up under 3.2.2.1

  - The CA can directly call me, Ryan Sleevi, asking if I'm authorized ("the CA 
MAY establish the authenticity of the certificate request directly with the 
Applicant Representative")

  - The requirement to use an RMOC simply means that Foo CA could decide to 
call up Jeremy, since Jeremy knows me, and say "Hey, does Ryan work for Adriano 
Santoni" - that's all that's required.

- Finally, the CA contacts the registrar, and says "Hey, does Adriano Santoni's 
Lightly Validated Certificates own example.com <http://example.com> " - and the 
registrar says sure

  - Note: There's no consensus whether we're talking about the same 
organization - perhaps I created a version incorporated in the US, but you're 
incorporated in Italy

 

These are just a few of the legal-but-bad things you can do. I'm sure we'll see 
the normal rush from some CAs saying "Yes, but we'd never do that" - while 
ignoring the fact that some could, as it's valid under the language, and we 
consistently see "That which is valid (or subject to misinterpretation) is 
possible to use"

 

 

Could you provide an example of how you believe 3.2.2.4.1 "should" work and 
offer the same level of assurance as the other methods, without normatively 
prescribing the data sources used? From conversations with both current and 
past employees of CAs, I am adamantly convinced that there is not a consistent 
standard of reliableness being applies. Google Maps being used as a Reliable 
Data Source is not a hypothetical, despite it allowing community edits.

 

 

On Thu, Dec 21, 2017 at 4:00 AM, Adriano Santoni via Public 
<public@cabforum.org <mailto:public@cabforum.org> > wrote:

Jeremy, I am not sure I fully understand the problems you describe. 

Would it be possible for you to provide some concrete example related to method 
#1, with some details, without of course mentioning specific certificates 
and/or organizations?

 

Il 19/12/2017 22:30, Jeremy Rowley via Public ha scritto:

Hi all, 

 

When reviewing the Symantec validation methods and the customers using each 
method, I found an alarming number of customers verified under 3.2.2.4.1 
(Verification of a Domain Contact) or 3.2.2.4.5 (Domain Authorization Document) 
where the domain is not technically associated with the entity. These two 
methods need improvement or removal as the way they are currently lacks 
sufficient controls to associate the domain verification with the actu

Re: [cabfpub] [EXTERNAL]Re: New RFC on CT Domain Label Redaction

[Jeremy Rowley via Public]

Do you want us to send our comments directly to you or would you care if we 
edit the wiki? Or do you not care?

-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Kirk Hall via 
Public
Sent: Monday, November 27, 2017 10:41 PM
To: Gervase Markham ; CA/Browser Forum Public Discussion List 

Subject: Re: [cabfpub] [EXTERNAL]Re: New RFC on CT Domain Label Redaction

Gerv, your summary document is a brilliant idea, and a very good start.  We 
will discuss this approach on our CABF teleconference on Thursday.

Entrust Datacard wants to offer additional comments to the summary.  I'm afraid 
if everyone just modifies the document on a wiki, it could become a mess.  Can 
we all send our additional comments to you instead, and let you organize and 
add them to the master document?

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org]
Sent: Tuesday, November 21, 2017 7:04 AM
To: Kirk Hall ; CA/Browser Forum Public 
Discussion List 
Subject: [EXTERNAL]Re: [cabfpub] New RFC on CT Domain Label Redaction

On 03/11/17 23:23, Kirk Hall via Public wrote:
> This email is to lay out the course we want to follow to complete the 
> technical specs for Redaction in the IETF, and also to address the 
> recourse issues and consider appropriate changes to the Forum’s 
> Baseline Requirements in response.

In order to try and bring some light to this discussion, I have attempted to 
summarise the arguments for and against CT redaction here:
https://clicktime.symantec.com/a/1/956oI21haQ09DJzZbJMK9oUu5I_gG9rEh8YT0Sh9fgo=?d=oEZ0lomfPRzv4HCGLY8dPYw2ZuLdFpOasUOjGmoKX5hci_qM8LyDD4lsF4OdLEy0hDZZIxutKDdpyDLtA5U1R9XDoGf-49-ytUesvokLmaxyw_YkpmCnsVzH9pW2KzvNzW-dUPsKtf0kWy1W09j5xYIpt7nkUvnJn2_9nNZqBvRF2bOCkAhZj-a4q_31z89hW48-dAVscWHWgvVqYU6yyavX5VzYmOsfc0UdNZKlBuzWkD_vflGgAoIAq3uzqmux1XdKmyW1Xe1OUSmCZW2aTx3zg7wqm26-tO_koAJ03ZpWHpiv0PCTR58W-2L1JORx5EEnNd_9g1GloMbN4wI_nTLQJ_tIi1c7kN3nZZtlJeeclegRimBtGNre8C2hSJ37QYrRIaAMq9TfYF61JAVRpbb_hjolB5shOH0aDOZYICoVHUyf7gqdEbhKDZMLgraSZQx_7w%3D%3D=https%3A%2F%2Fwiki.mozilla.org%2FCA%2FCT_Redaction

I can only extract data from recently-posted messages and IDs, so the document 
is clearly incomplete. If you have an additional consideration to add, or a 
response to an existing one, or want to improve the text, feel free - it's a 
wiki. If you are unable or unwilling to get a login (they do need approving, 
but it doesn't normally take long) then you can send edits to me, although I 
reserve the right to edit your edits ;-)

Gerv
___
Public mailing list
Public@cabforum.org
https://clicktime.symantec.com/a/1/QlQth1g1cp4je-BBRNXx43y50g8Z1zmTTIeYnzsIbQA=?d=oEZ0lomfPRzv4HCGLY8dPYw2ZuLdFpOasUOjGmoKX5hci_qM8LyDD4lsF4OdLEy0hDZZIxutKDdpyDLtA5U1R9XDoGf-49-ytUesvokLmaxyw_YkpmCnsVzH9pW2KzvNzW-dUPsKtf0kWy1W09j5xYIpt7nkUvnJn2_9nNZqBvRF2bOCkAhZj-a4q_31z89hW48-dAVscWHWgvVqYU6yyavX5VzYmOsfc0UdNZKlBuzWkD_vflGgAoIAq3uzqmux1XdKmyW1Xe1OUSmCZW2aTx3zg7wqm26-tO_koAJ03ZpWHpiv0PCTR58W-2L1JORx5EEnNd_9g1GloMbN4wI_nTLQJ_tIi1c7kN3nZZtlJeeclegRimBtGNre8C2hSJ37QYrRIaAMq9TfYF61JAVRpbb_hjolB5shOH0aDOZYICoVHUyf7gqdEbhKDZMLgraSZQx_7w%3D%3D=https%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fpublic


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

[cabfpub] DigiCert representatives

[Jeremy Rowley via Public]

I'm please to announce that Tim Hollebeek has joined DigiCert as our
technical liaison to various industry groups.  The current plan is to have
Ben, Tim, and I attend the CAB Forum and be the official reps. Dean is still
planning to help out with the governance and other groups. 

 

I'm also going to step down as chair of the validation working group.
Unfortunately, I don't have the time to give the group the loving affection
necessary for things to progress.  Tim has offered to sub for me until a new
chair is appointed. I'll still join the group and make snippy comments
though. 

 

Jeremy



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

Re: [cabfpub] Obtaining an EV cert for phishing

[Jeremy Rowley via Public]

I don’t think we should require a landline.  Too many places are deprecating 
them in favor of only mobile numbers (see Norway for example). 

 

I’m not sure the name should have raised alarm bells as it assumes the 
verification was done in the US or by English speaking natives.  Although this 
is true for the current scenario, all you’d need to do is translate it into 
Spanish or use a US name through a non-US based CA for the same effect.  I also 
don’t think there’s anything inherently wrong with the name.  Perhaps you are 
providing identity services for online dating or passport expedition. You could 
have a product that verifies the identity of each contact you are adding to an 
address book. There’s too many realistic use cases to consider this name 
inherently misleading. To improve, the emphasis would either need to be on post 
issuance mitigation of actual phishing or pre-issuance controls to ensure law 
enforcement can easily find and shut-down operations of a phishing entity. EV 
was originally built on the latter.

 

From: James Burton [mailto:ja...@sirburton.com] 
Sent: Monday, November 27, 2017 2:26 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>; CA/Browser Forum Public 
Discussion List <public@cabforum.org>
Subject: Re: [cabfpub] Obtaining an EV cert for phishing

 

Hi Jeremy,

 

The company "Identity Verified" was incorporated using a legitimate address. 
The company could have been incorporated using a service address bought online 
to assert its legitimacy as a real company for the application of the EV SSL 
and in turn would have same outcome. The company name in question should've 
started the alarm bells ringing long before the vetting process in my opinion 
as its really implausible.company name as its way too common. If it was me 
doing the vetting I would've been very sceptical of this company name and never 
issued the EV SSL certificate in the first place. 

 

The requirements specified in the EV guidelines for phone number verification 
are way too relaxed in my opinion as it shouldn't be possible to get a EV SSL 
without a proper landline telephone number. The phone number specified on this 
application was my mobile number and as you can pick up these sim cards for 
nothing from mobile providers its too easy to bypass these requirements. 

 

The idea of vetting each client face to face by video stream is the way forward 
in vetting the company individuals for EV SSL certificates. 

 

Thank you,

 

Regards,

 

James

 

On Mon, Nov 27, 2017 at 7:52 PM, Jeremy Rowley via Public <public@cabforum.org 
<mailto:public@cabforum.org> > wrote:

Hi Gerv,

I have information about this now. Sorry for the delay.

Basically, Symantec verified the organization using the UK companies house, 
which qualifies as a QGIS. Because it's a QGIS, the data source can be used to 
validate most of the requirements under the EV Guidelines, including address 
and legal existence.  The phone number was verified using QIIS and a call to 
the number, answered, of course, by the applicant. The result is James ended up 
forming a real company with fake address information. The failure was in the 
government process for vetting any kind of information before forming the 
company, which is a problem.  Speaking to other government entities, this is 
common and they usually catch these fake businesses on renewal (the business 
never receives the renewal notification because of the fake address/phone).  
Note that the issuance itself was fine - the entity really existed and was 
located at the address specified for all governmental intents and purposes.  
Increasing the number of data sources wouldn't have prevented issuance as many 
sources pull their info directly from the government resources. What do you do 
when the government fails?

To answer your specific questions:

11.4: Verification of Applicant’s Physical Existence. How was that done in this 
case, and what was the address which was verified?
- The address provided was verified with the UK Companies House.

11.6: Verification of Applicant’s Operational Existence. How was that done in 
this case? Which clause of 11.6.2 was used? What were the results?
- Operational existence was verified under (2) using a QIIS.  The QIIS 
specified the company existed at the address specified in the UK companies 
house.

One way I can think of to lock down issuance would be requiring a face to face 
validation (through video software) with each applicant if the company was 
formed within three years (operational existence).  The applicant would still 
get the cert if they were verified, but there would be a video record of the 
identity of the application, making law enforcement easier. Of course, the 
applicant could still use a fake ID, but obtaining the cert would be more risky 
because of the video recording. Plus, if the verifier determined the ID as 
fake, the applicant would be blacklisted from getting additio

Re: [cabfpub] Obtaining an EV cert for phishing

[Jeremy Rowley via Public]

Hi Gerv, 

I have information about this now. Sorry for the delay.

Basically, Symantec verified the organization using the UK companies house, 
which qualifies as a QGIS. Because it's a QGIS, the data source can be used to 
validate most of the requirements under the EV Guidelines, including address 
and legal existence.  The phone number was verified using QIIS and a call to 
the number, answered, of course, by the applicant. The result is James ended up 
forming a real company with fake address information. The failure was in the 
government process for vetting any kind of information before forming the 
company, which is a problem.  Speaking to other government entities, this is 
common and they usually catch these fake businesses on renewal (the business 
never receives the renewal notification because of the fake address/phone).  
Note that the issuance itself was fine - the entity really existed and was 
located at the address specified for all governmental intents and purposes.  
Increasing the number of data sources wouldn't have prevented issuance as many 
sources pull their info directly from the government resources. What do you do 
when the government fails?

To answer your specific questions:

11.4: Verification of Applicant’s Physical Existence. How was that done in this 
case, and what was the address which was verified?
- The address provided was verified with the UK Companies House.

11.6: Verification of Applicant’s Operational Existence. How was that done in 
this case? Which clause of 11.6.2 was used? What were the results?
- Operational existence was verified under (2) using a QIIS.  The QIIS 
specified the company existed at the address specified in the UK companies 
house. 

One way I can think of to lock down issuance would be requiring a face to face 
validation (through video software) with each applicant if the company was 
formed within three years (operational existence).  The applicant would still 
get the cert if they were verified, but there would be a video record of the 
identity of the application, making law enforcement easier. Of course, the 
applicant could still use a fake ID, but obtaining the cert would be more risky 
because of the video recording. Plus, if the verifier determined the ID as 
fake, the applicant would be blacklisted from getting additional cert and 
potentially reported to authorities.  Another idea are to require phishing 
checks (such as through Google's API) daily/weekly to determine if the website 
is a phishing website.  We  are still trying to get D to engage in a 
conversation about self-reported data, but with little success.

Jeremy


-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham 
via Public
Sent: Thursday, September 14, 2017 7:08 AM
To: CABFPub 
Subject: [cabfpub] Obtaining an EV cert for phishing

As noted in the Paypal/Let's Encrypt meeting yesterday, James Burton has 
published a blog post claiming that it's not difficult to get a fraudulent EV 
certificate:
https://0.me.uk/ev-phishing/

Now, they didn't actually get a fraudulent one, and it did take them a few days 
and a reasonable amount of manual work, but if we accept for the sake of 
argument their claim that valid stolen personal ID can be obtained online 
easily, it does seem that the other steps are not too onerous.

As someone noted at the meeting, fraudsters often don't pay for things with 
their own money. To my mind, the "cost" of EV is in the requirement to either 
reveal your true identity, or to spend prohibitive time on a successful effort 
to fool the checks.

I hope we can use this as a learning experience. Because a certificate was not 
misissued, there is no obligation on them to do so, but I hope that in the 
cause of making EV better, Symantec would be willing to discuss their EV 
verification steps and what happened in this case, so we can look and see if 
the EV process needs improving.

Some areas I'd particularly like to consider:

11.4: Verification of Applicant’s Physical Existence. How was that done in this 
case, and what was the address which was verified?

11.6: Verification of Applicant’s Operational Existence. How was that done in 
this case? Which clause of 11.6.2 was used? What were the results?

Gerv


___
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] BR 3.2.2.4.4 question

[Jeremy Rowley via Public]

Yes. Pretty sure we’re all saying the same thing at this point.

On Oct 12, 2017, at 4:02 PM, Moudrick M. Dadashov via Public 
<public@cabforum.org<mailto:public@cabforum.org>> wrote:

Yes.

As the keyword in Jeremy's question was "translation" to other languages  I 
thought those names (admin etc.) shouldn't be treated as English words.

Thanks,
M.D.

On 10/13/2017 12:49 AM, Ryan Sleevi wrote:
Yes, it indicates the name of a mailbox, but that doesn't resolve the issue (as 
I believe your intent was).

That is, put differently, some Applicants are saying that a translated address 
delivers to the same local mailbox as the required address. This is no 
different than an Applicant saying "sleevi@google" and "s.l.e.e.v.i@google" or 
"sleevi+cabf@google" deliver to the same local mailbox. Regardless of whether 
this is true or not, it's an Applicant-supplied piece of information, and the 
CA has to verify it. The only way that the CA can verify, as allowed under 
3.2.2.4.4, is to send to the required mailbox :)

On Thu, Oct 12, 2017 at 5:44 PM, Moudrick M. Dadashov 
<m...@ssc.lt<mailto:m...@ssc.lt>> wrote:
Hi Ryan,

My point was that the part before the @<https://en.wikipedia.org/wiki/@> symbol 
(local-part) identifies the name of a mailbox (it is not a word in any 
language, so it can't be translated). Correct?

Thanks,
M.D.


On 10/13/2017 12:27 AM, Ryan Sleevi wrote:
I'm not sure your point, Moudrick?

On Thu, Oct 12, 2017 at 5:14 PM, Moudrick M. Dadashov via Public 
<public@cabforum.org<mailto:public@cabforum.org>> wrote:
FYI:  An addr-spec is a specific Internet identifier that contains a locally 
interpreted string followed by the at-sign character ("@", ASCII value 64) 
followed by an Internet domain.

Thanks,
M.D.


On 10/13/2017 12:00 AM, Jeremy Rowley via Public wrote:
Section 3.2.2.4.4 states that CAs can validate an email by “(i) sending an 
email to one or more addresses created by using 'admin', 'administrator', 
'webmaster', 'hostmaster', or 'postmaster' as the local part, followed by the 
at‐ sign ("@"), followed by an Authorization Domain Name, (ii) including a 
Random Value in the email, and (iii) receiving a confirming response utilizing 
the Random Value”.

Recently, we’ve been getting requests to send the email to the Spanish word for 
administrator (“Administrador” according to Google translate – I don’t speak 
Spanish). I don’t think this is permitted because the BRs specifically state 
that the five key email words permitted.   Should translations of those words 
be allowed?

Jeremy



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



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





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

Re: [cabfpub] BR 3.2.2.4.4 question

[Jeremy Rowley via Public]

That was my thoughts as well, but I thought it might make a good discussion. I 
see them as keywords, not as words set in a particular language.

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Thursday, October 12, 2017 3:04 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>; CA/Browser Forum Public 
Discussion List <public@cabforum.org>
Subject: Re: [cabfpub] BR 3.2.2.4.4 question

 

 

 

On Thu, Oct 12, 2017 at 5:00 PM, Jeremy Rowley via Public <public@cabforum.org 
<mailto:public@cabforum.org> > wrote:

Section 3.2.2.4.4 states that CAs can validate an email by “(i) sending an 
email to one or more addresses created by using 'admin', 'administrator', 
'webmaster', 'hostmaster', or 'postmaster' as the local part, followed by the 
at‐ sign ("@"), followed by an Authorization Domain Name, (ii) including a 
Random Value in the email, and (iii) receiving a confirming response utilizing 
the Random Value”. 

 

Recently, we’ve been getting requests to send the email to the Spanish word for 
administrator (“Administrador” according to Google translate – I don’t speak 
Spanish). I don’t think this is permitted because the BRs specifically state 
that the five key email words permitted.   Should translations of those words 
be allowed?

 

Absolutely not :) 

 

These were allocated because they're either reserved (webmaster, hostmaster, 
postmaster) or because the CABF made them up based on past practices (admin, 
administrator). CAs absolutely should not be extending this list :)



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

[cabfpub] BR 3.2.2.4.4 question

[Jeremy Rowley via Public]

Section 3.2.2.4.4 states that CAs can validate an email by “(i) sending an
email to one or more addresses created by using 'admin', 'administrator',
'webmaster', 'hostmaster', or 'postmaster' as the local part, followed by
the at‐ sign ("@"), followed by an Authorization Domain Name, (ii)
including a Random Value in the email, and (iii) receiving a confirming
response utilizing the Random Value”.



Recently, we’ve been getting requests to send the email to the Spanish word
for administrator (“Administrador” according to Google translate - I don’
t speak Spanish). I don’t think this is permitted because the BRs
specifically state that the five key email words permitted.   Should
translations of those words be allowed?



Jeremy



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

Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

[Jeremy Rowley via Public]

I don’t understand why we are mixing creation of separate mailing list 
discussion for reporting BR violations with the revocation timeline change. The 
two aren’t closely related, at least, no more than any other BR violation and 
public disclosure requirement. Because certificate problem reporters are free 
to publish the problem report wherever they would like, I see a benefit in a 
publicly open list where people can post certificate problem reports and 
violations of policy to the CAB Forum.  I’d even support/endorse a separate 
ballot on creating a public mailing list where interested parties (or even 
non-interested parties) can discuss and report violations of the BRs and 
reasons for the violations. What I don’t understand is the tie to certificate 
revocation timelines ballot.

 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Wednesday, October 11, 2017 11:40 AM
To: Jeremy Rowley 
Cc: Dean Coclin ; CA/Browser Forum Public Discussion 
List ; Wayne Thayer ; Gervase Markham 

Subject: Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

 

Jeremy,

 

To be clear: The suggestion is to simply setup an additional mailing list for 
this.

 

Advantages:

- No vendor dependency (the Mozilla list is, of course, simply one root store 
member)

- An auditable criteria (whether or not a message was posted is something that 
can be quantified without an external dependency)

- Objective transparency without a vendor dependence

- Avoids requiring the high-volume subscription to the Mozilla list to 
understand the challenges there are with processing revocations in a timely 
fashion, so that the Forum can best review and update its expectations

 

Given that this is an exceptional process, it's one we can expect to be 
extremely low volume, but when there is volume, it will hopefully be of 
substantive quality.

 

The objections I've heard are:

- Objections to the notion of transparency itself

- Concerns about messages requiring moderation (not an issue for the questions@ 
list, AIUI, so one would similarly expect the same)

- Concerns about administrative overhead (Mailman supports self-service 
subscription - as evidenced by the public@ list - and allows public posting - 
as evidenced by the questions@ list)

- Concerns about spam (not an issue for the questions@ list, AIUI, so one would 
similarly expect the same)

- Concerns about vendor dependence (having this be a Forum list resolves this)

- Concerns about "The Forum" running a list ("The Forum" already runs several 
lists, as per our bylaws)

 

I am earnestly surprised by the degree of concern here, and am trying to make a 
good faith understanding of the concerns, which do not seem to be well-founded, 
but I may simply be misunderstanding the concerns.

 

On Wed, Oct 11, 2017 at 1:31 PM, Jeremy Rowley  > wrote:

I still don’t see the value of bastardizing the CAB Forum questions list to do 
something that the Mozilla mailing list already does perfectly.  Why use a 
brand new process when a good one already exists?  Unless, there’s a good 
reason for double transparency (Mozilla plus a new mailing list) I’d like to 
keep the ballot as already proposed if people are willing to endorse.

 

From: Public [mailto:public-boun...@cabforum.org 
 ] On Behalf Of Dean Coclin via Public
Sent: Wednesday, October 11, 2017 11:18 AM
To: Wayne Thayer  >; 
CA/Browser Forum Public Discussion List  >; Ryan Sleevi  >; Gervase Markham  >


Subject: Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

 

I’m currently responding to questions as best I can. We haven’t had much volume 
on that list though.


Dean

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Wayne Thayer via 
Public
Sent: Wednesday, October 11, 2017 1:16 PM
To: Ryan Sleevi  >; CA/Browser 
Forum Public Discussion List  
>; Gervase Markham  >
Subject: Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

 

>>I do not believe that's not been a concern of any Forum mailing list to date, 
>>because that's now how the Forum has operated its mailing lists.

 

This is precisely how the Forum operates its lists – questions@ in particular, 
but all the others as well. And while Eddy Nigg was the long-time questions@ 
list admin, there is currently no one who really owns the task of monitoring 
the questions list in a timely fashion (and I suspect that timely moderation is 
quite important for this new list that’s being proposed). I am 

Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

[Jeremy Rowley via Public]

I still don’t see the value of bastardizing the CAB Forum questions list to do 
something that the Mozilla mailing list already does perfectly.  Why use a 
brand new process when a good one already exists?  Unless, there’s a good 
reason for double transparency (Mozilla plus a new mailing list) I’d like to 
keep the ballot as already proposed if people are willing to endorse.

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Dean Coclin via 
Public
Sent: Wednesday, October 11, 2017 11:18 AM
To: Wayne Thayer ; CA/Browser Forum Public Discussion List 
; Ryan Sleevi ; Gervase Markham 

Subject: Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

 

I’m currently responding to questions as best I can. We haven’t had much volume 
on that list though.


Dean

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Wayne Thayer via 
Public
Sent: Wednesday, October 11, 2017 1:16 PM
To: Ryan Sleevi  >; CA/Browser 
Forum Public Discussion List  
>; Gervase Markham  >
Subject: Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

 

>>I do not believe that's not been a concern of any Forum mailing list to date, 
>>because that's now how the Forum has operated its mailing lists.

 

This is precisely how the Forum operates its lists – questions@ in particular, 
but all the others as well. And while Eddy Nigg was the long-time questions@ 
list admin, there is currently no one who really owns the task of monitoring 
the questions list in a timely fashion (and I suspect that timely moderation is 
quite important for this new list that’s being proposed). I am currently doing 
a lot of the moderation but am transitioning the work to Ben, which I believe 
supports the point that Gerv is making.

 

Thanks,

 

Wayne

 

From: Public  
> on behalf of Ryan Sleevi via Public  >
Reply-To: Ryan Sleevi  >, 
CA/Browser Forum Public Discussion List  >
Date: Wednesday, October 11, 2017 at 9:54 AM
To: Gervase Markham  >
Cc: CA/Browser Forum Public Discussion List  >
Subject: Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

 

 

 

On Wed, Oct 11, 2017 at 12:42 PM, Gervase Markham  > wrote:

On 11/10/17 17:39, Ryan Sleevi wrote:
> What do you believe requires looking after? Spam? Substance? Access?

Mailing lists don't manage themselves. Says someone who manages six and
has to clear the spam queues daily.

 

So your concern is a message being held for moderation and requiring manual 
review?

 

I do not believe that's not been a concern of any Forum mailing list to date, 
because that's now how the Forum has operated its mailing lists.

 

Would that address your concern? 



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

Re: [cabfpub] CAA working group description

[Jeremy Rowley via Public]

I know there’s a CAA document going through ACME. Is this also going LAMPS?  
The ACME WG is already working on account UIR and validation-methods 
parameters. Given that this represents two of the four parameters suggested 
during the F2F, should we add the other two there? 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jacob 
Hoffman-Andrews via Public
Sent: Thursday, October 5, 2017 12:52 PM
To: Phillip 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] CAA working group description

 

On Thu, Oct 5, 2017 at 11:09 AM, Phillip  > wrote:

What somewhat worries me is a situation in which I have ten CABForum members 
tell me that they really want X in a CABForum group and then I report that into 
the IETF WG and three people say they have other ideas and there being 3 of 
them and one of me, they represent the consensus.

 

I agree that this would be a bad outcome, and it's part of why we need to 
encourage interested CA/Browser Forum members to participate directly in IETF, 
so they can be heard as part of the consensus.



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

Re: [cabfpub] Short-lived certs

[Jeremy Rowley via Public]

Sure. Think of them as one time use certs. They aren't replacing them every 15 
min. They're just good for 15 min.

On Oct 6, 2017, at 5:49 AM, Tim Hollebeek 
<tholleb...@trustwave.com<mailto:tholleb...@trustwave.com>> wrote:

Are 15 minute certs a good idea in a CT world?

-Tim

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: Thursday, October 5, 2017 3:23 PM
To: Ryan Sleevi <sle...@google.com<mailto:sle...@google.com>>
Cc: CA/Browser Forum Public Discussion List 
<public@cabforum.org<mailto:public@cabforum.org>>
Subject: Re: [cabfpub] Short-lived certs

For a short-lived cert that is truly short-lived, you never deliver a 
meaningful response.  Of course, there’s always an initial “good” response for 
an initially issued cert, but that only tells me it was issued.  By the time I 
sign a new response, the cert is expired.

I’m not sure why people are requesting 15 min or 8 hour certs. We can do them, 
but then we need to sign an OCSP response as well. Requiring OCSP on these 
certs doesn’t mean that the certs don’t exist.

From: Ryan Sleevi [mailto:sle...@google.com]
Sent: Wednesday, October 4, 2017 11:58 PM
To: Jeremy Rowley 
<jeremy.row...@digicert.com<mailto:jeremy.row...@digicert.com>>
Cc: CA/Browser Forum Public Discussion List 
<public@cabforum.org<mailto:public@cabforum.org>>
Subject: Re: [cabfpub] Short-lived certs



On Wed, Oct 4, 2017 at 10:54 PM, Jeremy Rowley 
<jeremy.row...@digicert.com<mailto:jeremy.row...@digicert.com>> wrote:

Pre-signing OCSP responses for these certs is a waste of time as they’ll expire 
before the OCSP is ever delivered.

Delivered to who? Are you saying you deliver certificates before you've 
produced OSP responses?

  *   If we pre-sign an OCSP response for a 15 min cert, the OCSP is rarely 
used.

But that's different than what you said - you indicated that 15 minutes is 
because the OCSP is delivered, and I was trying to understand delivered to 
who/what?


  *
When you are signing certs daily, even signing that first OCSP response eats up 
lots of processing power without providing any benefit to the user.  Removing 
OCSP for short-lived certs eliminates an external call to the CA

Stapling

  *   These are usually on a home network. Getting an OCSP response to staple 
through the firewall usually doesn’t happen
Can you explain how you deliver a cert, but cannot deliver an OCSP response for 
said cert?

-  Clock skew is a problem. That is the assumption.  But 
that’s not really relevant to the OCSP issue right? That’s more an issue with 
certificate lifecycles. My contention is that OCSP provides little value in the 
context of a three day, or less, cert.
Well, your stated objective is to support lifetimes for as low as 15 minutes. 
If this objective is not reasonable - or is detrimental - then the need to not 
include revocation information no longer there, right? Or are there other 
reasons that weren't enumerated?
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Short-lived certs

[Jeremy Rowley via Public]

For a short-lived cert that is truly short-lived, you never deliver a 
meaningful response.  Of course, there’s always an initial “good” response for 
an initially issued cert, but that only tells me it was issued.  By the time I 
sign a new response, the cert is expired.

 

I’m not sure why people are requesting 15 min or 8 hour certs. We can do them, 
but then we need to sign an OCSP response as well. Requiring OCSP on these 
certs doesn’t mean that the certs don’t exist. 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Wednesday, October 4, 2017 11:58 PM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Short-lived certs

 

 

 

On Wed, Oct 4, 2017 at 10:54 PM, Jeremy Rowley  > wrote:


Pre-signing OCSP responses for these certs is a waste of time as they’ll expire 
before the OCSP is ever delivered. 

 

Delivered to who? Are you saying you deliver certificates before you've 
produced OSP responses?

*   If we pre-sign an OCSP response for a 15 min cert, the OCSP is rarely 
used.

 

But that's different than what you said - you indicated that 15 minutes is 
because the OCSP is delivered, and I was trying to understand delivered to 
who/what?

 

*

When you are signing certs daily, even signing that first OCSP response eats up 
lots of processing power without providing any benefit to the user.  Removing 
OCSP for short-lived certs eliminates an external call to the CA 

 

Stapling

*   These are usually on a home network. Getting an OCSP response to staple 
through the firewall usually doesn’t happen

Can you explain how you deliver a cert, but cannot deliver an OCSP response for 
said cert?

-  Clock skew is a problem. That is the assumption.  But 
that’s not really relevant to the OCSP issue right? That’s more an issue with 
certificate lifecycles. My contention is that OCSP provides little value in the 
context of a three day, or less, cert.

Well, your stated objective is to support lifetimes for as low as 15 minutes. 
If this objective is not reasonable - or is detrimental - then the need to not 
include revocation information no longer there, right? Or are there other 
reasons that weren't enumerated?



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

Re: [cabfpub] Short-lived certs

[Jeremy Rowley via Public]

Sorry – I was answering on my phone. Never a good idea. 

 

Pre-signing OCSP responses for these certs is a waste of time as they’ll expire 
before the OCSP is ever delivered. 

 

Delivered to who? Are you saying you deliver certificates before you've 
produced OSP responses?

*   If we pre-sign an OCSP response for a 15 min cert, the OCSP is rarely 
used.

When you are signing certs daily, even signing that first OCSP response eats up 
lots of processing power without providing any benefit to the user.  Removing 
OCSP for short-lived certs eliminates an external call to the CA 

 

Stapling

*   These are usually on a home network. Getting an OCSP response to staple 
through the firewall usually doesn’t happen

and makes the certificate smaller,   both essential in device performance.  
Plus, Mozilla already supports not checking revocation for these certs, meaning 
the revocation info is completely useless in at least one browser.  

 

Any takers on supporting this?

 

 

Do you have any new data to suggest clock skew isn't a significant issue, and 
that such certificates would represent compatibility problems for the ecosystem 
if deployed? Is the assumption that it's the sites and users' 
fault/responsibility, despite the overall ecosystem widespread use could cause?

 

-  Clock skew is a problem. That is the assumption.  But 
that’s not really relevant to the OCSP issue right? That’s more an issue with 
certificate lifecycles. My contention is that OCSP provides little value in the 
context of a three day, or less, cert.

 



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

Re: [cabfpub] Short-lived certs

[Jeremy Rowley via Public]

That wasn't quite accurate I realized. They aren't necessarily embedding the 
root but they are relying on browser access to the device, meaning each of 
these devices are essentially the same as servers, requiring public trust.

On Oct 5, 2017, at 1:44 PM, Jeremy Rowley via Public 
<public@cabforum.org<mailto:public@cabforum.org>> wrote:

Yes. Check out plex and our other mass issuance customers (I'm not sure I can 
provide names on a public list despite these being discoverable). These aren't 
short lived...yet.

On Oct 5, 2017, at 1:37 PM, Ryan Sleevi 
<sle...@google.com<mailto:sle...@google.com>> wrote:

Jeremy,

Could you supply data to support your claim that "internet connected devices 
increasingly use trusted roots for connecting to smartphones"?

On Wed, Oct 4, 2017 at 8:21 PM, Jeremy Rowley via Public 
<public@cabforum.org<mailto:public@cabforum.org>> wrote:
Pre-signing OCSP responses for these certs is a waste of time as they’ll expire 
before the OCSP is ever delivered.

Delivered to who? Are you saying you deliver certificates before you've 
produced OSP responses?

When you are signing certs daily, even signing that first OCSP response eats up 
lots of processing power without providing any benefit to the user.  Removing 
OCSP for short-lived certs eliminates an external call to the CA

Stapling

and makes the certificate smaller,   both essential in device performance.  
Plus, Mozilla already supports not checking revocation for these certs, meaning 
the revocation info is completely useless in at least one browser.

Any takers on supporting this?


Do you have any new data to suggest clock skew isn't a significant issue, and 
that such certificates would represent compatibility problems for the ecosystem 
if deployed? Is the assumption that it's the sites and users' 
fault/responsibility, despite the overall ecosystem widespread use could cause?
___
Public mailing list
Public@cabforum.org<mailto:Public@cabforum.org>
https://cabforum.org/mailman/listinfo/public
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Short-lived certs

[Jeremy Rowley via Public]

Yes. Check out plex and our other mass issuance customers (I'm not sure I can 
provide names on a public list despite these being discoverable). These aren't 
short lived...yet.

On Oct 5, 2017, at 1:37 PM, Ryan Sleevi 
<sle...@google.com<mailto:sle...@google.com>> wrote:

Jeremy,

Could you supply data to support your claim that "internet connected devices 
increasingly use trusted roots for connecting to smartphones"?

On Wed, Oct 4, 2017 at 8:21 PM, Jeremy Rowley via Public 
<public@cabforum.org<mailto:public@cabforum.org>> wrote:
Pre-signing OCSP responses for these certs is a waste of time as they’ll expire 
before the OCSP is ever delivered.

Delivered to who? Are you saying you deliver certificates before you've 
produced OSP responses?

When you are signing certs daily, even signing that first OCSP response eats up 
lots of processing power without providing any benefit to the user.  Removing 
OCSP for short-lived certs eliminates an external call to the CA

Stapling

and makes the certificate smaller,   both essential in device performance.  
Plus, Mozilla already supports not checking revocation for these certs, meaning 
the revocation info is completely useless in at least one browser.

Any takers on supporting this?


Do you have any new data to suggest clock skew isn't a significant issue, and 
that such certificates would represent compatibility problems for the ecosystem 
if deployed? Is the assumption that it's the sites and users' 
fault/responsibility, despite the overall ecosystem widespread use could cause?
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] Short-lived certs

[Jeremy Rowley via Public]

I'd like to revisit short-lived certificates and see if there is an interest
in adopting the previous proposal to permit removal of OCSP information from
certificates with a 3 day or shorter validation period. I think there's been
enough change over the past few years to warrant a fresh look. In
particular, internet connected devices increasingly use trusted roots for
connecting to smart phones.  Some of these have certificate validity periods
as short as 15 minutes.  Pre-signing OCSP responses for these certs is a
waste of time as they'll expire before the OCSP is ever delivered. When you
are signing certs daily, even signing that first OCSP response eats up lots
of processing power without providing any benefit to the user.  Removing
OCSP for short-lived certs eliminates an external call to the CA and makes
the certificate smaller,   both essential in device performance.  Plus,
Mozilla already supports not checking revocation for these certs, meaning
the revocation info is completely useless in at least one browser.  

 

Any takers on supporting this?

 

Jeremy

 

 



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

[cabfpub] Ballot 184 - SRVnames

[Jeremy Rowley via Public]

Probably time to finish this ballot off.  This is the last version I have,
slightly modified to remove the 822 and other language.  Thoughts?

Ballot 184 - SRVNames

Amend Section 7.1.4.2.1 as follows:

7.1.4.2.1. Subject Alternative Name Extension

Certificate Field: extensions:subjectAltName

Required/Optional: Required

Contents: This extension MUST contain at least one entry where each included
entry is one of the following:



7.1.4.2.1.1. dNSName

The subjectAltName extension MAY include one or more dNSName entries
provided each entry is either a Fully‐Qualified Domain Name or a Wildcard
Domain Name. The CA MUST confirm the Applicant’s ownership or control over
each Fully-Qualified Domain Name and Wildcard Domain Name entry in
accordance with Section 3.2.2.4. Except where the entry is an Internal Name
with onion as the right‐most label in an entry in the subjectAltName
Extension or commonName field in accordance with Appendix F of the EV
Guidelines, CAs MUST NOT include an Internal Name in a dNSName entry.



7.1.4.2.1.2. iPAddress

The subjectAltName MAY include one or more iPAddress entries provided the CA
has confirmed the Applicant’s ownership or control over each IP address
entry in accordance with Section 3.2.2.5. CAs MUST NOT include any entry
that is a Reserved IP Address.



7.1.4.2.1.4. otherName with SRVName { 1.3.6.1.5.5.7.0.18.8.7 } type-id

The subjectAltName MAY include one or more SRVNames (as defined in RFC4986)
as an otherName entry with the SRVName type-id. The CA MUST verify the name
portion of the entry in accordance with Section 3.2.2.4.  A CA MUST NOT
include a Wildcard Domain Name in any SRVName entry. If a Technically
Constrained Subordinate CA Certificate includes a dNSName constraint but
does not have a technical constraint for SRVNames, the CA MUST NOT issue
certificates containing SRVNames from the Technically Constrained
Subordinate CA Certificate. The CA MUST include permitted name subtrees and
MAY include excluded name subtrees in all Technically Constrained
Subordinate CA Certificate that includes a technical constraint for
SRVNames.





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

Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

[Jeremy Rowley via Public]

I understand what you are saying, but revocation timelines seems like a 
different topic than challenges facing the space.  There should be a mailing 
list for challenges, but I don’t think it should be tied to changing the 
revocation timelines already in the BRs.

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Wednesday, September 13, 2017 1:18 PM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

 

 

 

On Wed, Sep 13, 2017 at 3:10 PM, Jeremy Rowley  > wrote:

Sure, but I plan on uploading all these to the Mozilla dev list.  Emailing the 
CAB Forum as well seems like duplicative effort, especially since the emails 
aren’t going to be readily collaborated.  If the CABForum is going to collect 
the problem reports, some format other than email would be much better for data 
collection.

 

I'm not sure I understand your point about collaborated, but I think you may be 
misunderstanding the goal.

 

I appreciate the desire for transparency and engagement with the community, and 
I hope all CAs aspire to that level. However, I think the goal here is 
minimally to ensure public visibility, in a self-managed form (that is, I have 
difficulty imagining the CABF requiring an MDSP posting). I think going above 
and beyond is good, but i think we should set minimum reasonable requirements.

 

As I noted, I'm not wedded to the idea of public@, but I think there should be 
a CABF-managed, publicly-visible list for discussion about the challenges here 
in this space :) 

 



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

Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

[Jeremy Rowley via Public]

Sure, but I plan on uploading all these to the Mozilla dev list.  Emailing the 
CAB Forum as well seems like duplicative effort, especially since the emails 
aren’t going to be readily collaborated.  If the CABForum is going to collect 
the problem reports, some format other than email would be much better for data 
collection.

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Wednesday, September 13, 2017 1:04 PM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

 

 

 

On Wed, Sep 13, 2017 at 2:52 PM, Jeremy Rowley  > wrote:

I agree with the goal of getting this information out there, and using the CAB 
Forum this way seems in scope. Per the bylaws: “Members of the CA/Browser Forum 
have worked closely together in defining the guidelines and means of 
implementation for best practices as a way of providing a heightened security 
for Internet transactions and creating a more intuitive method of displaying 
secure sites to Internet users.” (Section 1)

 

However, I’m struggling to see why the CAB Forum would want to collect this 
info as a requirement rather than allowing CAs to submit the information 
voluntarily when there are questions.  Usually, we require the location of the 
disclosure be set in the CPS/CP, not as an email to the CAB Forum.  Shouldn’t 
we follow that format here?

 

Because this is an industry problem - and it's one that is either facilitated 
by or stymied by the collective Baseline Requirements and Root Program 
Requirements.

 

Our goals in Internet Security should be to establish a consistent baseline in 
the application of policies and practices. While we can disclose those in 
CP/CPS, that doesn't do anything to align consistency or promote information 
sharing. What we're discussing about is sharing information related to the 
challenges of adhering to the minimum required policies and practices, so we 
can improve both.

 



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

Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

[Jeremy Rowley via Public]

I agree with the goal of getting this information out there, and using the CAB 
Forum this way seems in scope. Per the bylaws: “Members of the CA/Browser Forum 
have worked closely together in defining the guidelines and means of 
implementation for best practices as a way of providing a heightened security 
for Internet transactions and creating a more intuitive method of displaying 
secure sites to Internet users.” (Section 1)

 

However, I’m struggling to see why the CAB Forum would want to collect this 
info as a requirement rather than allowing CAs to submit the information 
voluntarily when there are questions.  Usually, we require the location of the 
disclosure be set in the CPS/CP, not as an email to the CAB Forum.  Shouldn’t 
we follow that format here? 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Wednesday, September 13, 2017 12:28 PM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

 

 

 

On Wed, Sep 13, 2017 at 2:14 PM, Jeremy Rowley  > wrote:

If we’re trying to require transparency, I’d rather see a requirement to 
publish all certificate problem reports within 24 hours, regardless of 
resolution. First, this accomplishes the goal in a more straight-forward 
manner. Second, publication separates the transparency goal from the resolution 
timeline frames. 

 

24 hours to publish

24-7 days to investigate/fix

24-7 days to revoke

 

The other question is where should these be published.  The CAB Forum questions 
list seems like the wrong place. The CAB Forum isn’t the mis-issuance police 
(the browsers are).  The questions list in particular is intended for third 
party questions about the CAB Forum requirements. The Mozilla dev list is a 
better place to publish. If that’s the case, wouldn’t a publication of 
certificate problem reports be better presented as a Mozilla root store 
requirement?

 

I think that's conflating publication with response, and I think it presupposes 
that response only originates from the root program side.

 

Note I didn't suggest the goal of transparency was to facilitate the 
misissuance police - it was to promote information sharing and disclosure to 
allow improved policies, practices, and guidelines. And that very much seems a 
CA/B Forum activity. Whether or not there is (separately) a conversation about 
misissuance does seem like something for policy enforcement and not necessarily 
the remit of the CA/B Forum.



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

Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

[Jeremy Rowley via Public]

If we’re trying to require transparency, I’d rather see a requirement to 
publish all certificate problem reports within 24 hours, regardless of 
resolution. First, this accomplishes the goal in a more straight-forward 
manner. Second, publication separates the transparency goal from the resolution 
timeline frames. 

 

24 hours to publish

24-7 days to investigate/fix

24-7 days to revoke

 

The other question is where should these be published.  The CAB Forum questions 
list seems like the wrong place. The CAB Forum isn’t the mis-issuance police 
(the browsers are).  The questions list in particular is intended for third 
party questions about the CAB Forum requirements. The Mozilla dev list is a 
better place to publish. If that’s the case, wouldn’t a publication of 
certificate problem reports be better presented as a Mozilla root store 
requirement? 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Wednesday, September 13, 2017 12:07 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: CA/Browser Forum Public Discussion List <public@cabforum.org>
Subject: Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

 

 

 

On Wed, Sep 13, 2017 at 1:50 PM, Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> > wrote:

Not that a QIIS is slow to provide information but the QIIS may be slow to  
update. For example, one QIIS may say the address is A. A second may state the 
address as B. Resolving the different information takes time. Is there much 
interest from the CAB forum perspective on this issues? 

 

I think there is and should be. For example, if we have QIIS's with different 
information, then it matters to those who rely on CAs to provide accurate 
information to understand what the QIISes are that a CA uses.

 

Understanding how (different) CAs address this problem - and whether these 
solutions provide the expected level of assurance - is useful.

 

Requiring reporting on this issues has the added disadvantage that it 
encourages a quick resolution (a determination that the address remained 
unchanged) rather than a thorough investigation about the changed info.

 

I'm not sure I agree with that. If anything, if a CA provides a quick 
resolution ("QIIS A states that the Address is A"), then it provides sufficient 
detail to allow the reporter to demonstrate that ("QIIS B states that the 
Address is B").

 

I think we should continue to err on the side of transparency in both policy 
and remediation, so that we can ensure there is a sufficient level of 
consistency amongst CAs, and that there is sufficient clarity as to what the 
expectations are.

 

 


On Sep 13, 2017, at 10:44 AM, Ryan Sleevi <sle...@google.com 
<mailto:sle...@google.com> > wrote:

 

 

On Wed, Sep 13, 2017 at 1:24 PM, Jeremy Rowley via Public <public@cabforum.org 
<mailto:public@cabforum.org> > wrote:

A 24 hour report to the CAB Forum doesn’t make sense if the length of the 
investigation is not tied to the understanding/interpretation of the CAB Forum 
requirement.  For example, if someone alleges a company changed addresses, 
revocation may be required under “information appearing in the Certificate is 
inaccurate or misleading”.  Information in the QIIS might not be updated, the 
contact person may be on vacation, etc.  This isn’t a CAB Forum issue so 
there’s no reason to report that it’s taking longer than 24 hours to complete 
the certificate problem report.  

 

What should be required, imo, is a report to the entity submitting the 
certificate problem report about why it’s taken longer than the required 24 
hours.  For investigation, what if we did:

*   24 hours required for the initial report
*   24 hours for the final report if the problem alleges X, Y, or Z
*   7 days for the final report for all other reasons.

 

Anything taking longer than 24 hours because of an issue with the CAB Forum 
requirements, must be reported to the CAB Forum.

 

Then revocation stays at:

*   24 hours required for X, Y, and Z
*   24 hours SHOULD for all other reasons
*   7 days required for all other reasons

 

Will this work?

 

 

I'm not sure I agree with that. That is, if someone is having trouble looking 
up information in a QIIS, then I think there is an expectation that CAs should 
be able to have process and controls to be able to confirm that information in 
a timely fashion. If, for example, the QIIS is particularly slow, then having a 
public discussion allows for opportunities to share information, such as 
whether CAs are using another QIIS to address this gap, or whether automated 
solutions exist, or whether an opportunity exists to feed that back to a QIIS.

 

I'm suggesting that, as an industry, we benefit most from information sharing, 
particularly around the challenges faced to ensure users are kept secure.

 

The ontology of whether or not it's a CA/B Forum issue is probl

Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

[Jeremy Rowley via Public]

Not that a QIIS is slow to provide information but the QIIS may be slow to  
update. For example, one QIIS may say the address is A. A second may state the 
address as B. Resolving the different information takes time. Is there much 
interest from the CAB forum perspective on this issues?

Requiring reporting on this issues has the added disadvantage that it 
encourages a quick resolution (a determination that the address remained 
unchanged) rather than a thorough investigation about the changed info.

On Sep 13, 2017, at 10:44 AM, Ryan Sleevi 
<sle...@google.com<mailto:sle...@google.com>> wrote:



On Wed, Sep 13, 2017 at 1:24 PM, Jeremy Rowley via Public 
<public@cabforum.org<mailto:public@cabforum.org>> wrote:
A 24 hour report to the CAB Forum doesn’t make sense if the length of the 
investigation is not tied to the understanding/interpretation of the CAB Forum 
requirement.  For example, if someone alleges a company changed addresses, 
revocation may be required under “information appearing in the Certificate is 
inaccurate or misleading”.  Information in the QIIS might not be updated, the 
contact person may be on vacation, etc.  This isn’t a CAB Forum issue so 
there’s no reason to report that it’s taking longer than 24 hours to complete 
the certificate problem report.

What should be required, imo, is a report to the entity submitting the 
certificate problem report about why it’s taken longer than the required 24 
hours.  For investigation, what if we did:

  *   24 hours required for the initial report
  *   24 hours for the final report if the problem alleges X, Y, or Z
  *   7 days for the final report for all other reasons.

Anything taking longer than 24 hours because of an issue with the CAB Forum 
requirements, must be reported to the CAB Forum.

Then revocation stays at:

  *   24 hours required for X, Y, and Z
  *   24 hours SHOULD for all other reasons
  *   7 days required for all other reasons

Will this work?


I'm not sure I agree with that. That is, if someone is having trouble looking 
up information in a QIIS, then I think there is an expectation that CAs should 
be able to have process and controls to be able to confirm that information in 
a timely fashion. If, for example, the QIIS is particularly slow, then having a 
public discussion allows for opportunities to share information, such as 
whether CAs are using another QIIS to address this gap, or whether automated 
solutions exist, or whether an opportunity exists to feed that back to a QIIS.

I'm suggesting that, as an industry, we benefit most from information sharing, 
particularly around the challenges faced to ensure users are kept secure.

The ontology of whether or not it's a CA/B Forum issue is problematic, because 
one CA may argue it's a CABForum problem can easily vary between two CAs with 
the same problem. One may view it as a Forum problem that our definition of 
QIIS precludes certain automated sources (which might allow for a more rapid 
response), while another may view it as an external problem.

Similarly, if CAs are routinely getting 'bad' problem reports, having 
transparency about that allows the CA/Browser Forum to respond, as an industry, 
on potential solutions for that.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

[Jeremy Rowley via Public]

A 24 hour report to the CAB Forum doesn’t make sense if the length of the 
investigation is not tied to the understanding/interpretation of the CAB Forum 
requirement.  For example, if someone alleges a company changed addresses, 
revocation may be required under “information appearing in the Certificate is 
inaccurate or misleading”.  Information in the QIIS might not be updated, the 
contact person may be on vacation, etc.  This isn’t a CAB Forum issue so 
there’s no reason to report that it’s taking longer than 24 hours to complete 
the certificate problem report.  

 

What should be required, imo, is a report to the entity submitting the 
certificate problem report about why it’s taken longer than the required 24 
hours.  For investigation, what if we did:

*   24 hours required for the initial report
*   24 hours for the final report if the problem alleges X, Y, or Z
*   7 days for the final report for all other reasons.

 

Anything taking longer than 24 hours because of an issue with the CAB Forum 
requirements, must be reported to the CAB Forum.

 

Then revocation stays at:

*   24 hours required for X, Y, and Z
*   24 hours SHOULD for all other reasons
*   7 days required for all other reasons

 

Will this work? 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Monday, September 4, 2017 8:14 AM
To: Gervase Markham 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Ballot 213 - Revocation Timeline Extension

 

 

 

On Mon, Sep 4, 2017 at 5:27 AM, Gervase Markham  > wrote:

On 01/09/17 18:58, Ryan Sleevi wrote:
> It's primarily about ensuring transparency in a way that's consistent -
> and the Forum is relevant because it feeds into our determination about
> ways to clarify text, while also providing a useful reference for
> auditors and CAs regarding root stores' interpretations (and ensuring
> there's no misalignment). I suggested questions@, because it's our only
> list that doesn't require any form of agreement or participation in the
> Forum at large - thus ensuring it's appropriate for all members. 

(This is not the first time we've encountered that issue; do we need a
better-named "notificati...@cabforum.org  " 
email list?)

I see what you are trying to do; perhaps it's the phrasing which is
bugging me. Does this wording do the same thing that you are aiming for,
or has it changed the meaning?

"If any interpretation of these Requirements means that a CA believes it
may permit, and does permit, more than seven days to elapse between
receiving a Certificate Problem Report and providing a final
determination, the CA SHALL notify the CA/Browser Forum of their
interpretation by emailing questi...@cabforum.org 
 ."

 

Thanks for highlighting this. I actually think Jeremy and I may have crossed 
wires. My intent was to set the following limits for determination:

- 24 hours under situations X, Y, Z

- 24 hours SHOULD for everything else

- 7 days MUST for everything else

 

With a "Anything > 24 hours requires a report"

 

That covers assessment

 

And then the actual revocation works as

- 24 hours under situations X, Y, Z

- 7 days MUST for everything else

 

With no report as to the timing of that revocation.

 

 

But again, while I see what you are trying to do, how to we avoid the
BRs filling up with text like:

A) Do X.
B) If any CA feels these Requirements can be interpreted to mean that
they don't have to do X, they should email questi...@cabforum.org 
 .
C) Do Y.
D) If any CA feels these Requirements can be interpreted to mean that
they don't have to do X, they should email questi...@cabforum.org 
 .
...

Why is there a unique need in this particular case for notification of
interpretive "creativity"?

 

I'm not sure I would go as far as to suggest it's interpretative "creativity" - 
I think we're discussing cases of ambiguity which may take time to resolve 
(e.g. the CA consulting with their auditors and/or the Forum), or for which 
systemic issues might exist. I think we're appreciative of the need to 
coordinate with subscribers and perhaps take additional steps (although it does 
mean that the effectiveness of revocation for is now 7d+7d+7d days rather than 
the current 24h+24h+7d), but I think we'd want to understand why any 
investigation _isn't_ cut and dry.

 

For example, if an OCSP Responder is reported as responding GOOD to non-issued 
certificates, that should be something the CA can investigate and report on 
within 24 hours. If the CA can't, that's concerning.

 

As to notification, I think any place we offer for purely CA discretion, we 
need transparency. So to the extent we allow for situations like "You should do 
X, unless you think you don't have to" - then 

Re: [cabfpub] CAA checking: anecdotal reports?

[Jeremy Rowley via Public]

Here's some more data.  Attached is a complete list of all CAA records where 
we've rejected issuance. I think most of these are tests being run to verify 
DigiCert's CAA record checking (either CAAtestsuite or the Bear one). We have 
issued for cacerts.digicert.com as a domain, but we permit *.digicert.com 
right now as a valid CAA setting.  I think we also saw and permitted 
caa.digicert.com but that was before the 8th.

-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: Monday, September 11, 2017 6:57 PM
To: Paul Hoffman <paul.hoff...@icann.org>; CA/Browser Forum Public Discussion 
List <public@cabforum.org>
Subject: Re: [cabfpub] CAA checking: anecdotal reports?

Some initial thoughts:

Attached is an image of what we're seeing on CAA record check times since it 
was fully implemented as a pre-issuance check back on the 5th.  Average delay 
caused by CAA checking is about 180 ms.

We have rejected 48 FQDNS because of CAA since Thursday, many of these are 
caatestsuite.com names.  Since Thursday, we've rejected between 3-17 domains a 
day based on CAA records. Again, each caatestsuite site is counted separately.

Jeremy


-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Paul Hoffman 
via Public
Sent: Sunday, September 10, 2017 9:19 AM
To: CA/Browser Forum Public Discussion List <public@cabforum.org>
Subject: [cabfpub] CAA checking: anecdotal reports?

Greetings. I'm interested in how CAA is working out for both the names and CA 
communities.

Is someone collecting anecdotal reports of certificate non-issuance due to CAA 
checking? I kind of imagine they fall into at least two buckets: "I really do 
own the name but don't know how that wrong CAA record got there" and "As a CA, 
we have seen X blocked attempts to use us to try to get certs that had CAA 
records from other vendors". I guess I'm also interested in "About X% of our 
renewals are names that have us correctly listed in a CAA record".

--Paul Hoffman
___
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] CAA checking: anecdotal reports?

[Jeremy Rowley via Public]

Some initial thoughts:

Attached is an image of what we're seeing on CAA record check times since it 
was fully implemented as a pre-issuance check back on the 5th.  Average delay 
caused by CAA checking is about 180 ms.

We have rejected 48 FQDNS because of CAA since Thursday, many of these are 
caatestsuite.com names.  Since Thursday, we've rejected between 3-17 domains a 
day based on CAA records. Again, each caatestsuite site is counted separately.

Jeremy


-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Paul Hoffman 
via Public
Sent: Sunday, September 10, 2017 9:19 AM
To: CA/Browser Forum Public Discussion List 
Subject: [cabfpub] CAA checking: anecdotal reports?

Greetings. I'm interested in how CAA is working out for both the names and CA 
communities.

Is someone collecting anecdotal reports of certificate non-issuance due to CAA 
checking? I kind of imagine they fall into at least two buckets: "I really do 
own the name but don't know how that wrong CAA record got there" and "As a CA, 
we have seen X blocked attempts to use us to try to get certs that had CAA 
records from other vendors". I guess I'm also interested in "About X% of our 
renewals are names that have us correctly listed in a CAA record".

--Paul Hoffman
___
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

[cabfpub] Ballot 213 - Revocation Timeline Extension

[Jeremy Rowley via Public]

A revised version is attached. Additional comments and/or endorsements are 
welcome! 

 

Ballot 213 – Revocation Timeline Extension

 

Purpose: This ballot extends the revocation requirements in certain 
circumstances from 24 hours to seven days. The following motion is proposed by 
Jeremy Rowley of DigiCert and endorsed by XXX and XXX:

 

--MOTION BEGINS—

 

A.  Amend Section 4.9.1.1 as follows

 

The CA –(SHALL)-- __MUST__ revoke a Certificate within 24 hours if:

 

1.   The Subscriber requests in writing that the CA revoke the Certificate;

2.   The Subscriber notifies the CA that the original certificate 
request was not authorized and does not retroactively grant authorization;

3.  The CA obtains evidence that the Subscriber’s Private Key corresponding 
to the Public Key in the Certificate suffered a Key Compromise –(or)--; 

 

__The CA SHOULD revoke the certificate within 24 hours and MUST revoke a 
Certificate within seven days__ if one or more of the following occurs:

 

__1.  The Certificate__ no longer complies with the requirements of Sections 
6.1.5 and 6.1.6;

__2. __  --(4)--The CA obtains evidence that the Certificate was misused;

__3. __ --(5)--The CA is made aware that a Subscriber has violated one or more 
of its material obligations under the Subscriber Agreement or Terms of Use;

__4. __ --(6)--The CA is made aware of any circumstance indicating that use of 
a Fully-Qualified Domain Name or IP address in the Certificate is no longer 
legally permitted (e.g. a court or arbitrator has revoked a Domain Name 
Registrant’s right to use the Domain Name, a relevant licensing or services 
agreement between the Domain Name Registrant and the Applicant has terminated, 
or the Domain Name Registrant has failed to renew the Domain Name);

__5. __ --(7)--The CA is made aware that a Wildcard Certificate has been used 
to authenticate a fraudulently misleading subordinate Fully-Qualified Domain 
Name;

__6. __ --(8)--The CA is made aware of a material change in the information 
contained in the Certificate;

__7. __  --(9)--The CA is made aware that the Certificate was not issued in 
accordance with these Requirements or the CA’s Certificate Policy or 
Certification Practice Statement;

__8. __ --(10)--The CA determines that any of the information appearing in the 
Certificate is inaccurate or misleading;

__9. __ --(11)--The CA ceases operations for any reason and has not made 
arrangements for another CA to provide revocation support for the Certificate;

__10. __ --(12)--The CA’s right to issue Certificates under these Requirements 
expires or is revoked or terminated, unless the CA has made arrangements to 
continue maintaining the CRL/OCSP Repository;

__11. __ --(13)--The CA is made aware of a possible compromise of the Private 
Key of the Subordinate CA used for issuing the Certificate;

__12. __ --(14)--Revocation is required by the CA’s Certificate Policy and/or 
Certification Practice Statement; or

__13. __ --(15)--The technical content or format of the Certificate presents an 
unacceptable risk to Application Software Suppliers or Relying Parties (e.g. 
the CA/Browser Forum might determine that a deprecated cryptographic/signature 
algorithm or key size presents an unacceptable risk and that such Certificates 
should be revoked and replaced by CAs within a given period of time).

 

B.  Amend Section 4.9.3 as follows:


The CA SHALL provide a process for Subscribers to request revocation of their 
own Certificates. The process MUST be described in the CA’s Certificate Policy 
or Certification Practice Statement. The CA SHALL maintain a continuous 24x7 
ability to accept and respond to revocation requests and –(related inquiries)-- 
__Certificate Problem Reports__. 


The CA SHALL –(provide)-- __publicly disclose an email address through its 
online repository that __Subscribers, Relying Parties, Application Software 
Suppliers, and other third parties __may use to submit Certificate Problem 
Reports. The CA SHALL monitor this email address 24x7. A Certificate Problem 
Report is considered received by the CA when sent to the specified email 
address.__ ---(with clear instructions for reporting suspected Private Key 
Compromise, Certificate misuse, or other types of fraud, compromise, misuse, 
inappropriate conduct, or any other matter related to Certificates. The CA 
SHALL publicly disclose the instructions through a readily accessible online 
means.)—


C)   Amend Section 4.9.5 as follows:


4.9.5  Time within which CA Must Process the Revocation Request


__Within 24 hours after receiving a Certificate Problem Report, the CA SHALL 
investigate the facts and circumstances related to a Certificate Problem Report 
and provide a preliminary report on its findings to both the Subscriber and the 
entity who filed the Certificate Problem Report.  The CA SHALL provide a final 
determination on the Certificate Problem Report within the earliest of the 
following 

Re: [cabfpub] CAA Test Suite

[Jeremy Rowley via Public]

This is awesome! Thanks Andrew!

> On Aug 31, 2017, at 10:46 AM, Andrew Ayer via Public  
> wrote:
> 
> To help with the correct implementation of CAA, I've put together a CAA
> test suite:
> 
>https://caatestsuite.com/
> 
> It consists of a list of FQDNs for which no CA is allowed to issue.
> In addition to testing the basic CAA processing rules described in RFC
> 6844, it also tests for proper handling of edge cases and DNSSEC
> failures.
> 
> I encourage all CAs to test their CAA implementation against the FQDNs
> in the test suite.  If your implementation says you're allowed to issue
> for any of the FQDNs, then there may be a bug in your CAA
> implementation.
> 
> Let me know if you have any issues or questions.
> 
> Regards,
> Andrew
> ___
> 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] Revocation ballot v2

[Jeremy Rowley via Public]

Yeah – pretty much, except the part about the CAB Forum. If emailing the CAB 
Forum is required, I think the CA MUST provide a link to the entity submitting 
the Certificate Problem Report with the discussion.

 

Any additional comments before I finalize and ask for endoresers? 

 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Tuesday, August 29, 2017 3:18 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: CA/Browser Forum Public Discussion List <public@cabforum.org>; Gervase 
Markham <g...@mozilla.org>
Subject: Re: [cabfpub] Revocation ballot v2

 

I'm not sure if you were trying to say the same thing or propose a different 
thing :)

 

That is, I was suggesting the normal flow be:

 

The CA MUST make a final determination and respond to a Problem Report within 
24 hours, unless all of the following conditions are satisfied:

  - The Report does not indicate that the private key was compromised or 
publicly disclosed

  - The Report was not provided by the Subscriber

  - The CA makes a final determination and response available within 7 days of 
receipt of the Problem Report

  - The CA notifies the CA/Browser Forum via the questi...@cabforum.org 
<mailto:questi...@cabforum.org>  (as it's the only list that doesn't implicitly 
impose a membership requirement; although we can certainly explore other ways) 
of the Problem Report and why more than 24 hours was needed to investigate 
within 7 days of receipt of the Problem Report

 

The CA MUST revoke the certificate within 24 hours if:

  - The subscriber requests ...

  - The subscriber notifies ...

  - The CA obtains evidence that the Private Key ...

 

The CA SHOULD revoke the certificate within 24 hours and MUST revoke the 
certificate within 7 days if:

  - ...

 

Is that aligned with what you were saying? (I probably structured it poorly, 
but there's the handwavy approach)

 

 

On Mon, Aug 28, 2017 at 3:38 PM, Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> > wrote:

Not hearing from any other CAs, should we state that the CA must make an 
initial determination and report within 24 hours and a final report in 
accordance with the other timeline? 

 

From: Ryan Sleevi [mailto:sle...@google.com <mailto:sle...@google.com> ] 
Sent: Thursday, August 24, 2017 9:18 AM
To: Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> >; CA/Browser Forum Public Discussion List 
<public@cabforum.org <mailto:public@cabforum.org> >
Cc: Gervase Markham <g...@mozilla.org <mailto:g...@mozilla.org> >
Subject: Re: [cabfpub] Revocation ballot v2

 

 

 

On Wed, Aug 23, 2017 at 11:32 PM, Jeremy Rowley via Public <public@cabforum.org 
<mailto:public@cabforum.org> > wrote:

Okay - attached.

a) I added the requirement to maintain an email address for addressing 
certificate problem reports to 4.9.3
b) I added a 24 hour rule for when the original certificate request was not 
authorized.

 

Jeremy,

 

I'm wondering if you could speak more to what sort of challenges CAs face in 
making a determination within 24 hours, versus seven days. 

 

For example, consider a report of a CP/CPS non-compliance - which is something 
entirely under the CA's control - particularly for something like a profile 
violation (e.g. extensions when they said they wouldn't have them, missing 
subject naming fields, wrong policies, etc). Why wouldn't a CA be able to make 
a determination about compliance within 24 hours? One downside is I could see 
the added time for investigation adding an incentive to delay investigating (in 
order to delay revocation), rather than purely granting the flexibility 
necessary for complex situations.

 

I think if you (or others) could share a bit more about the challenges of 
investigating reports, since I think, ideally, we'd want all reports to be 
taken with the same gravity and attentiveness as a potential security issue. I 
ask this, because I'm wondering whether it makes sense to set the standard of 
the _final_ report at 24 hours, but then allow CAs to take up to 7 days (except 
for the types of reports you noted) as an exception, and with an added 
requirement to disclose why they made use of the additional time.

 

That is, let's say someone gets report of a CP/CPS violation, and the CA 
determines that the current BR language is unclear, and they need additional 
time to consult with their auditors and/or the broader community. That seems a 
perfectly reasonable reason to take up to the 7 days - to make sure the 
violation is certain - but it also means we may not know of the potential 
confusion in the language, or the auditors' conclusions, as a community. If we 
have those types of situations disclosed (through, say, a public mail posting 
explaining why the >24 hour investigation took place, and what the challenges 
were), we can, as a community, better address those situatio

Re: [cabfpub] Restarting Ballot 190 v6

[Jeremy Rowley via Public]

I agree we don't want to try and include fixes for the issues identified in
the validation WG. We can start those fixes once the ballot passes.

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Kirk Hall via
Public
Sent: Monday, August 28, 2017 6:29 PM
To: CA/Browser Forum Public Discussion List 
Subject: [cabfpub] Restarting Ballot 190 v6

 

I think the time has come to restart Ballot 190 v6 (as it was ready to go on
July 6 - see attached).  Here is my reasoning.

 

Background

 

As a reminder, the Forum approved ten updated domain validation methods (and
elimination of old Method 7 - "any other method") in Ballot 169, back in
August 2016.  We then realized we had not followed the exact review
procedures of our IPR Agreement (which was intended to create royalty free
licenses for all procedures in the Baseline Requirements), so we set out to
fix that in Ballots 180-182 in January 2017.  

 

It worked!  However, at that point only Methods 5, 6, and 10 had been added
to the BRs; we needed to add back Method 1-4 and 7-9 to the BRs from prior
Ballot 169 in a new ballot.  We also needed to remove the temporary Method
11 - "any other method."  That's what Ballot 190 was intended to do.

 

Ballot 190 circulated starting in April, but a problem arose with
conflicting opinions as to transition rules for the new authentication
methods - for example, if a validation method changed, were CAs and website
owners require to go through a new validation of all domains validated under
the previous version of the method, or could they rely on prior validations
under the old methods for the period allowed by BR 4.2.1, etc.  So we had to
add language clarifying those transition rules, which we did.

 

Version 6 of Ballot 190 was ready to go to a vote in early July, 2017.
However, a few members did not like the use of "Notes" after each validation
method, and preferred we instead use our Definitions to accomplish
everything that was covered by the Notes.  I was fine with that, and pulled
back Ballot 190 v6 so it could be modified to use Definitions instead of
Notes.

 

Unfortunately, our current BR Definitions had problems, and needed to be
amended before being added to the validation methods of BR 3.2.2.4 in Ballot
190.  We tried to fix the Definitions in Ballot 202, but it failed on July
26 for technical reasons that can be fixed.  However, some members are
getting impatient now to get the ten new vetting methods completed in the
BRs, and to remove Method 11 "any other method" as soon as possible.  I
agree.  A new Definitions ballot is still being drafted, and I don't think
we should wait for that - it could take two or three months to finish Ballot
190 if we first vote on a new Definitions ballot.

 

New Issues

 

Over the past few weeks, new questions have arisen about the BR 3.2.2.4
validation methods, including when it's proper to re-use Random Values, when
it's acceptable to follow redirects when using Method 6, and a few other
issues.  These are not quick fixes, and in my opinion it would be a mistake
to try to include any of these changes in Ballot 190.

 

Proposal

 

In order for us to complete the basic step of re-inserting all the Ballot
169 methods with the related clarifications re transition rules, I would
propose we go ahead and vote on Ballot 190 v6 (attached), then immediately
work on the new Definitions, removing the Notes, dealing with reuse of
Random Values and with redirects, etc.  Let's not make the "perfect" ballot
the enemy of the very, very good ballot - we can get to perfection in
stages.



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

Re: [cabfpub] CAA: Interpretation of 3.2.2.8 + 3.2.2.5

[Jeremy Rowley via Public]

That’s the way we interpreted it. 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Monday, August 28, 2017 3:56 PM
To: CABFPub 
Subject: [cabfpub] CAA: Interpretation of 3.2.2.8 + 3.2.2.5

 

I received a question from an auditor regarding CAA that I thought best 
directed through to the broader Forum, both to ensure it's a consistent 
interpretation with the BRs and to see if there is any disagreement with it.

 

The question they raised is as follows (slightly edited)

 

Section 3.2.2.5#3, allows CAs to perform a reverse lookup of the IP, verify 
control of the resulting Domain Name, and issue a certificate. In such a 
situation, does the CA have to perform a CAA check on the “reverse looked-up” 
domain name? Because 3.2.2.8 only requires CAA check for each _dNSName_ in the 
SAN.
 
Most of the certs I see include both the ipAddress and the associated domain 
name in the SAN, so those will be fine (most of the time).
 
However, if the cert does not contain the domain name associated with the ip, 
is a CAA check required? i.e., does such a cert pose any risk to the domain 
holder (from a BR/Browser perspective)?
 
E.g., SAN: dNSName: example.com  , ipAddress: 50.50.50.1
RevLook(50.50.50.1) = example.net  

 

The BRs are unambiguous that "example.com  " must have CAA 
checked for it (it appears in the dNSName). However, should example.net 
  have CAA checked prior to issuing for the equivalent IP?

 

I believe the answer is "No", for the following reasons:

 

1) The language in 3.2.2.8 is clear it applies to the dNSName, so I don't think 
I can argue for an interpretation that suggests it applies to 3.2.2.5, as 
worded :) Whether we intended it to or not is a separate discussion, but 
whether it does or not, at present, is clear :)

 

2) The CAA check does not meaningfully add security, because the certificate 
could have been obtained under 3.2.2.5 (Methods 1, 2, 4), all of which would 
have bypassed any restrictions on CAs.

 

 

As such, if you desire an IP-address bearing certificate, there is no means you 
can use to limit the CAs who can issue or (by virtue of the CA-specific 
extensions) any policies that the issuing CAs use to verify or authenticate the 
request.

 

Does this conclusion feel correct for others?

 

 



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

Re: [cabfpub] Revocation ballot v2

[Jeremy Rowley via Public]

Not hearing from any other CAs, should we state that the CA must make an 
initial determination and report within 24 hours and a final report in 
accordance with the other timeline?



From: Ryan Sleevi [mailto:sle...@google.com]
Sent: Thursday, August 24, 2017 9:18 AM
To: Jeremy Rowley <jeremy.row...@digicert.com>; CA/Browser Forum Public 
Discussion List <public@cabforum.org>
Cc: Gervase Markham <g...@mozilla.org>
Subject: Re: [cabfpub] Revocation ballot v2







On Wed, Aug 23, 2017 at 11:32 PM, Jeremy Rowley via Public 
<public@cabforum.org <mailto:public@cabforum.org> > wrote:

Okay - attached.

a) I added the requirement to maintain an email address for addressing 
certificate problem reports to 4.9.3
b) I added a 24 hour rule for when the original certificate request was not 
authorized.



Jeremy,



I'm wondering if you could speak more to what sort of challenges CAs face in 
making a determination within 24 hours, versus seven days.



For example, consider a report of a CP/CPS non-compliance - which is something 
entirely under the CA's control - particularly for something like a profile 
violation (e.g. extensions when they said they wouldn't have them, missing 
subject naming fields, wrong policies, etc). Why wouldn't a CA be able to make 
a determination about compliance within 24 hours? One downside is I could see 
the added time for investigation adding an incentive to delay investigating 
(in order to delay revocation), rather than purely granting the flexibility 
necessary for complex situations.



I think if you (or others) could share a bit more about the challenges of 
investigating reports, since I think, ideally, we'd want all reports to be 
taken with the same gravity and attentiveness as a potential security issue. I 
ask this, because I'm wondering whether it makes sense to set the standard of 
the _final_ report at 24 hours, but then allow CAs to take up to 7 days 
(except for the types of reports you noted) as an exception, and with an added 
requirement to disclose why they made use of the additional time.



That is, let's say someone gets report of a CP/CPS violation, and the CA 
determines that the current BR language is unclear, and they need additional 
time to consult with their auditors and/or the broader community. That seems a 
perfectly reasonable reason to take up to the 7 days - to make sure the 
violation is certain - but it also means we may not know of the potential 
confusion in the language, or the auditors' conclusions, as a community. If we 
have those types of situations disclosed (through, say, a public mail posting 
explaining why the >24 hour investigation took place, and what the challenges 
were), we can, as a community, better address those situations and work on 
improvements.



I'm wondering if that might address your concern about "two weeks", while also 
help the community better understand the challenges so we can work to improve 
them (in the case they're ambiguities) or collaboratively share best practices 
(in the case of other factors)



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

Re: [cabfpub] Revocation ballot v2

[Jeremy Rowley via Public]

I added the requirement to 4.9.3. That way all of the certificate problem 
reporting requirements are contained in a single section.

 

From: Tim Hollebeek [mailto:tholleb...@trustwave.com] 
Sent: Thursday, August 24, 2017 7:45 AM
To: Adriano Santoni <adriano.sant...@staff.aruba.it>; CA/Browser Forum Public 
Discussion List <public@cabforum.org>; Jeremy Rowley 
<jeremy.row...@digicert.com>
Subject: RE: [cabfpub] Revocation ballot v2

 

I think it’s probably cleaner to put a requirement for an email address for 
problem reports in 1.5.2 where it can have a SHALL.  For some CAs it’s going to 
be the same address as the one that’s already required there.

 

Implied requirements through carefully written definitions are easy to miss.

 

-Tim

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Adriano Santoni 
via Public
Sent: Thursday, August 24, 2017 2:13 AM
To: Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> >; CA/Browser Forum Public Discussion List 
<public@cabforum.org <mailto:public@cabforum.org> >
Subject: Re: [cabfpub] Revocation ballot v2

 

OK. then I agree.

 

Il 24/08/2017 07:44, Jeremy Rowley ha scritto:

Under this change, email is not the only way to manage Certificate Problem 
Reports. The change requires CAs to support at least email, but the CA may 
support any other methods they want to manage.  Regardless of potential spam, 
requiring CAs to manage one mailing list doesn’t seem unreasonable considering 
how difficult/annoying other methods are.

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Adriano Santoni 
via Public
Sent: Wednesday, August 23, 2017 11:40 PM
To: public@cabforum.org <mailto:public@cabforum.org> 
Subject: Re: [cabfpub] Revocation ballot v2

 

The problem I see with mandating an email address as the only way to report a 
problem to the CA is that mailboxes are subject to spamming. Our certificate 
problem reporting mailbox is being targeted to spam more and more, lately, and 
it is not always easy and quick to tell apart real problem reports and spam.

Il 24/08/2017 02:45, Gervase Markham via Public ha scritto:

On 23/08/17 17:39, Jeremy Rowley via Public wrote:

“Certificate Problem Report: A complaint of suspected Key Compromise,
Certificate misuse, or other types of fraud, compromise, misuse, or
inappropriate conduct related to Certificates that is sent to an email
address publicly specified in the CA’s repository. “

 
I think that if we want to mandate that the CA's Problem Reporting
Mechanisms include at minimum an email address, we should say that in
the relevant section, rather than slip it in here.
 
I would be in support of such a change. :-) We are considering it for
Mozilla policy. People currently find it too difficult to send reports
to multiple CAs, having to cope with lots of different mechanisms.
 
Gerv
___
Public mailing list
Public@cabforum.org <mailto:Public@cabforum.org> 
https://cabforum.org/mailman/listinfo/public 
<https://scanmail.trustwave.com/?c=4062=ne6e2Tm40TveA1JmOQYRaAomMM1rSPVAB19MCH3j3w=5=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fpublic>
 

 

 



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

Re: [cabfpub] Revocation ballot v2

[Jeremy Rowley via Public]

I’ll have to defer to others on the investigation period. We usually make the 
determination of a mis-issuance within 24 hours. The only difficulty on our 
side is contacting the subscriber so they know about the revocation.  

 

I’d much rather have a 24 hour investigation period followed by a 2 week 
revocation window than a 7 day investigation period followed by a 1 week 
revocation window because a) it keeps feedback going to the reporter on a 
timeline basis, b) action items under the CA’s control are accelerated, and  c) 
the CA’s job is to issue and manage certificates for its customers – revocation 
and investigation is part of that responsibility. 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Thursday, August 24, 2017 9:18 AM
To: Jeremy Rowley <jeremy.row...@digicert.com>; CA/Browser Forum Public 
Discussion List <public@cabforum.org>
Cc: Gervase Markham <g...@mozilla.org>
Subject: Re: [cabfpub] Revocation ballot v2

 

 

 

On Wed, Aug 23, 2017 at 11:32 PM, Jeremy Rowley via Public <public@cabforum.org 
<mailto:public@cabforum.org> > wrote:

Okay - attached.

a) I added the requirement to maintain an email address for addressing 
certificate problem reports to 4.9.3
b) I added a 24 hour rule for when the original certificate request was not 
authorized.

 

Jeremy,

 

I'm wondering if you could speak more to what sort of challenges CAs face in 
making a determination within 24 hours, versus seven days. 

 

For example, consider a report of a CP/CPS non-compliance - which is something 
entirely under the CA's control - particularly for something like a profile 
violation (e.g. extensions when they said they wouldn't have them, missing 
subject naming fields, wrong policies, etc). Why wouldn't a CA be able to make 
a determination about compliance within 24 hours? One downside is I could see 
the added time for investigation adding an incentive to delay investigating (in 
order to delay revocation), rather than purely granting the flexibility 
necessary for complex situations.

 

I think if you (or others) could share a bit more about the challenges of 
investigating reports, since I think, ideally, we'd want all reports to be 
taken with the same gravity and attentiveness as a potential security issue. I 
ask this, because I'm wondering whether it makes sense to set the standard of 
the _final_ report at 24 hours, but then allow CAs to take up to 7 days (except 
for the types of reports you noted) as an exception, and with an added 
requirement to disclose why they made use of the additional time.

 

That is, let's say someone gets report of a CP/CPS violation, and the CA 
determines that the current BR language is unclear, and they need additional 
time to consult with their auditors and/or the broader community. That seems a 
perfectly reasonable reason to take up to the 7 days - to make sure the 
violation is certain - but it also means we may not know of the potential 
confusion in the language, or the auditors' conclusions, as a community. If we 
have those types of situations disclosed (through, say, a public mail posting 
explaining why the >24 hour investigation took place, and what the challenges 
were), we can, as a community, better address those situations and work on 
improvements.

 

I'm wondering if that might address your concern about "two weeks", while also 
help the community better understand the challenges so we can work to improve 
them (in the case they're ambiguities) or collaboratively share best practices 
(in the case of other factors)



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

Re: [cabfpub] Revocation ballot v2

[Jeremy Rowley via Public]

Under this change, email is not the only way to manage Certificate Problem 
Reports. The change requires CAs to support at least email, but the CA may 
support any other methods they want to manage.  Regardless of potential spam, 
requiring CAs to manage one mailing list doesn’t seem unreasonable considering 
how difficult/annoying other methods are.

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Adriano Santoni 
via Public
Sent: Wednesday, August 23, 2017 11:40 PM
To: public@cabforum.org
Subject: Re: [cabfpub] Revocation ballot v2

 

The problem I see with mandating an email address as the only way to report a 
problem to the CA is that mailboxes are subject to spamming. Our certificate 
problem reporting mailbox is being targeted to spam more and more, lately, and 
it is not always easy and quick to tell apart real problem reports and spam.

Il 24/08/2017 02:45, Gervase Markham via Public ha scritto:

On 23/08/17 17:39, Jeremy Rowley via Public wrote:

“Certificate Problem Report: A complaint of suspected Key Compromise,
Certificate misuse, or other types of fraud, compromise, misuse, or
inappropriate conduct related to Certificates that is sent to an email
address publicly specified in the CA’s repository. “

 
I think that if we want to mandate that the CA's Problem Reporting
Mechanisms include at minimum an email address, we should say that in
the relevant section, rather than slip it in here.
 
I would be in support of such a change. :-) We are considering it for
Mozilla policy. People currently find it too difficult to send reports
to multiple CAs, having to cope with lots of different mechanisms.
 
Gerv
___
Public mailing list
Public@cabforum.org <mailto: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] Revocation ballot v2

[Jeremy Rowley via Public]

Okay - attached.

a) I added the requirement to maintain an email address for addressing 
certificate problem reports to 4.9.3
b) I added a 24 hour rule for when the original certificate request was not 
authorized. 

If I have everything, I'm looking for two endorsers on this one.

 

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org] 
Sent: Wednesday, August 23, 2017 6:47 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>; CA/Browser Forum Public 
Discussion List <public@cabforum.org>
Subject: Re: [cabfpub] Revocation ballot v2

On 23/08/17 11:56, Jeremy Rowley via Public wrote:
> Attached is a revised version of the revocation ballot. This leaves 
> the revocation deadline at 24 hours for key compromise, but gives CAs 
> a week to respond to other issues. Pretty sure I don’t need to preface 
> where this proposal is coming from.

This seems pretty excellent. The only issue is, as you say, if it turns out 
that a cert is issued to the wrong person, 8 days seems long. Could we say that 
if the CA determines that the cert is issued to the wrong person, they must 
immediately revoke within 24 hours; they don't get the remainder of the 7 days 
before having to revoke? Not perhaps easily enforceable, but a commendation of 
good practice.

Gerv



Revocation-Time-Revision-Ballot v2.doc
Description: MS-Word document


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

Re: [cabfpub] Revocation ballot v2

[Jeremy Rowley via Public]

Thanks Ryan!  

 

One more thing I think we should address in this ballot is when the time period 
starts.  The definition for certificate problem report is:

 

“Certificate Problem Report: Complaint of suspected Key Compromise, Certificate 
misuse, or other types of fraud, compromise, misuse, or inappropriate conduct 
related to Certificates. “

The CA is obligated, under Section 4.9.5, to start investigating within 24 
hours of receipt.  Receipt is vague.  On the Mozilla list, I mentioned that we 
should require all CAs to have at least an email address where these are 
submitted.  What do you think about changing the Certificate Problem Report to:

 

“Certificate Problem Report: A complaint of suspected Key Compromise, 
Certificate misuse, or other types of fraud, compromise, misuse, or 
inappropriate conduct related to Certificates that is sent to an email address 
publicly specified in the CA’s repository. “

 

 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Wednesday, August 23, 2017 2:26 PM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Revocation ballot v2

 

 

 

On Wed, Aug 23, 2017 at 3:42 PM, Jeremy Rowley  > wrote:

Looking at it another way, the timelines are:

 

24 hours if the Subscriber requests the cert (no certificate problem report)

48 hours if there is a key compromise (24 hour investigation + 24 hour to 
revoke)

8 days if the cert was issued to the wrong domain name or organization (7 day 
investigation + 24 hours to revoke) *

14 days for all other reasons

 

* My heartburn over how long this is to take care of.  8 days is a long time 
where domain validation failed.

 

I think the requirement to reply to the certificate problem report is built in 
by requiring the CA to work with the entity making the report. I don’t have a 
good idea on how to improve the escalation path.

 

OK, good, then I wasn't misreading the proposal, and I think the broad strokes 
of that are a good balance between the community need and a reasonable amount 
of flexibility for CAs.



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

Re: [cabfpub] Revocation ballot v2

[Jeremy Rowley via Public]

Looking at it another way, the timelines are:

 

24 hours if the Subscriber requests the cert (no certificate problem report)

48 hours if there is a key compromise (24 hour investigation + 24 hour to 
revoke)

8 days if the cert was issued to the wrong domain name or organization (7 day 
investigation + 24 hours to revoke) *

14 days for all other reasons

 

* My heartburn over how long this is to take care of.  8 days is a long time 
where domain validation failed.

 

I think the requirement to reply to the certificate problem report is built in 
by requiring the CA to work with the entity making the report. I don’t have a 
good idea on how to improve the escalation path.

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Wednesday, August 23, 2017 1:33 PM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Revocation ballot v2

 

 

 

On Wed, Aug 23, 2017 at 3:25 PM, Jeremy Rowley  > wrote:

Hmm  - that does seem long.  What if we keep the investigation to 24 hours and 
change revocation to 24 hours/2 weeks? There’s no reason for the CA to delay 
investigating any issue.

 

I wasn't trying to suggest it's long. I think we've seen some CAs want to 
investigate, such as relevant RFCs, errata, document and change control 
history, etc. That it is bounded at an upper-bound (by 14 days) keeps it within 
a reasonable frame. If a CA wants more time, they should be proactively 
internally reviewing for compliance :)

 

For transparency, what do you suggest?  I left it the same as today. Perhaps 
state that the CA MUST reply to the certificate problem reporter about its 
decision within 3 days?

 

I know we'd previously talked about reports to public@cabforum.org 
 , in line with how 9.16.3 is handled for local 
law, but the fact that we have a maximum cap at 14 days for revocation does, I 
think, reduce the risk. I'm also sensitive to the fact that running any form of 
'security bug queue' will result in absolutely terrible submissions that are 
fundamentally incorrect, and I don't want to further impose additional costs 
for having to deal with junk-reports.

 

My concern is that CAs who receive problem reports would be incentivized to 
close them as "not an issue", and thus force the root stores to get involved, 
but that's arguably the status quo today. I think root stores that want to 
address this would have a variety of tools - for example, requiring quarterly 
disclosures of the number of problem reports received, responded to, etc - that 
could address some of those high-level concerns, hopefully without introducing 
significant burden for junk reports. After all, today, if a CA gets a junk 
report, there's also zero disclosure requirements - so I'm not terribly 
convinced we need to solve that problem as well, provided that the cap at 14 
days stands.

 



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

Re: [cabfpub] Revocation ballot v2

[Jeremy Rowley via Public]

Hmm  - that does seem long.  What if we keep the investigation to 24 hours and 
change revocation to 24 hours/2 weeks? There’s no reason for the CA to delay 
investigating any issue.

 

For transparency, what do you suggest?  I left it the same as today. Perhaps 
state that the CA MUST reply to the certificate problem reporter about its 
decision within 3 days?  

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Wednesday, August 23, 2017 1:10 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>; CA/Browser Forum Public 
Discussion List <public@cabforum.org>
Subject: Re: [cabfpub] Revocation ballot v2

 

To make sure I'm summarizing the meaningful change:

- 7 days upon when a CA itself decides a violation (e.g. CA failing to follow 
its CP/CPS or the Baseline Requirements)

- 14 days (up to 7 days for investigation/confirmation) for an external report 
of a CA violating its CP/CPS

  - 7 days for investigation & FINAL report

  - While still requiring that CAs MUST NOT exceed 7 days from that 
determination to revoke

 

And not requiring any transparency for reports the CA determines are 'not 
valid', right? Meaning any problem reporter who feels the CA's response is 
inadequate must, as they do today, escalate to Application Software Suppliers.

 

Did I properly summarize? I want to make sure I parse it right (the "MUST not" 
was subtle, for example, in part due to non-2119 capitalization), particularly 
that the CA must still revoke within a total of 14 days for 
externally-reported-and-confirmed issues.

 

On Wed, Aug 23, 2017 at 2:56 PM, Jeremy Rowley via Public <public@cabforum.org 
<mailto:public@cabforum.org> > wrote:

Attached is a revised version of the revocation ballot. This leaves the 
revocation deadline at 24 hours for key compromise, but gives CAs a week to 
respond to other issues. Pretty sure I don’t need to preface where this 
proposal is coming from.

 

Thoughts?

Jeremy


___
Public mailing list
Public@cabforum.org <mailto: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

[cabfpub] Revocation ballot v2

[Jeremy Rowley via Public]

Attached is a revised version of the revocation ballot. This leaves the
revocation deadline at 24 hours for key compromise, but gives CAs a week to
respond to other issues. Pretty sure I don't need to preface where this
proposal is coming from.

 

Thoughts?

Jeremy



Revocation-Time-Revision-Ballot v2.doc
Description: MS-Word document


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

Re: [cabfpub] Minutes & Agendas for WG teleconferences & meetings

[Jeremy Rowley via Public]

Agreed. I'll migrate old ones to the wiki and start sending new agendas and 
minutes to the public list. It's a good idea regardless so everyone can 
evaluate whether they want to join or if they missed anything interesting.

On Aug 16, 2017, at 10:34 AM, Ryan Sleevi via Public 
> wrote:

Right, you're talking about 
https://cabforum.org/pipermail/validation/2017-July/000621.html or 
https://cabforum.org/pipermail/validation/2017-June/000605.html , right?

I couldn't find the draft or final agendas for the meetings (I would think 
agendas are sent before the meeting). I'm also not sure that matches the 
Bylaws, which use Public Mail List as a specific term.

Don't get me wrong, I'm glad to see/hear the Validation WG is doing this, and 
it's good to understand context, but I would hate for a member to suggest that 
a (minuted to the validation WG) contribution was or was not in-scope of the IP 
policy.



On Wed, Aug 16, 2017 at 1:26 PM, Jeremy Rowley 
> wrote:
The validation WG minutes have been sent the public mailing list for the WG, 
although I haven’t been to the last few so haven’t written up minutes on them.  
The agendas are posted to the same threat.

From: Public 
[mailto:public-boun...@cabforum.org] On 
Behalf Of Ryan Sleevi via Public
Sent: Wednesday, August 16, 2017 11:23 AM
To: CABFPub >
Subject: [cabfpub] Minutes & Agendas for WG teleconferences & meetings

In looking through to make sure we weren't having any mailing list issues, and 
that my filters were good, I haven't been able to find any minutes of the 
Working Group teleconferences being posted to the Public Mail List, nor the 
draft and final agendas of the WG meetings. They also don't seem to be posted 
to https://cabforum.org/category/minutes/ (which is where our Minutes link to 
for the webpage)

Per 5.2(a) and (b) of our Bylaws, these should end up on one either the Public 
Mail List or Public Web Site. Have folks been posting these, and the mail list 
not sending them? Or have the WG Chairs not been following the bylaws?

It'd be great if we could make sure those agendas and (final) minutes are 
captured, particularly given the IP concerns, so that contributions such as the 
Network Security work or the Validation work be recorded and attributed 
appropriately. However, if I've simply missed them, if someone can link me to 
the past few months' work, that'd be super-appreciated.

Thanks!

___
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] Minutes & Agendas for WG teleconferences & meetings

[Jeremy Rowley via Public]

The validation WG minutes have been sent the public mailing list for the WG, 
although I haven’t been to the last few so haven’t written up minutes on them.  
The agendas are posted to the same threat.  

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Wednesday, August 16, 2017 11:23 AM
To: CABFPub 
Subject: [cabfpub] Minutes & Agendas for WG teleconferences & meetings

 

In looking through to make sure we weren't having any mailing list issues, and 
that my filters were good, I haven't been able to find any minutes of the 
Working Group teleconferences being posted to the Public Mail List, nor the 
draft and final agendas of the WG meetings. They also don't seem to be posted 
to https://cabforum.org/category/minutes/ (which is where our Minutes link to 
for the webpage)

 

Per 5.2(a) and (b) of our Bylaws, these should end up on one either the Public 
Mail List or Public Web Site. Have folks been posting these, and the mail list 
not sending them? Or have the WG Chairs not been following the bylaws?

 

It'd be great if we could make sure those agendas and (final) minutes are 
captured, particularly given the IP concerns, so that contributions such as the 
Network Security work or the Validation work be recorded and attributed 
appropriately. However, if I've simply missed them, if someone can link me to 
the past few months' work, that'd be super-appreciated.

 

Thanks!



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

Re: [cabfpub] Random value reuse

[Jeremy Rowley via Public]

True - unless the CA reads it as the domain contact/role account as being the 
applicant. 

-Original Message-
From: Peter Bowen [mailto:p...@amzn.com] 
Sent: Wednesday, August 9, 2017 3:49 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: Ben Wilson <ben.wil...@digicert.com>; geo...@apple.com; CA/Browser Forum 
Public Discussion List <public@cabforum.org>; Gervase Markham 
<g...@mozilla.org>; Rich Smith <richard.sm...@comodo.com>
Subject: Re: [cabfpub] Random value reuse

In methods 2 & 4 it goes to the domain contact or a role account at the domain. 
 Giving it to the applicant voids the whole purpose of the exercise, as the 
applicant isn’t the one who needs to approve the request.

Thanks,
Peter

> On Aug 9, 2017, at 2:46 PM, Jeremy Rowley <jeremy.row...@digicert.com> wrote:
> 
> How do you figure? They can provide it by email to the applicant.  
> 
> -Original Message-
> From: Peter Bowen [mailto:p...@amzn.com]
> Sent: Wednesday, August 9, 2017 3:46 PM
> To: Ben Wilson <ben.wil...@digicert.com>
> Cc: geo...@apple.com; CA/Browser Forum Public Discussion List 
> <public@cabforum.org>; Gervase Markham <g...@mozilla.org>; Jeremy 
> Rowley <jeremy.row...@digicert.com>; Rich Smith 
> <richard.sm...@comodo.com>
> Subject: Re: [cabfpub] Random value reuse
> 
> That definition is problematic.  In methods 2 & 4, the CA doesn’t provide the 
> random value to the applicant.
> 
>> On Aug 9, 2017, at 2:33 PM, Ben Wilson <ben.wil...@digicert.com> wrote:
>> 
>> I suppose you're right, since the definition of "Random Value" is "A value 
>> specified by a CA to the Applicant that exhibits at least 112 bits of 
>> entropy."
>> 
>> 
>> -Original Message-
>> From: geo...@apple.com [mailto:geo...@apple.com]
>> Sent: Wednesday, August 9, 2017 3:30 PM
>> To: Ben Wilson <ben.wil...@digicert.com>
>> Cc: CA/Browser Forum Public Discussion List <public@cabforum.org>; 
>> Gervase Markham <g...@mozilla.org>; Jeremy Rowley 
>> <jeremy.row...@digicert.com>; Rich Smith <richard.sm...@comodo.com>; 
>> Peter Bowen <p...@amzn.com>
>> Subject: Re: [cabfpub] Random value reuse
>> 
>> 
>>> On 9 Aug 2017, at 2:24 pm, Ben Wilson <ben.wil...@digicert.com> wrote:
>>> 
>>> Agreed.  And each method should stand on its own without cross-referencing 
>>> among methods (otherwise tracking the particular method used will be too 
>>> complicated).  So I'm OK without cross-referencing methods.
>>> 
>>> But are we clear enough?  For example, the currently proposed method 10 
>>> could probably benefit from better language on how the applicant obtains 
>>> the random value.  Currently it only says, "Confirming the Applicant's 
>>> control over the FQDN by confirming the presence of a Random Value within a 
>>> Certificate on the Authorization Domain Name which is accessible by the CA 
>>> via TLS over an Authorized Port."  The other methods seem to specify the 
>>> process more thoroughly.
>> 
>> I think it doesn’t matter, in this case, how the Random Value gets to the 
>> Applicant—we don’t want to overspecify things like this, because that limits 
>> the ability of CAs to innovate.
>> 
>>> 
>>> -Original Message-
>>> From: geo...@apple.com [mailto:geo...@apple.com]
>>> Sent: Wednesday, August 9, 2017 3:11 PM
>>> To: Ben Wilson <ben.wil...@digicert.com>; CA/Browser Forum Public 
>>> Discussion List <public@cabforum.org>
>>> Cc: Gervase Markham <g...@mozilla.org>; Jeremy Rowley 
>>> <jeremy.row...@digicert.com>; Rich Smith <richard.sm...@comodo.com>; 
>>> Peter Bowen <p...@amzn.com>
>>> Subject: Re: [cabfpub] Random value reuse
>>> 
>>> I think that’s where the ‘single communication’ rule really helps.  
>>> Then this is taken care of by the descriptions of the methods: if 
>>> you have to send the random value to a particular place, then 
>>> obviously that can’t be combined with a random value sent some other 
>>> way; if you have to put it in a particular place, then it doesn’t 
>>> matter how it was sent…
>>> 
>>>> On 9 Aug 2017, at 1:54 pm, Ben Wilson via Public <public@cabforum.org> 
>>>> wrote:
>>>> 
>>>> Putting the  issue of "reuse" aside, do we need to clarify this issue of 
>>>> which random value methods can be used in combination with others?  It 
>>>> seems that a random 

Re: [cabfpub] Random value reuse

[Jeremy Rowley via Public]

Here's the ways I think random value is either contemplated or being provided:
1) Email to WHOIS/Constructed emails
2) Phone call to applicant
3) Email to applicant
4) Display on website (in the user's account)
5) Through integration tools 
6) Through an API
7) Through a partner/reseller 
8) By making the change to the DNS/website itself
9) As part of a private certificate


These are all okay? A few seem sketchy. 


-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: Wednesday, August 9, 2017 3:46 PM
To: Ben Wilson <ben.wil...@digicert.com>; geo...@apple.com
Cc: CA/Browser Forum Public Discussion List <public@cabforum.org>
Subject: Re: [cabfpub] Random value reuse

It raises a lot of questions though.  Can I email the Random Value to a 
reseller who forwards it on to the end entity?  Can I display it on a website 
without them logging in?  Right now, no security or controls is built on 
delivery of Random Value. 

-Original Message-
From: Ben Wilson 
Sent: Wednesday, August 9, 2017 3:33 PM
To: geo...@apple.com
Cc: CA/Browser Forum Public Discussion List <public@cabforum.org>; Gervase 
Markham <g...@mozilla.org>; Jeremy Rowley <jeremy.row...@digicert.com>; Rich 
Smith <richard.sm...@comodo.com>; Peter Bowen <p...@amzn.com>
Subject: RE: [cabfpub] Random value reuse

I suppose you're right, since the definition of "Random Value" is "A value 
specified by a CA to the Applicant that exhibits at least 112 bits of entropy."


-Original Message-
From: geo...@apple.com [mailto:geo...@apple.com] 
Sent: Wednesday, August 9, 2017 3:30 PM
To: Ben Wilson <ben.wil...@digicert.com>
Cc: CA/Browser Forum Public Discussion List <public@cabforum.org>; Gervase 
Markham <g...@mozilla.org>; Jeremy Rowley <jeremy.row...@digicert.com>; Rich 
Smith <richard.sm...@comodo.com>; Peter Bowen <p...@amzn.com>
Subject: Re: [cabfpub] Random value reuse


> On 9 Aug 2017, at 2:24 pm, Ben Wilson <ben.wil...@digicert.com> wrote:
> 
> Agreed.  And each method should stand on its own without cross-referencing 
> among methods (otherwise tracking the particular method used will be too 
> complicated).  So I'm OK without cross-referencing methods.
> 
> But are we clear enough?  For example, the currently proposed method 10 could 
> probably benefit from better language on how the applicant obtains the random 
> value.  Currently it only says, "Confirming the Applicant's control over the 
> FQDN by confirming the presence of a Random Value within a Certificate on the 
> Authorization Domain Name which is accessible by the CA via TLS over an 
> Authorized Port."  The other methods seem to specify the process more 
> thoroughly.

I think it doesn’t matter, in this case, how the Random Value gets to the 
Applicant—we don’t want to overspecify things like this, because that limits 
the ability of CAs to innovate.

> 
> -Original Message-
> From: geo...@apple.com [mailto:geo...@apple.com] 
> Sent: Wednesday, August 9, 2017 3:11 PM
> To: Ben Wilson <ben.wil...@digicert.com>; CA/Browser Forum Public Discussion 
> List <public@cabforum.org>
> Cc: Gervase Markham <g...@mozilla.org>; Jeremy Rowley 
> <jeremy.row...@digicert.com>; Rich Smith <richard.sm...@comodo.com>; Peter 
> Bowen <p...@amzn.com>
> Subject: Re: [cabfpub] Random value reuse
> 
> I think that’s where the ‘single communication’ rule really helps.  Then this 
> is taken care of by the descriptions of the methods: if you have to send the 
> random value to a particular place, then obviously that can’t be combined 
> with a random value sent some other way; if you have to put it in a 
> particular place, then it doesn’t matter how it was sent…
> 
>> On 9 Aug 2017, at 1:54 pm, Ben Wilson via Public <public@cabforum.org> wrote:
>> 
>> Putting the  issue of "reuse" aside, do we need to clarify this issue of 
>> which random value methods can be used in combination with others?  It seems 
>> that a random value could be provided to the domain contact / admin under 
>> methods 2, 3 (if you wanted) or 4 and then used within 30 days for methods 
>> 2, 4, 6, 7 and 10,  but not vice versa.
>> 
>> -Original Message-
>> From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase 
>> Markham via Public
>> Sent: Monday, July 31, 2017 9:02 AM
>> To: Jeremy Rowley <jeremy.row...@digicert.com>; CA/Browser Forum Public 
>> Discussion List <public@cabforum.org>; Rich Smith 
>> <richard.sm...@comodo.com>; 'Peter Bowen' <p...@amzn.com>
>> Subject: Re: [cabfpub] Random value reuse
>> 
>> On 28/07/17 14:53, Jere

Re: [cabfpub] Random value reuse

[Jeremy Rowley via Public]

It raises a lot of questions though.  Can I email the Random Value to a 
reseller who forwards it on to the end entity?  Can I display it on a website 
without them logging in?  Right now, no security or controls is built on 
delivery of Random Value. 

-Original Message-
From: Ben Wilson 
Sent: Wednesday, August 9, 2017 3:33 PM
To: geo...@apple.com
Cc: CA/Browser Forum Public Discussion List <public@cabforum.org>; Gervase 
Markham <g...@mozilla.org>; Jeremy Rowley <jeremy.row...@digicert.com>; Rich 
Smith <richard.sm...@comodo.com>; Peter Bowen <p...@amzn.com>
Subject: RE: [cabfpub] Random value reuse

I suppose you're right, since the definition of "Random Value" is "A value 
specified by a CA to the Applicant that exhibits at least 112 bits of entropy."


-Original Message-
From: geo...@apple.com [mailto:geo...@apple.com] 
Sent: Wednesday, August 9, 2017 3:30 PM
To: Ben Wilson <ben.wil...@digicert.com>
Cc: CA/Browser Forum Public Discussion List <public@cabforum.org>; Gervase 
Markham <g...@mozilla.org>; Jeremy Rowley <jeremy.row...@digicert.com>; Rich 
Smith <richard.sm...@comodo.com>; Peter Bowen <p...@amzn.com>
Subject: Re: [cabfpub] Random value reuse


> On 9 Aug 2017, at 2:24 pm, Ben Wilson <ben.wil...@digicert.com> wrote:
> 
> Agreed.  And each method should stand on its own without cross-referencing 
> among methods (otherwise tracking the particular method used will be too 
> complicated).  So I'm OK without cross-referencing methods.
> 
> But are we clear enough?  For example, the currently proposed method 10 could 
> probably benefit from better language on how the applicant obtains the random 
> value.  Currently it only says, "Confirming the Applicant's control over the 
> FQDN by confirming the presence of a Random Value within a Certificate on the 
> Authorization Domain Name which is accessible by the CA via TLS over an 
> Authorized Port."  The other methods seem to specify the process more 
> thoroughly.

I think it doesn’t matter, in this case, how the Random Value gets to the 
Applicant—we don’t want to overspecify things like this, because that limits 
the ability of CAs to innovate.

> 
> -Original Message-
> From: geo...@apple.com [mailto:geo...@apple.com] 
> Sent: Wednesday, August 9, 2017 3:11 PM
> To: Ben Wilson <ben.wil...@digicert.com>; CA/Browser Forum Public Discussion 
> List <public@cabforum.org>
> Cc: Gervase Markham <g...@mozilla.org>; Jeremy Rowley 
> <jeremy.row...@digicert.com>; Rich Smith <richard.sm...@comodo.com>; Peter 
> Bowen <p...@amzn.com>
> Subject: Re: [cabfpub] Random value reuse
> 
> I think that’s where the ‘single communication’ rule really helps.  Then this 
> is taken care of by the descriptions of the methods: if you have to send the 
> random value to a particular place, then obviously that can’t be combined 
> with a random value sent some other way; if you have to put it in a 
> particular place, then it doesn’t matter how it was sent…
> 
>> On 9 Aug 2017, at 1:54 pm, Ben Wilson via Public <public@cabforum.org> wrote:
>> 
>> Putting the  issue of "reuse" aside, do we need to clarify this issue of 
>> which random value methods can be used in combination with others?  It seems 
>> that a random value could be provided to the domain contact / admin under 
>> methods 2, 3 (if you wanted) or 4 and then used within 30 days for methods 
>> 2, 4, 6, 7 and 10,  but not vice versa.
>> 
>> -Original Message-
>> From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase 
>> Markham via Public
>> Sent: Monday, July 31, 2017 9:02 AM
>> To: Jeremy Rowley <jeremy.row...@digicert.com>; CA/Browser Forum Public 
>> Discussion List <public@cabforum.org>; Rich Smith 
>> <richard.sm...@comodo.com>; 'Peter Bowen' <p...@amzn.com>
>> Subject: Re: [cabfpub] Random value reuse
>> 
>> On 28/07/17 14:53, Jeremy Rowley via Public wrote:
>>> I think the random value should be tied to a single communication 
>>> without reuse.  For example, a single email sent to the constructed 
>>> emails, a single API call, a single phone call, etc.  The random value 
>>> shouldn’t be tied to a method, but should be tied to a specific 
>>> communication from the CA that is tied to a request. By getting rid of 
>>> the reuse language, we can simplify the process and eliminate the risk 
>>> associated with reuse.
>> 
>> Right. New random values are cheap :-)
>> 
>> Gerv
>> ___
>> Public mailing list
>> Public@cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>> ___
>> 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] Random value reuse

[Jeremy Rowley via Public]

I think the random value should be tied to a single communication without 
reuse.  For example, a single email sent to the constructed emails, a single 
API call, a single phone call, etc.  The random value shouldn’t be tied to a 
method, but should be tied to a specific communication from the CA that is tied 
to a request. By getting rid of the reuse language, we can simplify the process 
and eliminate the risk associated with reuse.

 

From: Rich Smith [mailto:richard.sm...@comodo.com] 
Sent: Friday, July 28, 2017 6:38 AM
To: 'Peter Bowen' <p...@amzn.com>; 'CA/Browser Forum Public Discussion List' 
<public@cabforum.org>; Jeremy Rowley <jeremy.row...@digicert.com>
Subject: RE: [cabfpub] Random value reuse

 

Peter,

You make good points.  How about something along the lines of:

 

The CA SHALL NOT share the random value generated for methods 2 and/or 4 with 
the Applicant via any other method, but the CA MAY accept that random value for 
verification under methods 6, 7 and 10.

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Peter Bowen via 
Public
Sent: Wednesday, July 26, 2017 12:34 AM
To: Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> >; CA/Browser Forum Public Discussion List 
<public@cabforum.org <mailto:public@cabforum.org> >
Subject: Re: [cabfpub] Random value reuse

 

Jeremy,

 

This is an interesting question and I the answer is you cannot share a value 
across all five of the methods you list.

 

Methods 2 and 4 involve sending the value privately to contacts related to the 
domain (either from registration data or role mailboxes). The certificate 
applicant does not know the random value unless they are a contact or the 
contact gives them the random value.  The CA doesn’t care how it gets the value 
back for these methods.

 

On the other hand, 6, 7, and 10 involve giving the applicant the random value 
and then the CA verifying the applicant could cause it to appear on something 
related to the domain.  The CA then looks for it at the right point.

 

If you use the same value for 2/4 and 6/7/10, then the workflow could look like:

- Certificate request

- You generate the random value and give it to the applicant (intending to be 
used for 6/7/10)

- Applicant turns around and submits it back to you (as if they had gotten it 
from a domain contact as per 2/4)

Result: No confirmation the applicant is authorized (BAD)

 

Alternatively, you could:

- Get certificate request

- Send random value to one or more addressed allowed by 2/4

- Then look for the value in a location allowed by 6/7/10

Result: double confirmation (good, but beyond the minimal requirement)

 

Maybe we should clarify this somehow in 3.2.2.4.

 

Thanks,

Peter

 

 

 

On Jul 25, 2017, at 9:20 PM, Jeremy Rowley via Public <public@cabforum.org 
<mailto:public@cabforum.org> > wrote:

 

An interesting question came up today in connection with random values used for 
validation.  Methods 2, 4, 6, 7, and 10 permit use of a random values. Methods 
2 and 4, require a unique random value per email. Methods 6, 7, and 10 do not 
require unique random values per request for the random value. 

 

Some customers would like to use the same random value across multiple methods 
(method 2, 6, and 7), having us look for the first instance of the random 
value, or across multiple domains. Method 6 and 7 require a unique random value 
per certificate request, not per domain. This means, that the same Random Value 
can appear in multiple DNS records at once to confirm control. 

 

The questions raised by this are:

1.  Should the random value be unique per verified domain name instead of 
per certificate request? With email methods, use of a single email to verify 
multiple domain names with the same email address makes sense. I’m not sure 
this makes as much sense for DNS records.  
2.  Can multiple methods use the same random value? Can you request a 
random value and then the CA just scour the permitted locations to find it? 
This seems okay to me as nothing requires the CA to specify the method of 
validation associated with the Random Value, but thought I’d get other opinions.

 

 

Jeremy

___
Public mailing list
 <mailto:Public@cabforum.org> Public@cabforum.org
 <https://cabforum.org/mailman/listinfo/public> 
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] [Ext] .well-known and re-directs

[Jeremy Rowley via Public]

Thanks a ton for the reply, Ryan! {Didn't mean to make it sound urgent, but 
that same question keeps arising during the verification process} 

Your summary is correct, and my thinking aligned with yours - that we want a 
single request/response for verification.  I was surprised Let's Encyrpt was 
permitting re-directs.  However, as you pointed, they did not state Let's 
Encrypt permits redirects to a separate domain (just a port change).  

Jacob - does Let's Encrypt permit redirects to other sites or does the request 
token/random value need to be on the same authorization domain, just a 
different port?  

-Original Message-
From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Friday, July 21, 2017 9:05 AM
To: Jeremy Rowley <jeremy.row...@digicert.com>; CA/Browser Forum Public 
Discussion List <public@cabforum.org>
Cc: Jacob Hoffman-Andrews <j...@letsencrypt.org>; Paul Hoffman 
<paul.hoff...@icann.org>
Subject: Re: [cabfpub] [Ext] .well-known and re-directs

Hi Jeremy,

Apologies for the delay in responding. Would this be a correct summary of the 
confusion:

In HTTP, it is a Request/Response protocol. A request is made for a given 
resource, and a response is provided. Some responses include the resource 
directly requested (e.g. the 200/2xx series), other responses may indicate the 
resource has moved (e.g. 304) or is not available (e.g. 404 or 500). These are 
valid responses, but they indicate they're not the resource requested.

The question is whether or not a CA is expected to perform a single 
Request/Response in the of retrieving a resource (namely, "the content of a 
file or on a web page"), or whether it is allowed to adhere to the HTTP 
semantics that indicate how multiple Requests can be made to ultimately satisfy 
a resource fetch.

Personally, I'm strongly of the opinion that the Required Website Content 
should be obtained via a single Request/Response workflow.
This aligns with at least some of the audit reports I've seen, where various 
auditors (whether security or BR) have interpreted this section as being 
restrictive to a single Request/Response flow, and appropriately flagged when a 
CA follows redirects. This suggests that there's at least some agreement on 
this view.

That said, I can also understand and appreciate a view that, by specifying 
"content of a file or on a web page", we may have inadvertently allowed for an 
interpretation that allows for multiple Requests/Responses.

When considering the reasonableness of either approach, it does seem important 
to consider this: Would we consider it reasonable for a CA to issue Range 
Requests for the file or a web page? This is where multiple requests can be 
made that, in their sum totality, encompass the fullness of the file or the web 
page. Would we allow for partial range requests (e.g. the CA only requesting 
say, the first 32 bytes).
Would we expect CAs to detect situations of truncation (e.g. the content 
received does not align with the Content-Length) and either recover from it, 
reject it, or accept it as valid?

I'm certainly curious others' take, but from an overall security perspective 
(and aligning with the security audits of CAs that I've seen), there seems to 
be a general belief that a single Request/Response pair is all that is 
permitted.

Jacob has taken the view on the rewrite of the scheme, but without modifying 
the domain. If a server redirected to ftp://, would we still consider that 
Required Website Content? If it redirected to ldap://, would we still consider 
that Required Website content?

That said, I haven't heard any arguments that "on the Authorization Domain" 
encompasses anything other than the domain itself. At best, a modification of 
scheme (and thus, transitively, a modification of the port used - which needs 
to be congruent with Authorized Ports) may be worth discussing, but I would not 
want to see any scoping beyond that.

In these situations, it seems most advisable to take the restrictive approach - 
to disable redirects. The website authentication mechanism is already 
substantially less secure than some of our other methods, and the less we can 
do to increase that attack surface, the better.

On Fri, Jul 21, 2017 at 10:49 AM, Jeremy Rowley via Public 
<public@cabforum.org> wrote:
> Is the lack of additional response agreement that “on the 
> Authorization Domain” encompasses both the authorization domain names 
> and redirects from an authorization domain name?
>
>
>
> From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy 
> Rowley via Public
> Sent: Thursday, July 20, 2017 8:37 AM
> To: Jacob Hoffman-Andrews <j...@letsencrypt.org>; Paul Hoffman 
> <paul.hoff...@icann.org>; CA/Browser Forum Public Discussion List 
> <public@cabforum.org>
> Subject: Re: [cabfpub] [Ext] .well-known and re-directs
>
>
>
> The BR language state

Re: [cabfpub] [Ext] .well-known and re-directs

[Jeremy Rowley via Public]

Is the lack of additional response agreement that “on the Authorization Domain” 
encompasses both the authorization domain names and redirects from an 
authorization domain name? 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: Thursday, July 20, 2017 8:37 AM
To: Jacob Hoffman-Andrews <j...@letsencrypt.org>; Paul Hoffman 
<paul.hoff...@icann.org>; CA/Browser Forum Public Discussion List 
<public@cabforum.org>
Subject: Re: [cabfpub] [Ext] .well-known and re-directs

 

The BR language states the well-known directory must be “on the Authorization 
Domain Name”.  Whether a re-direct is “on the Authorization Domain Name” is 
questionable.  If following redirects is permitted, the language should be 
updated accordingly. 

 

Jeremy

 

 

From: Jacob Hoffman-Andrews [mailto:j...@letsencrypt.org] 
Sent: Wednesday, July 19, 2017 2:54 PM
To: Paul Hoffman <paul.hoff...@icann.org <mailto:paul.hoff...@icann.org> >; 
CA/Browser Forum Public Discussion List <public@cabforum.org 
<mailto:public@cabforum.org> >
Cc: Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> >
Subject: Re: [cabfpub] [Ext] .well-known and re-directs

 

I disagree with Paul's interpretation. At Let's Encrypt we have always followed 
HTTP redirects, and consider it an important part of validating by HTTP. 
Consider, for instance, a web site that redirects all "http:" URLs to "https:" 
URLs. If that site were required to inhibit redirects for validation requests, 
that would be harmful to the site's security.

 

My interpretation is that RFC 5785 (Well-Known URIs) doesn't need to 
specifically mention redirects, any more than it needs to mention Host headers, 
status codes, or any of the other implementation details of HTTP. According to 
RFC 7231 <https://tools.ietf.org/html/rfc7231#section-6.4>  (HTTP Semantics and 
Content):

 

> The 3xx (Redirection) class of status code indicates that further
> action needs to be taken by the user agent in order to fulfill the
> request.  If a Location header field (Section 7.1.2 
> <https://tools.ietf.org/html/rfc7231#section-7.1.2> ) is provided, the
> user agent MAY automatically redirect its request to the URI
> referenced by the Location field value, even if the specific status
> code is not understood.
 

If it was the intent of RFC 5785 or the Baseline Requirements to rule out 
certain HTTP semantics, that would need to be made explicit. And I think an 
amendment ruling out redirects would be a mistake. For reference, here's the 
relevant BR text:


3.2.2.4.6 Agreed-Upon Change to Website


Confirming the Applicant’s control over the requested FQDN by confirming one of 
the following under the “/.well-known/pki-validation” directory, or another 
path registered with IANA for the purpose of Domain Validation, on the 
Authorization Domain Name that is accessible by the CA via HTTP/HTTPS over an 
Authorized Port:

1.  The presence of Required Website Content contained in the content of a 
file or on a web page in the form of a meta tag. The entire Required Website 
Content MUST NOT appear in the request used to retrieve the file or web page, or
2.  The presence of the Request Token or Request Value contained in the 
content of a file or on a webpage in the form of a meta tag where the Request 
Token or Random Value MUST NOT appear in the request.

If a Random Value is used, the CA or Delegated Third Party SHALL provide a 
Random Value unique to the certificate request and SHALL not use the Random 
Value after the longer of (i) 30 days or (ii) if the Applicant submitted the 
certificate request, the timeframe permitted for reuse of validated information 
relevant to the certificate (such as in Section 3.3.1 of these Guidelines or 
Section 11.14.3 of the EV Guidelines).



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

Re: [cabfpub] [Ext] .well-known and re-directs

[Jeremy Rowley via Public]

The BR language states the well-known directory must be “on the Authorization 
Domain Name”.  Whether a re-direct is “on the Authorization Domain Name” is 
questionable.  If following redirects is permitted, the language should be 
updated accordingly. 

 

Jeremy

 

 

From: Jacob Hoffman-Andrews [mailto:j...@letsencrypt.org] 
Sent: Wednesday, July 19, 2017 2:54 PM
To: Paul Hoffman ; CA/Browser Forum Public Discussion 
List 
Cc: Jeremy Rowley 
Subject: Re: [cabfpub] [Ext] .well-known and re-directs

 

I disagree with Paul's interpretation. At Let's Encrypt we have always followed 
HTTP redirects, and consider it an important part of validating by HTTP. 
Consider, for instance, a web site that redirects all "http:" URLs to "https:" 
URLs. If that site were required to inhibit redirects for validation requests, 
that would be harmful to the site's security.

 

My interpretation is that RFC 5785 (Well-Known URIs) doesn't need to 
specifically mention redirects, any more than it needs to mention Host headers, 
status codes, or any of the other implementation details of HTTP. According to 
RFC 7231   (HTTP Semantics and 
Content):

 

> The 3xx (Redirection) class of status code indicates that further
> action needs to be taken by the user agent in order to fulfill the
> request.  If a Location header field (Section 7.1.2 
>  ) is provided, the
> user agent MAY automatically redirect its request to the URI
> referenced by the Location field value, even if the specific status
> code is not understood.
 

If it was the intent of RFC 5785 or the Baseline Requirements to rule out 
certain HTTP semantics, that would need to be made explicit. And I think an 
amendment ruling out redirects would be a mistake. For reference, here's the 
relevant BR text:


3.2.2.4.6 Agreed-Upon Change to Website


Confirming the Applicant’s control over the requested FQDN by confirming one of 
the following under the “/.well-known/pki-validation” directory, or another 
path registered with IANA for the purpose of Domain Validation, on the 
Authorization Domain Name that is accessible by the CA via HTTP/HTTPS over an 
Authorized Port:

1.  The presence of Required Website Content contained in the content of a 
file or on a web page in the form of a meta tag. The entire Required Website 
Content MUST NOT appear in the request used to retrieve the file or web page, or
2.  The presence of the Request Token or Request Value contained in the 
content of a file or on a webpage in the form of a meta tag where the Request 
Token or Random Value MUST NOT appear in the request.

If a Random Value is used, the CA or Delegated Third Party SHALL provide a 
Random Value unique to the certificate request and SHALL not use the Random 
Value after the longer of (i) 30 days or (ii) if the Applicant submitted the 
certificate request, the timeframe permitted for reuse of validated information 
relevant to the certificate (such as in Section 3.3.1 of these Guidelines or 
Section 11.14.3 of the EV Guidelines).



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

[cabfpub] .well-known and re-directs

[Jeremy Rowley via Public]

We recently encountered a reoccurring scenario while using .well-known to
validate a certificate. The customer is trying to validate basedomain.com
using http://basedomain.com/.well-known/pki-validation/[page
 ]. However, the
server redirects this to
https://www.basedomain.com/.well-known.pki-valdiation/[page
 ]  Because
basedomain.com cannot be used to verify www.basedomain.com
 , the validation fails.  Is this the correct
result? Or is a returned random value through a re-direct sufficient to
verify the base domain? 



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

Re: [cabfpub] Revocation ballot

[Jeremy Rowley via Public]

Hi Geoff, 

I'm not sure I understand your post.  Are you commenting on the proposed 
changes or what's currently in the document?  From what I read, you'd like to 
see the 24 hour rule remain except in the limited circumstances described 
below? 


I do think these timeframes are a bit loose.  I wouldn’t like to see a CA 
explaining “well, we tried to contact the customer, and they haven’t replied, 
so we’re waiting the full fourteen business days” in response to being handed a 
copy of the private key.  Or if the actual domain owner appears and says “hey, 
you issued a certificate for my domain and I didn’t authorize it” and the CA 
then takes weeks to revoke.
[JR] Both of these events require revocation within 1 business day

However, I don’t think there’s so much of a problem in some specific cases:
- For item 1, the customer may voluntarily request a revocation at some time in 
the future.  The CA must still act on it within 24 hours of the requested time. 
 If the revocation is requested because of key compromise or change of 
information (and so is not voluntary, it is mandated by the Subscriber 
agreement), the following items control.
[JR] I don't see how this is allowed. The CA is required to revoke within 24 
hours under the current requirement and 1 business day under my proposal if the 
subscriber requests revocation. However, I like this exception as the 
subscriber can plan a specific time and date for revocation.  

- If the private key has been compromised, and the customer is contacted within 
2 business days and accepts the risk, the subscriber may delay revocation for 
up to 1 week from the time the CA is first notified.  (This is item 3.)
[JR] The current timeline is 24 hours. I proposed 1 business day.  Are you 
saying that 2 business days is acceptable to Apple with a 1 week delay in 
revocation from the date of notice?

- If there is a material change to the certificate information other than the 
DNS name, such as the address, I think the revocation can be delayed for up to 
10 business days from the date the information changed, to allow a smooth 
changeover, if the customer requests it.  This only applies if the previous 
information was valid but has changed.  (This is item 8 or 10.)
[JR] Thanks. 10 business days is fine with me as well.

I think you want to word these like this.  Otherwise you can end up in a 
scenario where someone reports a key compromise to the customer, the customer 
is required by the Subscriber Agreement to report it immediately to the CA and 
request revocation, which is not a Problem Report, and it must be revoked 
within 24 hours; but if it had been reported to the CA, it could have taken up 
to 2 weeks.  And of course if the reporter sees it’s not revoked fast enough, 
the reporter can then go to the CA and say the subscriber is not following 
their Subscriber Agreement, which might have consequences far beyond one 
certificate.
[JR] Good point. 

For all other items, I don’t see why 24 hours is unreasonable for the actual 
revocation.  I think setting a deadline on any investigations caused by a 
problem report is also a good idea, and think 24 hours for initial response 
then 3 business days for final action is OK.
[JR] There are others.
a) Requiring revocation for non-payment seems counter-productive to the goal of 
making revocation a technical control, not a business control.  The CA is 
forced to revoke within 24 hours if payment is delayed by a couple days because 
of a violation of the subscriber agreement (#6).  
b) If I put in my CPS that I will revoke 14 days after receiving notice of a 
trademark being awarded to a third party (but not the domain name), then you 
could argue that the CA actually only has 24 hours because revocation is 
required by the CPS (the timing in the CPS is irrelevant).  
c) Similarly, if technical content presents an unacceptable risk, does the 
timeline set for deprecation really control or does the 24 hour rule in this 
section control? It should require revocation in accordance with the timeline 
established by the CAB Forum.
d) What does a fraudulently misleading sub-domain mean in the wildcard context? 
We have to revoke within 24 hours of being made aware that this circumstance. 
I'm not sure how that plays into the certificate problem report.  It 
effectively shortens the certificate problem report investigation and 
revocation period into a single 24 hour period. 

I really think each revocation reason needs its own timeline, even if some of 
them are duplicative.  24 hours seems reasonable for customer requested 
revocations and key compromise events. However, other revocations should be 
within a certain time after finishing the investigation (which should also be 
capped) or within the time frame specified by industry standards.  I'll draft a 
revision for additional discussion based on your comments and re-circulate. 

Thanks!



smime.p7s
Description: S/MIME cryptographic signature

Re: [cabfpub] Revocation ballot

[Jeremy Rowley via Public]

The proposal already includes maximum timeframes for revocation, with two weeks 
being the highest and 24 hours being the shortest, depending on the reason for 
revocation. Discretion is not built involved. I already agree that timely 
revocation should be required to prevent a bad acting CA from never revoking, 
but what timely means depends on the circumstances. 

-Original Message-
From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Monday, July 17, 2017 12:28 PM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Revocation ballot

On Mon, Jul 17, 2017 at 12:46 PM, Jeremy Rowley  
wrote:
> I don't think we get to make that false equivalency, certainly not with how 
> the certificates work.
> [JR] This is probably the crux of the discussion.  Why do you feel this is a 
> false equivalency? It's a vulnerability associated with the product shipped 
> by an entity. The CA, as the service provider, seems obligated to help 
> remediate it.

I think it's clear you're seeing it as a product - I'm sure, in part, informed 
by some of your customers directly baking the certs and keys in. But from the 
point of view of a browser, or a relying party (e.g.
browser user), it's a break of the fundamental assurance of TLS in the Web PKI 
- that only the intended party can receive the communication.

The view of "exploited" doesn't align with, for example, a non-forward-secure 
ciphersuite negotiated with the key. In those cases, it may be 'exploited' 
retroactively - and so because of this, it's logical to stay it was exploited 
from the moment the key was known to be compromised. Even if the server was 
using solely forward-secure algorithms, without a form of binding the 
individual channel (which does not work on the Internet at large for a variety 
of reasons, including a number of members' security products), then you can't 
show that the connection _wasn't_ exploited.

Because this is about the communication channel itself, and the assurances, the 
idea of applying an exploit-oriented mindset doesn't hold up with how it works.

> a) If an online transaction was performed, and it was disputed and not 
> reversed, then DigiCert is liable
> b) If something else was performed - for example, the act of signing 
> in - DigiCert is disclaiming liability [JR] If we updated our relying party 
> agreement and removed disclaimers on liability, you'd be happy with the 
> modification?

I noted in the original message, although further below, this is not something 
that can, from a technical or legal perspective, be addressed by 'increased 
liability'.

> I think we're in agreement that, given the nature of the ecosystem, the 
> target state to be moving towards is to enable and allow the prompt and 
> timely rotation of keys, for both emergency and non-emergency situations, 
> correct?
> [JR] Yes. We are in agreement that this is one of the goals, but I think we 
> disagree on whether giving certificate holder's time to remediate an issue is 
> also a goal.

As you note, there are circumstances where no such remediation time is needed. 
As such, we'd rather see the system optimized for that - the scenario of rapid 
transition - because it ensures it will work robustly for all situations. The 
bifurcation of these is what creates risks - because neither browsers nor 
relying parties would have the necessary technical assurance or remedy that the 
situation was appropriately triaged.

> How do you propose to discover active exploitation? The math is 
> indistinguishable to all participants but the Subscriber, and even then, it's 
> questionable.
> [JR] Only for publicly disclosed compromised keys. There are many other 
> reasons for revocation under the BRs.

So if a Subscriber violates a Subscriber Agreement, your view is that the CA 
should be allowed to use its discretion to not revoke?
If a CA issues a certificate to a non-existent legal entity, your view is that 
the CA should be allowed to use its discretion to revoke?

There is no incentive structure for timely revocation. That discretion, however 
powerful, has zero incentive structure for timely action, and the original 
proposal would have allowed for this to continue indefinitely.

To be fair, if this is a view we want to go down - that the only thing you can 
rely on in a certificate is that the domain name is bound to the key - I'm 
fully supportive of this. However, to mitigate the risk and confusion to the 
market, that would naturally have to come with a prohibition on including any 
additional information beyond the domain in the certificate - since that would 
be untrustworthy information that subscribes and relying parties have come to 
rely upon. It will no doubt take several decades of active engagement for CAs 
to retrain users not to expect this information to be trustworthy, so the only 
viable solution until that retraining has 

Re: [cabfpub] Revocation ballot

[Jeremy Rowley via Public]

While perhaps not true in all cases, I think key compromise situations should 
be handled similar to all other software security vulnerabilities. Because they 
are vulnerabilities, we should react like other reported issues.  We should 
learn from the work and lessons of other responsible disclosure practices 
(Project Zero is a great example). I doubt you're in the camp that claims all 
vulnerabilities should be promptly disclosed without a correction period, so I 
think we can find some common ground on how certificate vulnerability and key 
compromise reporting should happen. The remediation window is a vital part of 
responsible disclosure; it's not merely a nice gesture, but represents the 
opportunity to work with information security and software development 
colleagues to remediate vulnerabilities in a way that minimally impacts users 
(i.e. attempts to reduce the potential harm that could be caused by the 
vulnerability to the greatest extent possible, while balancing the time 
constraints caused by an awareness that if one responsible party discovered the 
issue, it's only a matter of time before another, potentially less responsible, 
party does likewise). 

Of course, waiting on disclosure or revocation doesn't remove the 
vulnerability. However, using responsible disclosure does give developers and 
IT teams time to properly assess the scope of the issue, update their systems, 
and deploy fixes before the knowledge is wide-spread. I agree with prompt 
revocation, but what constitutes "timely and promptly" is subjective and 
depends heavily on context and severity.  For non-emergency situations (a 
vulnerability or compromise is discovered, but no evidence is found of active 
exploitation and the discovery occurred in such a way that repeat discovery is 
unlikely to be imminent), 24 hours seems too short to advise on a 
restructuring, deploy new certificates, and update systems. For emergency 
situations (a vulnerability is discovered to be undergoing active exploitation 
or is publicly available to an extend that re-discovery and exploitation is 
inevitable), 24 hours is probably too long.  My proposal is we bifurcate the 
timelines based on the reason for revocation and impact.  A company that 
changes address and fails to update their certificate within 24 hours is in a 
different risk category than someone who publishes the key pair used on their 
shopping site to Github.  I think we're in violent agreement that automation is 
essential within the industry, and that is a key recommendation we always make. 
Unfortunately, automation isn't available on every device, nor does every 
entity deploying digital certificates automate for all situations. Generally, 
if the device operator is disclosing their private key on a public repository 
like Github, they likely did not plan on addressing a revocation massively 
affecting their devices.  

Every company has "perverse" incentives to help their customers.  Google has 
its own perverse incentives to keep users on its search engine and browser. 
Somehow, despite these perverse incentives, we all seem to work towards 
Internet security in our own fashion. Ours is helping entities (customers and 
non-customers alike) configure PKI related systems, deploy certificates, and 
remediate messes, e.g. those caused by reusing private keys on hardware devices 
sent to all of their users.

For example, let's say we have a popular program that has 10 million downloads. 
Unfortunately, they deployed the same private key in every download (note that 
this was not our recommendation; at this point, they haven't contacted us for 
recommendations on best practices for key management and protection, etc.). We 
receive notice at 1 am on a Saturday. Although we maintain a constantly 
monitored certificate problem reporting process, the supplier does not. 
Although we immediately spam every email we have, including their emergency 
numbers, there's no way they can get someone technical on the phone prior to 1 
am Sunday.  The net effect is that on Sunday at 1 am, each user is potentially 
blocked from their app. That doesn't help relying parties at all.  Instead, if 
we received responsible disclosure of the issue, but could wait for a week 
before revoking, the company could push out an emergency update deploying 
unique certificates to each device (or re-work how their app communicates 
internally so that local private keys aren't needed at all; yes, that's what 
we'd recommend in plenty of cases because we actually do care about what’s best 
for users) eliminating the shut down. Luckily for us, so far, the revocations 
have not had quite that widespread of detrimental effects.

Seems like there should be a balance we can strike between the need for prompt 
revocation and the desire not to impact relying parties while still encouraging 
certificate use.  I proposed two weeks based on the reason for revocation, but 
I'm certainly open to other suggestions. Maybe 

Re: [cabfpub] Revocation ballot

[Jeremy Rowley via Public]

Why tell the CA that their Subscriber was compromised, rather than the 
Subscriber themselves? Alternatively, if the Subscriber _is_ compromised, then 
it's absolutely the correct incentive for the researcher to report this 
directly to the CA, so that Relying Parties are not mislead, regardless of 
what steps the Subscriber steps.

[JR] We often get involved directly with our customers on the certificate 
management and deployment-side. Thinking of the CA as only the certificate 
manufacture undervalues the services some CAs provide. Forcing CAs out of the 
advisory role and solely into the issuance role eliminates a lot of the value 
provided. Therefore, we would like to get involved early in the process with 
both the researchers and the Subscribers to advise on all PKI issues. 
Although subscribers have an obligation under the agreement to report 
certificate issues, we know this doesn't always happen. Take Heartbleed for 
example. We received minimal prior notification of the event. However, when 
the event was announced, we released a tool that detected certificate 
impacted.  With advanced notice, we can assist customers in navigating both 
industry and internal events.

> For non-public issues, I'd rather work with the customers earlier than wait 
> to be brought in until 24 hours before the revocation occurs.

Could you explain or provide an example of this? As the CA - a service 
provider role - naturally being brought in the end of a customer-impacting 
issue is the right way to handle it.
[JR] There's a consulting role involved as well as a certificate issuance 
role. Many of our customers approach us with questions on the use of PKI and 
best practices.  Heartbleed is an example. We'd like to remain a consultant in 
the framework.  Another consideration is the CA is easy for a researcher to 
contact and report issues to. We have dedicated emails and personnel who 
handle these issues.  For example, Hanno emailed me directly about compromised 
private keys. I have no problem with this. To my knowledge, he did not reach 
out to the subscribers themselves. I also have no problem with this.  As the 
CA, we generally are the ones helping our customers with the certificate 
needs, including helping them through the revocation process.

> Could we balance the issue to say within 24 hours of public disclosure or 
> within two weeks of receiving a certificate problem report where the CA 
> confirms that one of the reasons under Section 4?

When we past discussed this, my understanding of the conclusion was that the 
CA would be afforded up to two weeks to investigate the problem report (with 
the requirement additional details about why the delay occurred being made 
public), but that upon determining it met one of the revocation reasons, was 
obligated to make the timely revocation under 4.9.1.1/4.9.1.2.
[JR] What if the certificate was deployed to 1000+ servers? If the private key 
is not disclosed, but there is a need to revoke, giving them time to manage 
the revocation minimizes the impact on relying parties. I generally don't need 
two weeks to investigate the problem. What I need is two weeks to migrate the 
customer to a better practice, which is then followed by revocation.

If I understand your proposal, it would be that if a CA determines the 
Subscriber (or Subordinate CA) meets the requirements of 4.9.1.1, they could 
still delay for up to two weeks before revoking, is that correct?
[JR] Sort of - I propose 4.9.1.1(1) and 4.9.1.1(2) (and corresponding sections 
under 4.9.2.2) require revocation within 24 hours. In both cases, the customer 
requested revocation.  That really should be immediate. What I'm proposing is 
the CA could delay two weeks for things like a subscriber agreement breach or 
if certificate information changes (such as a change in address).

How does that benefit Relying Parties?
[JR] It prevents critical systems from being shut off before the server 
operator can migrate to a new certificate.  It's an attempt to balance risk of 
misuses (a non-public event is less risky) with the desire to keep all 
infrastructure secured. The result of revocation is usually a move to no 
encryption rather than some new encryption - especially if revocation was for 
something like a change in address.

Jeremy

-Original Message-
From: Ryan Sleevi [mailto:sle...@google.com]
Sent: Thursday, July 13, 2017 4:32 PM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Revocation ballot

On Thu, Jul 13, 2017 at 5:48 PM, Jeremy Rowley  
wrote:
> I thought the goal was to start heading to a responsible disclosure model 
> where the revocation timeline is a balance of public dissemination of 
> information compared to the need for certificate holders to remediate the 
> issue, actively engaging the CA early instead of waiting until revocation is 
> required.  Right now, there's 

Re: [cabfpub] Revocation ballot

[Jeremy Rowley via Public]

I thought the goal was to start heading to a responsible disclosure model where 
the revocation timeline is a balance of public dissemination of information 
compared to the need for certificate holders to remediate the issue, actively 
engaging the CA early instead of waiting until revocation is required.  Right 
now, there's a strong incentive not to tell the CA about compromise events 
because it starts the 24-hour window.  For non-public issues, I'd rather work 
with the customers earlier than wait to be brought in until 24 hours before the 
revocation occurs.
  
Could we balance the issue to say within 24 hours of public disclosure or 
within two weeks of receiving a certificate problem report where the CA 
confirms that one of the reasons under Section 4?  

-Original Message-
From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Thursday, July 13, 2017 1:37 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: CA/Browser Forum Public Discussion List <public@cabforum.org>
Subject: Re: [cabfpub] Revocation ballot

Hi Jeremy,

I think you may have misunderstood. That is, I think that at any point the CA 
determines any of the conditions on 4.9.1.1 or 4.9.1.2 are met, they should 
remain obligated to revoke within 24 hours. That includes the full list.

I think greater time for the investigation of a certificate problem report - 
which allows for ascertaining whether or not 4.9.1.1 or
4.9.1.2 have been met - is reasonable, because as it stands, CAs are obligated 
to err on the side of revocation (and assume 4.9.1.1/4.9.1.2 will be true) 
rather than not.

I don't think it's a positive step forward, however, to suggest that a CA may 
opt to _not_ revoke, or to delay revocation beyond 24 hours, once 4.9.1.1 or 
4.9.1.2 are met. I'm particularly troubled, for example, by the suggestion that 
the impact of revocation be considered
- as that's entirely a subjective, unquantifiable, and arguably unsupportable 
interpretation in general, and it creates a perverse incentives, as the 
incentives of both the CA and the subscriber are to 'not' revoke an 
illegitimate certificate, even if it causes substantial harm to the ecosystem 
or Relying Parties.

It's unclear, however, if it was your intent to do that. My understanding is 
that the goal was to provide additional time for a CA to investigate the facts 
surrounding a Certificate Problem Report, so that they can fully determine 
whether 4.9.1.1/4.9.1.2 are met - not to make it possible for a CA to 'never' 
have to revoke a certificate (which is a natural consequence, as presently 
worded).

On Thu, Jul 13, 2017 at 3:24 PM, Jeremy Rowley <jeremy.row...@digicert.com> 
wrote:
> Thanks Ryan - I missed that.  IMO, we should leave the cap at 1 business day 
> (or even 24 hours) for those two events.  If the subscriber is requesting 
> revocation, there's no reason to delay.
>
> I don't mind adding a two week cap for the rest of the reasons if that helps.
>
> -Original Message-
> From: Ryan Sleevi [mailto:sle...@google.com]
> Sent: Thursday, July 13, 2017 1:19 PM
> To: Jeremy Rowley <jeremy.row...@digicert.com>; CA/Browser Forum 
> Public Discussion List <public@cabforum.org>
> Subject: Re: [cabfpub] Revocation ballot
>
> Hi Jeremy,
>
> This seems rather problematic. I greatly appreciated DigiCert's past 
> consideration of this, which was to set the absolute upper bound at no 
> greater than two weeks.
>
> As proposed, this would effectively make 4.9.1.1 and 4.9.1.2 pointless, as it 
> leaves it fully up to CA discretion. As we've seen with the validation 
> methods' "any other method", CA discretion creates significant challenges for 
> relying parties and auditors to be assured of the integrity of the Web PKI 
> and of the technical and material factors weighing in.
>
> That is, I'm totally supportive of an approach that tries to balance
> 24 hours, but I think anything that allows for arbitrarily-determined 
> revocation, as proposed, would be a big step backwards for the security and 
> confidence in the PKI.
>
> On Thu, Jul 13, 2017 at 2:47 PM, Jeremy Rowley via Public 
> <public@cabforum.org> wrote:
>> Hi all,
>>
>>
>>
>> I took Ben’s previous ballot proposal for changing revocation 
>> timelines and combined it with the timelines previously proposed.
>> Basically, the timelines were established to still require CA 
>> responsiveness but balance with compromise notices that are received at 
>> weird hours or during holidays.
>>
>>
>>
>> Looking forward to your comments.
>>
>>
>>
>> Jeremy
>>
>>
>> ___
>> 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] Revocation ballot

[Jeremy Rowley via Public]

Thanks Ryan - I missed that.  IMO, we should leave the cap at 1 business day 
(or even 24 hours) for those two events.  If the subscriber is requesting 
revocation, there's no reason to delay. 

I don't mind adding a two week cap for the rest of the reasons if that helps.

-Original Message-
From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Thursday, July 13, 2017 1:19 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>; CA/Browser Forum Public 
Discussion List <public@cabforum.org>
Subject: Re: [cabfpub] Revocation ballot

Hi Jeremy,

This seems rather problematic. I greatly appreciated DigiCert's past 
consideration of this, which was to set the absolute upper bound at no greater 
than two weeks.

As proposed, this would effectively make 4.9.1.1 and 4.9.1.2 pointless, as it 
leaves it fully up to CA discretion. As we've seen with the validation methods' 
"any other method", CA discretion creates significant challenges for relying 
parties and auditors to be assured of the integrity of the Web PKI and of the 
technical and material factors weighing in.

That is, I'm totally supportive of an approach that tries to balance
24 hours, but I think anything that allows for arbitrarily-determined 
revocation, as proposed, would be a big step backwards for the security and 
confidence in the PKI.

On Thu, Jul 13, 2017 at 2:47 PM, Jeremy Rowley via Public <public@cabforum.org> 
wrote:
> Hi all,
>
>
>
> I took Ben’s previous ballot proposal for changing revocation 
> timelines and combined it with the timelines previously proposed.  
> Basically, the timelines were established to still require CA 
> responsiveness but balance with compromise notices that are received at weird 
> hours or during holidays.
>
>
>
> Looking forward to your comments.
>
>
>
> Jeremy
>
>
> ___
> 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] Profiling OCSP & CRLs

[Jeremy Rowley via Public]

"Infrequently used" was a poor choice of words on my part.  We agree with you 
that OCSP stapling should and can be used for all certs (and didn't mean to 
imply otherwise).  Instead, I meant that most of these devices are not 
frequently connected to the Internet.  Some of them connect periodically, 
distributing out-of-date OCSP responses when OCSP stapling is used.  More than 
anything against OCSP stapling, I was thinking that it seems like a waste of 
resources to pre-sign OCSP responses for each device when the devices 
themselves only rarely call back to us for the a stapled response.  

-Original Message-
From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Monday, July 10, 2017 3:18 PM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Profiling OCSP & CRLs

I suppose one challenge I have with "infrequently used" is that it effectively 
states that CAs do not believe that OCSP Stapling should/can be used for all 
certificates. That is, I think one vision of the future would be to say all 
sites support OCSP stapling, and all (Web PKI) clients request OCSP stapling, 
because that gets us to a world where we have security by default (stapling as 
the default, not the exception, with hard fail on its absence or revocation).

So I think it may be necessary to start thinking about designs that move away 
from 'infrequently used' certs, and look to providing OCSP responses for all 
certs, and since ideally all servers will staple, to just pre-generate. I think 
you're right in that it most likely involves a move to FIPS 140-2 Level 2 
hardware (at least, under today's available systems), so that we can get the 
necessary volume of signatures, but I think pre-generation may be something 
that CAs really need to start thinking about and planning for now, so we can 
figure out how to make this real in five years and finally have the revocation 
system everyone says they want.

Anyways, agreed, "future wish list" - and I think that's one of the things that 
may require folks to think more about and figure out what that vision looks 
like.

On Mon, Jul 10, 2017 at 5:08 PM, Jeremy Rowley  
wrote:
> More of "it would be nice" for OCSP responder certs.  Right now, we run all 
> OCSP through our CA hardware.  Yes - your summary is exactly what I was 
> thinking. We can roll responder certs pretty easily but the signing limit is 
> often hardware-based. Moving to Level 2 hardware gives us more flexibility 
> for large volume, infrequently used certs where OCSP pre-signing doesn't make 
> sense.  Regardless, it's on a future wish list rather than something urgent.
>
> -Original Message-
> From: Ryan Sleevi [mailto:sle...@google.com]
> Sent: Monday, July 10, 2017 3:01 PM
> To: Jeremy Rowley 
> Cc: CA/Browser Forum Public Discussion List 
> Subject: Re: [cabfpub] Profiling OCSP & CRLs
>
> I'm not sure - are you suggesting that the BRs (and/or NetSec
> guidelines) allow for that? Or is that more a "Would be nice"?
>
> For the incremental improvement of a normative profile, I'd rather keep the 
> status quo - which I believe already requires the hardware key protection at 
> Level 3 in Section 6.2.7 (but am curious to know if/how CAs have interpreted 
> it otherwise, given the risks).
>
> That said, if we're talking about future system design, I think going to 
> Level 2 does seem reasonable, but will be tricky to work out. As covered in 
> past discussions, we'd still want to see the overall system treated as a High 
> Security target - that is, it should have all the same design and protections 
> around issuance. The preproduction requirement was meant to address this, but 
> to address concerns from some CAs that have a large number of IOT 
> certificates, they wanted to have online responders - which means issuance 
> systems connected to the Internet, which means a much greater risk, HSM or 
> not. I suspect we'd want to see a validity period of something like 14 days 
> (twice that of the maximum permissible OCSP response) - is that what you were 
> thinking?
>
>
> On Mon, Jul 10, 2017 at 4:47 PM, Jeremy Rowley  
> wrote:
>> A shorter validity period for responders isn’t painful, but could we 
>> have a looser interpretation on hardware?  What if delegated 
>> responder certs were stored in FIPS 140-2 Level 2 if they were short periods?
>>
>>
>>
>> From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan 
>> Sleevi via Public
>> Sent: Monday, July 10, 2017 11:48 AM
>> To: public@cabforum.org
>> Subject: Re: [cabfpub] Profiling OCSP & CRLs
>>
>>
>>
>> Based on the public discussion, here on the list and on the GitHub, 
>> and the private discussions, both off-list and at the CA/Browser 
>> Forum F2F in Berlin, I've attempted to update the draft to reflect the 
>> discussions.
>>
>>
>>
>> To review 

Re: [cabfpub] Profiling OCSP & CRLs

[Jeremy Rowley via Public]

More of "it would be nice" for OCSP responder certs.  Right now, we run all 
OCSP through our CA hardware.  Yes - your summary is exactly what I was 
thinking. We can roll responder certs pretty easily but the signing limit is 
often hardware-based. Moving to Level 2 hardware gives us more flexibility for 
large volume, infrequently used certs where OCSP pre-signing doesn't make 
sense.  Regardless, it's on a future wish list rather than something urgent. 

-Original Message-
From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Monday, July 10, 2017 3:01 PM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Profiling OCSP & CRLs

I'm not sure - are you suggesting that the BRs (and/or NetSec
guidelines) allow for that? Or is that more a "Would be nice"?

For the incremental improvement of a normative profile, I'd rather keep the 
status quo - which I believe already requires the hardware key protection at 
Level 3 in Section 6.2.7 (but am curious to know if/how CAs have interpreted it 
otherwise, given the risks).

That said, if we're talking about future system design, I think going to Level 
2 does seem reasonable, but will be tricky to work out. As covered in past 
discussions, we'd still want to see the overall system treated as a High 
Security target - that is, it should have all the same design and protections 
around issuance. The preproduction requirement was meant to address this, but 
to address concerns from some CAs that have a large number of IOT certificates, 
they wanted to have online responders - which means issuance systems connected 
to the Internet, which means a much greater risk, HSM or not. I suspect we'd 
want to see a validity period of something like 14 days (twice that of the 
maximum permissible OCSP response) - is that what you were thinking?


On Mon, Jul 10, 2017 at 4:47 PM, Jeremy Rowley  
wrote:
> A shorter validity period for responders isn’t painful, but could we 
> have a looser interpretation on hardware?  What if delegated responder 
> certs were stored in FIPS 140-2 Level 2 if they were short periods?
>
>
>
> From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan 
> Sleevi via Public
> Sent: Monday, July 10, 2017 11:48 AM
> To: public@cabforum.org
> Subject: Re: [cabfpub] Profiling OCSP & CRLs
>
>
>
> Based on the public discussion, here on the list and on the GitHub, 
> and the private discussions, both off-list and at the CA/Browser Forum 
> F2F in Berlin, I've attempted to update the draft to reflect the discussions.
>
>
>
> To review the overall diff, with inline annotations, 
> https://github.com/sleevi/cabforum-docs/pull/2/files
>
>
>
> To review the difference of those discussions, you can compare with 
> https://github.com/sleevi/cabforum-docs/compare/03d4055ef2a08ad4bdecf9
> aab42440da080b244b...3171d339a9b5ca1e57b77c5175c6ea853f4cf24c
>
>
>
> Here's the summary form:
>
> - From the discussion related to a target of 30/31 days for Delegated 
> OCSP Responders, it is clear that some CAs strongly prefer 
> longer-lived responder certificates, largely due to the operational 
> challenges involved with offline issuance scenarios. To balance that, 
> based on the private discussions had with several CAs regarding their 
> infrastructure, I've attempted to capture this in 4.9.1.2. In short, 
> if a long-lived Delegated OCSP Responder is misused or compromised, 
> the revocation status of all issued certificates is called into 
> question, and since it's not possible to recover from this scenario 
> (such as within 30 days), the only mitigation identified is to fully 
> revoke the issuing CA certificate. This appears to be the standard 
> assumption for several CAs practicing these long-lived responders, and 
> hopefully aligns with their own operational security practices.
>
> - The response lifetime to a subordinate CA is dropped to 3 months 
> (from the existing, implied one year), based on the suggestion of Doug 
> Beattie.
>
> - To account for IOT scenarios raised by some members, the requirement 
> to pre-produce OCSP responses has been relaxed. If you're using a 
> Delegated OCSP Responder (which has a specific technical profile 
> associated with it), and its validity period is less than 31 days, CAs 
> are exempt from the MUST requirement. I'm curious how folks would feel 
> if this date was tightened further - perhaps to 15 days for the 
> Responder - to best balance the risk of an Internet-facing signing 
> system versus the benefit of not requiring a large number of 
> responses. Personally, given the HSMs currently or pending 
> availability, I still strongly believe that pre-producing and 
> distributing responses across-the-board is the best security architecture, 
> but I'm willing to see some of that phased in over time.
>
>
>
> From the discussion, there were some broader points discussed, and 
> from some of the 

Re: [cabfpub] Profiling OCSP & CRLs

[Jeremy Rowley via Public]

A shorter validity period for responders isn’t painful, but could we have a 
looser interpretation on hardware?  What if delegated responder certs were 
stored in FIPS 140-2 Level 2 if they were short periods?  

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Monday, July 10, 2017 11:48 AM
To: public@cabforum.org
Subject: Re: [cabfpub] Profiling OCSP & CRLs

 

Based on the public discussion, here on the list and on the GitHub, and the 
private discussions, both off-list and at the CA/Browser Forum F2F in Berlin, 
I've attempted to update the draft to reflect the discussions.

 

To review the overall diff, with inline annotations, 
https://github.com/sleevi/cabforum-docs/pull/2/files

 

To review the difference of those discussions, you can compare with 
https://github.com/sleevi/cabforum-docs/compare/03d4055ef2a08ad4bdecf9aab42440da080b244b...3171d339a9b5ca1e57b77c5175c6ea853f4cf24c

 

Here's the summary form:

- From the discussion related to a target of 30/31 days for Delegated OCSP 
Responders, it is clear that some CAs strongly prefer longer-lived responder 
certificates, largely due to the operational challenges involved with offline 
issuance scenarios. To balance that, based on the private discussions had with 
several CAs regarding their infrastructure, I've attempted to capture this in 
4.9.1.2. In short, if a long-lived Delegated OCSP Responder is misused or 
compromised, the revocation status of all issued certificates is called into 
question, and since it's not possible to recover from this scenario (such as 
within 30 days), the only mitigation identified is to fully revoke the issuing 
CA certificate. This appears to be the standard assumption for several CAs 
practicing these long-lived responders, and hopefully aligns with their own 
operational security practices.

- The response lifetime to a subordinate CA is dropped to 3 months (from the 
existing, implied one year), based on the suggestion of Doug Beattie.

- To account for IOT scenarios raised by some members, the requirement to 
pre-produce OCSP responses has been relaxed. If you're using a Delegated OCSP 
Responder (which has a specific technical profile associated with it), and its 
validity period is less than 31 days, CAs are exempt from the MUST requirement. 
I'm curious how folks would feel if this date was tightened further - perhaps 
to 15 days for the Responder - to best balance the risk of an Internet-facing 
signing system versus the benefit of not requiring a large number of responses. 
Personally, given the HSMs currently or pending availability, I still strongly 
believe that pre-producing and distributing responses across-the-board is the 
best security architecture, but I'm willing to see some of that phased in over 
time.

 

>From the discussion, there were some broader points discussed, and from some 
>of the offline discussions, some rather surprising architecture disclosures, 
>so I'm curious on how best to express the following:

 

I had thought it clear that, under the current Baseline Requirements, all 
Delegated OCSP Responder Private Keys were subject to the same requirements as 
"CA Private Key" - that is, Sections 5.2, 6.1.1.1, and 6.2 absolutely applied. 
Some CAs indicated that they did not share that interpretation - for example, 
that it was acceptable to deploy the CA private key directly to their CDN 
partners, or it was acceptable to maintain a copy of the private key on the 
disk of the OCSP responder system. I'm curious, more broadly, if the Forum 
members share that interpretation or have reason to believe it's a desirable 
property, and if not, where might be appropriate to best clarify this.



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

[cabfpub] Ballot 192 - Notary revision

[Jeremy Rowley via Public]

>From the validation WG:

 

Ballot 192 - Notary Revisions

The following motion has been proposed by Jeremy Rowley of DigiCert and
endorsed by Kirk Hall of Entrust and Rich Smith of Comodo.

Currently, section 11.11.1(A)(ii) states,

 

11.11.1.   Verified Legal Opinion  

(1)  Verification Requirements:  Before relying on a legal opinion
submitted to the CA, the CA MUST verify that such legal opinion meets the
following requirements:

(A)  Status of Author:  The CA MUST verify that the legal opinion is
authored by an independent legal practitioner retained by and representing
the Applicant (or an in-house legal practitioner employed by the Applicant)
(Legal Practitioner) who is either:

.

(ii)  A notary that is a member of the International Union of Latin
Notaries, and is licensed to practice in the country of the Applicant's
Jurisdiction of Incorporation or Registration or any jurisdiction where the
Applicant maintains an office or physical facility (and that such
jurisdiction recognizes the role of the Latin Notary);

 

The EV Guidelines already define "Latin Notary" appropriately and
sufficiently as "A person with legal training whose commission under
applicable law not only includes authority to authenticate the execution of
a signature on a document but also responsibility for the correctness and
content of the document. A Latin Notary is sometimes referred to as a Civil
Law Notary."

 

Whether a Latin Notary (or Civil Law Notary) is a member of the IULN should
not be dispositive as to whether the person is competent and qualified to
provide a legal opinion.  The current wording of section 11.11.1(A)(ii)
means we cannot accept letters from proper Latin Notaries (individuals) who
aren't members of the IULN. 

 

By deleting the requirement that a Latin Notary be a member of the
International Union of Latin Notaries, this ballot permits a more extensive
view on who can provide the type of legal opinion required by the EV
Guidelines.

 

--MOTION BEGINS--

 

  A. Effective immediately, modify 11.11.1(A) as follows:

 

'''11.11.1. Verified Legal Opinion'''

 

(1) '''Verification Requirements''': Before relying on a legal opinion
submitted to the CA, the CA MUST verify that such legal opinion meets the
following requirements:

 

(A) '''Status of Author''': The CA MUST verify that the legal opinion is
authored by an independent legal practitioner retained by and representing
the Applicant (or an in-house legal practitioner employed by the Applicant)
(Legal Practitioner) who is either: 

 

(i) A lawyer (or solicitor, barrister, advocate, or equivalent) licensed to
practice law in the country of the Applicant's Jurisdiction of Incorporation
or Registration or any jurisdiction where the Applicant maintains an office
or physical facility, or

 

(ii) A notary that is a member of the International Union of Latin Notaries,
and is Latin Notary who is currently commissioned or licensed to practice in
the country of the Applicant's Jurisdiction of Incorporation or Registration
or any jurisdiction where the Applicant maintains an office or physical
facility (and that jurisdiction recognizes the role of the Latin Notary);

 

--MOTION ENDS-

 

The procedure for approval of this ballot is as follows: 


BALLOT 192 

Start time (22:00 UTC) 

End time (22:00 UTC) 


Discussion (7 to 14 days) 

15th June

21st June


Vote for approval (7 days) 

21st June

28th June



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. 

 

 



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

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

[Jeremy Rowley via Public]

In addition to the concerns raised by Peter, additional issues with the Network 
Security Guidelines are:

 

1.  They haven’t been updated in a long time, nor are they currently being 
updated. 
2.  There are better audit regimes for network security. If there are 
particular items that apply to only CAs, we should take those and incorporate 
them into the Baseline Requirements while moving the more general framework to 
a group with better expertise. 
3.  Zones are oddly defined and inconsistent

 

 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Peter Bowen via 
Public
Sent: Sunday, June 11, 2017 10:01 PM
To: CA/Browser Forum Public Discussion List 
Cc: Peter Bowen 
Subject: Re: [cabfpub] Send us you list of current problems with the Network 
Security Guidelines

 

Below are a few things I’ve seen.  I’m happy to put my name to them, so I’m 
posting to the public list:

 

1) Offline CAs are treated the same as online CAs.  For example, a system for 
CA that is based on HSMs stored in safes theoretically needs individual user 
logins with multi-factor access control.  For systems where the HSMs has multi 
person access control, this is highly redundant.

 

2) Root CAs are not required to be air gapped at all times.

 

3) The scope is far larger than probably intended — it could be viewed as being 
as far reaching as including CDNs used to distribute CRLs and OCSP responses 
which have no ability to generate or modify the responses and systems the relay 
emails to domain contacts which are outside of the CA system

 

4) The segmentation requirements are confusing (and possibly contradictory): 
networks or zones based on their functional, logical, and physical (including 
location) relationship

 

5) It assumes passwords are the core authentication credential and does not 
align with current NIST guidance.  Authentication requirements could probably 
be put in terms of NIST SP 800-63 AAL.

 

6) It fails to define “multi-factor authentication”

 

7) It fails to define “remote” (used as part of “remote administration or 
access”); Is remote anything other then using a keyboard and monitor physically 
attached to the system motherboard?

 

8) Certificate Management System and Security Support System definitions are 
both very broad.  At least one interpretation prevents usage of any system 
accessible to persons who are not in Trusted Roles, even if such usage is not 
critical to system security. For example, the CA might have a corporate policy 
to send logs to a central log server in addition to CA specific log servers.  
It is not clear this is allowed.

 

9) It has no concept of compensating controls; for example, a CA might want to 
implement channel authentication as an alternative to physical network 
segmentation (for example using TLS over VLANs rather than physically 
segmenting LANs).

 

The list goes on, but this should be a good start.

 

Thanks,

Peter

 

On Jun 9, 2017, at 2:29 PM, Kirk Hall via Public  > wrote:

 

Yes, we have also noticed “90 days” versus quarterly – Most quarters have more 
than 90 days.

 

Thanks.

 

From: Dean Coclin [  
mailto:dean_coc...@symantec.com] 
Sent: Friday, June 9, 2017 2:09 PM
To: CA/Browser Forum Public Discussion List <  
public@cabforum.org>
Cc: Kirk Hall <  
kirk.h...@entrustdatacard.com>
Subject: [EXTERNAL]Re: [cabfpub] Send us you list of current problems with the 
Network Security Guidelines

 

One specific complaint from the auditors I believe was the specific time 
requirements in the document. For example, if it said you have to change the 
password at 90 days, and you did it on day 91, it would be an audit failure. I 
think Don has better examples but that's one I recall. 

Sent from my iPhone


On Jun 9, 2017, at 4:35 PM, Kirk Hall via Public <  
public@cabforum.org> wrote:

Bruce and I want to collect a preliminary list of current problems with the 
Network Security Guidelines (technically, the Network and Certificate System 
Security Requirements), so we can have a good discussion of possible new 
directions at the upcoming F2F.

 

To that end – please send Bruce and me a list of the specific requirements 
(and/or definitions) in the NetSec requirements that you think are most 
problematic and which should be changed or dropped.  If possible, give us the 
following data for each problematic issue:

 

1.   Section or definition of the NetSec Requirements that creates the 
problem

2.   What is the problem?

3.   What is a possible solution (drop, amend, supplement), with suggested 
language.

 

Bruce and I will combine all suggestions received and report anonymously to the 
whole group for a discussion in Berlin.  That may give the new Working Group 
some useful guidance for 

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

[Jeremy Rowley via Public]

The audits are more deficient than just the minimum number. If a CA issues a
million certs to one customer, the entire 3% audit will be that single
customer. If that system is automated, all other customers and systems are
effectively masked.  I haven't figured out to expand the audit requirement
though. Perhaps a minimum that is something along the lines of the greater
of 3% of certificates with a unique profile and five cert? An alternative is
3% of certificates with a unique base domain?

-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase
Markham via Public
Sent: Tuesday, June 6, 2017 4:47 AM
To: CABFPub 
Cc: Gervase Markham 
Subject: [cabfpub] Changing numbers of self-audited certificates

Currently, the BRs define, in section 8.7, the parameters for self-audits
and audits of certificates below a TCSC. At the moment, the number of certs
randomly chosen to be audited is defined as "the greater of one certificate
or at least three percent of the Certificates issued".

I think that auditing just a single certificate (which is currently OK up
until 33 are issued) makes it too easy to overlook problems when volumes are
small. I propose instead a 5-certificate minimum, or 3%, whichever is
larger. In other words:

Issued Audited
0  0
1  1
.
5  5
6  5
.
1665
1676
.

We could just change the "one" to a "five" if people thought it was obvious
that if you've issued less than five, you just audit all of them. Or we
could expand the text a bit to explicitly describe that.

I would be interested in feedback on the impact of this change. It's been
proposed for the Mozilla policy but as it's a BR stipulation I thought we
should try here first.

Gerv
___
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] Fairly Urgent: Draft Network Security Working Group charter ballot

[Jeremy Rowley via Public]

We will endorse 

> On Jun 3, 2017, at 3:16 PM, Dean Coclin via Public  
> wrote:
> 
> To be clear, I wasn’t suggesting a delay, rather, something that would be 
> done in parallel. But your call, either way is fine with me.
> 
> -Original Message-
> From: Gervase Markham [mailto:g...@mozilla.org] 
> Sent: Saturday, June 3, 2017 5:12 PM
> To: Dean Coclin ; CA/Browser Forum Public 
> Discussion List 
> Subject: Re: [cabfpub] Fairly Urgent: Draft Network Security Working Group 
> charter ballot
> 
>> On 03/06/17 21:59, Dean Coclin wrote:
>> Very good Gerv. It might also be useful to get a show of hands as to who 
>> would participate in this WG as it wouldn't make sense to form it if we 
>> don't get enough participants. My sense from the last F2F is that we will, 
>> but perhaps a poll would give the group a better indication as to who would 
>> actually be involved in researching and drafting. Of course, this is not 
>> required to form the group. Involvement of Interested Parties with domain 
>> expertise would be especially beneficial.
> 
> I think we should pass the ballot, form the group, and if it turns out no-one 
> wants to join it I'll join, elect myself as chair, and close it down again.
> 
> Let's not delay this with more straw polling. The best way this group can get 
> off to a good start is having a face-to-face meeting in Berlin, and for that 
> to happen, the ballot needs to start the process on Monday.
> 
> Gerv
> ___
> 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] Preballot - Revised Ballot 190

[Jeremy Rowley via Public]

Okay – but even if A-C is required, why is pre-validation not allowed under 
your interpretation?

 

A) A request from, or on behalf of, the Applicant for the issuance of a 
certificate

- Applicant signs a contract, submits a domain name where they want a cert, but 
doesn’t give a date when the cert will issue.

B) A certification by, or on behalf of, the Applicant that all of the 
information contained therein [in the request] is correct

- Applicant certifies that all the information is correct. However, information 
can be added after, such as the date when the cert will issue.

C) At least one Fully-Qualified Domain Name or IP address to be included in the 
Certificate's SubjectAltName extension

- Already submitted as part of the request.

 

 

 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Saturday, May 20, 2017 8:52 AM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Preballot - Revised Ballot 190

 

 

On Sat, May 20, 2017 at 10:41 AM, Ryan Sleevi  > wrote:

 

 

On Fri, May 19, 2017 at 9:47 PM, Jeremy Rowley  > wrote:

“The certificate request MAY include all factual information about the 
Applicant to be included in the Certificate, and such additional information as 
is necessary for the CA to obtain from the Applicant in order to comply with 
these Requirements and the CA’s Certificate Policy and/or Certification 
Practice Statement.”

*   This indicates a certificate request may include partial information.

I appreciate you mentioning this - as I've mentioned it several times - but 
this doesn't address the concern related to 4.1.2

 

Apologies, that sent too soon.

 

Let's look at 4.1.2 and 4.2.1 combined:

 

>From 4.2.1:

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.

 

>From 4.1.2

Prior to the issuance of a Certificate, the CA SHALL obtain the following 
documentation from the Applicant:

1. A certificate request, which may be electronic; and

2. An executed Subscriber Agreement or Terms of Use, which may be electronic.

 

The CA SHOULD obtain any additional documentation the CA determines necessary 
to meet these Requirements

 

Prior to the issuance of a Certificate, the CA SHALL obtain from the Applicant 
a certificate request in a form prescribed by the CA and that complies with 
these Requirements. One certificate request MAY suffice for multiple 
Certificates to be issued to the same Applicant, subject to the aging and 
updating requirement in Section 3.3.1, provided that each Certificate is 
supported by a valid, current certificate request signed by the appropriate 
Applicant Representative on behalf of the Applicant. The certificate request 
MAY be made, submitted and/or signed electronically. 

 

The certificate request MUST contain a request from, or on behalf of, the 
Applicant for the issuance of a Certificate, and a certification by, or on 
behalf of, the Applicant that all of the information contained therein is 
correct. 

 

 

>From these two, it's important to note what constitutes a request:

A) A request from, or on behalf of, the Applicant for the issuance of a 
certificate

B) A certification by, or on behalf of, the Applicant that all of the 
information contained therein [in the request] is correct

C) At least one Fully-Qualified Domain Name or IP address to be included in the 
Certificate's SubjectAltName extension

 

Are we at least in agreement that these three represent the _minimum_ necessary 
and sufficient conditions to constitute "A Request"?

 

Further, a Request MAY, but not necessarily, "include all factual information 
about the Applicant to be included in the Certificate". "In cases where the 
certificate request does not contain all the necessary information about the 
Applicant", the information requested by the Applicant is not part of the 
Request, and "the CA SHALL obtain the remaining information from the Applicant 
or, having obtained it from a 

Re: [cabfpub] Preballot - Revised Ballot 190

[Jeremy Rowley via Public]

“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.”

*   This indicates a certificate request may include partial information. 

 

“ 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.”

*   The CA can get additional information as necessary to support the 
issuance. The only information required is at least one FQDN. Provided one FQDN 
is provided, the rest of the information can be obtained by the CA after the 
initial request. Information obtained after the request may include the date to 
issue the certificate and additional FQDNs.

 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Friday, May 19, 2017 6:48 PM
To: Jeremy Rowley 
Cc: Ryan Sleevi ; CA/Browser Forum Public Discussion List 

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

 

 

 

On Fri, May 19, 2017 at 8:45 PM, Jeremy Rowley  > wrote:

A slightly different third interpretation:

- Obtaining a partial request (under 4.2.1, the certificate request does not 
contain all necessary information…)

 

How is the notion of "partial request" supported, in light of 4.1.2?

 

If we support the notion of "partial request", then what is the absolute 
minimum amount of information to distinguish that from "no request"?

 

I don't disagree we can come up with lots of words for those things, but I 
don't see how they're supported :)



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

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

[Jeremy Rowley via Public]

I agree that we don’t have a format. I was surprised that there was doubt on 
whether the wiki format was sufficient.  I used the wiki format specifically to 
avoid a rich text format. 

 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Friday, May 19, 2017 6:31 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: CA/Browser Forum Public Discussion List <public@cabforum.org>
Subject: Re: [cabfpub] Ballot 191 - Clarify Place of Business Information

 

To be clear: We did vote for it ;)

 

What constitutes a 'comparison showing the set of changes'? We don't really 
have a defined technical format, and we've continued to grow in the number and 
ways in which they're shared (PDFs, word documents, rich-text markup for 
e-mails, wiki forms)? Rich text e-mails are a really good example of a 
'questionable' idea, since you could have the rich text message (which some 
clients do not support) display things underline/strikethrough/colored, but 
then also provide a 'plain text' version (which is what our maillist archives 
for the public) that doesn't maintain that coloration.

 

On a more extreme basis, could a ballot simply say "See this link" and refer to 
a GitHub pull request? A pastebin dump? Are those links themselves comparisons, 
or are they links to comparison?

 

As far as process itself goes, I know it sounds like a silly semantic game, 
because 'surely' no one would submit a ballot for which the comparison could be 
made by 'deleting every word that ends in a vowel', but we're effectively 
introducing 'yet another way' to conduct a ballot. My hope and desire is that, 
regardless of bylaws, we'd at least pick some consistency and stick to it 
consistently =) For example, it was not until Ben's clarification, on May 18 - 
after several people had voted - that the nature and means of understanding 
that comparison was pointed out. Perhaps it was more obvious to our learned 
colleagues at Entrust, Izenpe, and Mozilla, but of course, until that 
clarification was provided, it was entirely suspect as to whether or not it was 
a legitimate ballot, and how to compare that text against the current EVGs :)

 

 

On Fri, May 19, 2017 at 8:19 PM, Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> > wrote:

Why wouldn’t the wiki version constitute a redlined version?

 

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


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

 

Thanks Bruce for providing this.

 

It's unclear to me, in light of the discussions around 198 - .onion domains - 
whether this constitutes a proper ballot, since a redline version was not 
provided.

 

That is, whether the --( )-- (deletion) __ __ (addition) constitute redlines or 
not. Assuming we accept it as such (expedience, courtesy, and no one has raised 
objections to this ballot yet), then I can confirm that Bruce's "redline" 
version is for the most part consistent with the EVG 1.6.2 and 1.6.3

 

I say "for the most part" because there's on the city and town line there's the 
text "EV Guidelines, v. 1.6.3 12", which is the result of a copy/paste issue 
from the source PDF (it's the footer of the PDF), and not part of the actual 
text :)

 

Since we have the redline version (from the original ballot, I think we can 
safely conclude the 'wiki markup' is "sufficient" redline, versus say PDF or 
word), and a visual version (Bruce's) to make sure it's correct, and it's based 
on the current EVGs (1.6.2 as last published, 1.6.3 is pending IP review)...

 

Google votes YES

 

On Thu, May 18, 2017 at 11:59 AM, Bruce Morton via Public <public@cabforum.org 
<mailto:public@cabforum.org> > wrote:

Here is a markup of BR section 9.2.7 for ballot 191.

 

Thanks, Bruce.

 

From: Public [mailto:public-boun...@cabforum.org 
<mailto:public-boun...@cabforum.org> ] On Behalf Of Ben Wilson via Public
Sent: Thursday, May 18, 2017 11:18 AM
To: CA/Browser Forum Public Discussion List <public@cabforum.org 
<mailto:public@cabforum.org> >
Cc: Ben Wilson <ben.wil...@digicert.com <mailto:ben.wil...@digicert.com> >
Subject: [EXTERNAL]Re: [cabfpub] Ballot 191 - Clarify Place of Business 
Information

 

Just a clarification for everyone, the text below was copied out of the wiki 
with wiki markup language, so the following text is being deleted --(City, 
State, and country – Required; Street and postal code - Optional)—(the open and 
close parentheses with dashes indicates a deletion).

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: 

Re: [cabfpub] Preballot - Revised Ballot 190

[Jeremy Rowley via Public]

A slightly different third interpretation:

- Obtaining a partial request (under 4.2.1, the certificate request does not 
contain all necessary information…) 

 - Obtaining validation documentation (under 3.2.2.4)

- Completing the certificate request (4.2.1)

- Looking back 825 days at documentation already obtained (per 4.2.1, the CA 
may use the documents…)

- Relying on the CA documentation of the verification to issue the cert.

 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Friday, May 19, 2017 6:14 PM
To: Peter Bowen 
Cc: Ryan Sleevi ; CA/Browser Forum Public Discussion List 

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

 

 

 

On Fri, May 19, 2017 at 7:52 PM, Peter Bowen  > wrote:

There is no reason a CA couldn’t pull public records based on info in CT to 
help expedite things (for example identifying the company registration number), 
but the validation still has to happen. You can’t finalize the validation 
without binding it to a legal entity who will be the applicant/subscriber.  It 
is possible that this validation could use records pulled by the CA prior to 
the request for validation.

 

And this goes back to the initial question you posed that kicked this all off, 
namely:

"I think some have suggested that the BRs don’t allow this alternative order of 
operations, but I’m having a little trouble finding the specific cite.  Do you, 
Ryan, or does anyone else, think the order of operations described above is not 
valid?"

 

To tie this all back together: Section 4.2.1 only permits the reuse of 
information gathered in context with Section 3.2:

"TheCA  MAY   use   thedocuments   and  data
 

provided  in Section3.2to 
verify   certificateinformation,provided  that  
  the   CA  obtained  thedata or 
document

froma  source  specified  underSection  
  3.2   nomorethan thirty‐nine   (39)   
 months priorto issuing the

Certificate."

 

Section 3.2 is tied to what the Applicant is requesting in the certificate:

 

So for there to be information to be reused, it needs to be obtained in the 
context of an Applicant. 

 

And so the question is whether or not there can be an Applicant prior to a 
Certificate Request.

 

Section 1.6.1 establishes the Applicant as: "Thenatural person or 
Legal   Entitythat  applies for   (or   seeks   
 renewal   of)   aCertificate. Once the   

Certificate   issues, the   Applicantis referred
   to asthe   Subscriber.  For  
  Certificates  issued  todevices,   the   

Applicantis the   entity   thatcontrols 
  or operatesthe   device  named in the 
   Certificate,  evenif  thedevice  is 

sendingthe   actual  certificaterequest.   "

 

I'm sure we can get into the game of debating whether 'applies for' is distinct 
from 'requests' (although I think that's not supported by the text itself, by 
virtue of the following sentence, but I'm sure we can misread it).

 

 

You asked if there was a reason to suggest the ordering must be different. My 
minimal suggestion was that the order must be:

 

- A Request, which includes the attestation of correctness (per 4.1.2)

- which establishes an Applicant (per 1.6.1)

- which then permits validation of the Applicant information (per 3.2)

- which can then be reused for subsequent Requests (per 4.2.1)

 

It would seem that you are advocating for an interpretation that establishes:

- An Applicant (by virtue of establishing an Applicant Representative - the 
party who has signed the Subscriber Agreement on behalf of the Applicant / 
acknowledges the TOU, per 1.6.1)

- which then permits validation of the Applicant information (per 3.2)

- Which then permits one or more Requests (per 4.1.2)

- Which then allows the validated information to be reused (per 4.2.1), or the 
reuse of a previously completed validation (per 3.2.2.4)

 

Is that a correct summary of the difference?



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

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

[Jeremy Rowley via Public]

Relevant text:

 

a.  A Draft Guideline Ballot will clearly indicate whether it is proposing 
a Final Guideline or a Final Maintenance Guideline.  If the Draft Guideline 
Ballot is proposing a Final Guideline, such ballot will include the full text 
of the Draft Guideline intended to become a Final Guideline.  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 Section 2.3(j) below.

 

The ballot included a “comparison showing the set of changes from the Final 
Guideline section(s) intended to become a Final Maintenance Guideline”.

 

From: Jeremy Rowley 
Sent: Friday, May 19, 2017 6:20 PM
To: 'CA/Browser Forum Public Discussion List' <public@cabforum.org>
Cc: Ryan Sleevi <sle...@google.com>
Subject: RE: [cabfpub] Ballot 191 - Clarify Place of Business Information

 

Why wouldn’t the wiki version constitute a redlined version?

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Friday, May 19, 2017 6:53 AM
To: CA/Browser Forum Public Discussion List <public@cabforum.org 
<mailto:public@cabforum.org> >
Cc: Ryan Sleevi <sle...@google.com <mailto:sle...@google.com> >
Subject: Re: [cabfpub] Ballot 191 - Clarify Place of Business Information

 

Thanks Bruce for providing this.

 

It's unclear to me, in light of the discussions around 198 - .onion domains - 
whether this constitutes a proper ballot, since a redline version was not 
provided.

 

That is, whether the --( )-- (deletion) __ __ (addition) constitute redlines or 
not. Assuming we accept it as such (expedience, courtesy, and no one has raised 
objections to this ballot yet), then I can confirm that Bruce's "redline" 
version is for the most part consistent with the EVG 1.6.2 and 1.6.3

 

I say "for the most part" because there's on the city and town line there's the 
text "EV Guidelines, v. 1.6.3 12", which is the result of a copy/paste issue 
from the source PDF (it's the footer of the PDF), and not part of the actual 
text :)

 

Since we have the redline version (from the original ballot, I think we can 
safely conclude the 'wiki markup' is "sufficient" redline, versus say PDF or 
word), and a visual version (Bruce's) to make sure it's correct, and it's based 
on the current EVGs (1.6.2 as last published, 1.6.3 is pending IP review)...

 

Google votes YES

 

On Thu, May 18, 2017 at 11:59 AM, Bruce Morton via Public <public@cabforum.org 
<mailto:public@cabforum.org> > wrote:

Here is a markup of BR section 9.2.7 for ballot 191.

 

Thanks, Bruce.

 

From: Public [mailto:public-boun...@cabforum.org 
<mailto:public-boun...@cabforum.org> ] On Behalf Of Ben Wilson via Public
Sent: Thursday, May 18, 2017 11:18 AM
To: CA/Browser Forum Public Discussion List <public@cabforum.org 
<mailto:public@cabforum.org> >
Cc: Ben Wilson <ben.wil...@digicert.com <mailto:ben.wil...@digicert.com> >
Subject: [EXTERNAL]Re: [cabfpub] Ballot 191 - Clarify Place of Business 
Information

 

Just a clarification for everyone, the text below was copied out of the wiki 
with wiki markup language, so the following text is being deleted --(City, 
State, and country – Required; Street and postal code - Optional)—(the open and 
close parentheses with dashes indicates a deletion).

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: Thursday, May 11, 2017 10:51 AM
To: CA/Browser Forum Public Discussion List <public@cabforum.org 
<mailto:public@cabforum.org> >
Cc: Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> >
Subject: Re: [cabfpub] Ballot 191 - Clarify Place of Business Information

 

Updated:

 

Ballot 191 - Clarify Place of Business Information Field Inclusion

The current EV Guidelines are not clear on what address information is required 
in a certificate. This ballot clarifies the requirements and harmonizes the EV 
Guidelines and Baseline Requirements.

The following motion has been proposed by Bruce Morton of Entrust and endorsed 
by Jeremy Rowley of DigiCert and Robin Alden of Comodo:

--Motion Begins--

A. Modify Section 9.2.7 of the EV Guidelines as follows:

9.2.7. Subject Physical Address of Place of Business Field

Certificate fields:

Number and street: subject:streetAddress (OID: 2.5.4.9)

City or town: subject:localityName (OID: 2.5.4.7)

State or province (where applicable): subject:stateOrProvinceName (

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

[Jeremy Rowley via Public]

Why wouldn’t the wiki version constitute a redlined version?

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Friday, May 19, 2017 6:53 AM
To: CA/Browser Forum Public Discussion List <public@cabforum.org>
Cc: Ryan Sleevi <sle...@google.com>
Subject: Re: [cabfpub] Ballot 191 - Clarify Place of Business Information

 

Thanks Bruce for providing this.

 

It's unclear to me, in light of the discussions around 198 - .onion domains - 
whether this constitutes a proper ballot, since a redline version was not 
provided.

 

That is, whether the --( )-- (deletion) __ __ (addition) constitute redlines or 
not. Assuming we accept it as such (expedience, courtesy, and no one has raised 
objections to this ballot yet), then I can confirm that Bruce's "redline" 
version is for the most part consistent with the EVG 1.6.2 and 1.6.3

 

I say "for the most part" because there's on the city and town line there's the 
text "EV Guidelines, v. 1.6.3 12", which is the result of a copy/paste issue 
from the source PDF (it's the footer of the PDF), and not part of the actual 
text :)

 

Since we have the redline version (from the original ballot, I think we can 
safely conclude the 'wiki markup' is "sufficient" redline, versus say PDF or 
word), and a visual version (Bruce's) to make sure it's correct, and it's based 
on the current EVGs (1.6.2 as last published, 1.6.3 is pending IP review)...

 

Google votes YES

 

On Thu, May 18, 2017 at 11:59 AM, Bruce Morton via Public <public@cabforum.org 
<mailto:public@cabforum.org> > wrote:

Here is a markup of BR section 9.2.7 for ballot 191.

 

Thanks, Bruce.

 

From: Public [mailto:public-boun...@cabforum.org 
<mailto:public-boun...@cabforum.org> ] On Behalf Of Ben Wilson via Public
Sent: Thursday, May 18, 2017 11:18 AM
To: CA/Browser Forum Public Discussion List <public@cabforum.org 
<mailto:public@cabforum.org> >
Cc: Ben Wilson <ben.wil...@digicert.com <mailto:ben.wil...@digicert.com> >
Subject: [EXTERNAL]Re: [cabfpub] Ballot 191 - Clarify Place of Business 
Information

 

Just a clarification for everyone, the text below was copied out of the wiki 
with wiki markup language, so the following text is being deleted --(City, 
State, and country – Required; Street and postal code - Optional)—(the open and 
close parentheses with dashes indicates a deletion).

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: Thursday, May 11, 2017 10:51 AM
To: CA/Browser Forum Public Discussion List <public@cabforum.org 
<mailto:public@cabforum.org> >
Cc: Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> >
Subject: Re: [cabfpub] Ballot 191 - Clarify Place of Business Information

 

Updated:

 

Ballot 191 - Clarify Place of Business Information Field Inclusion

The current EV Guidelines are not clear on what address information is required 
in a certificate. This ballot clarifies the requirements and harmonizes the EV 
Guidelines and Baseline Requirements.

The following motion has been proposed by Bruce Morton of Entrust and endorsed 
by Jeremy Rowley of DigiCert and Robin Alden of Comodo:

--Motion Begins--

A. Modify Section 9.2.7 of the EV Guidelines as follows:

9.2.7. Subject Physical Address of Place of Business Field

Certificate fields:

Number and street: subject:streetAddress (OID: 2.5.4.9)

City or town: subject:localityName (OID: 2.5.4.7)

State or province (where applicable): subject:stateOrProvinceName (OID: 2.5.4.8)

Country: subject:countryName (OID: 2.5.4.6)

Postal code: subject:postalCode (OID: 2.5.4.17)

Required/Optional: --(City, State, and country – Required; Street and postal 
code - Optional)--__As stated in Section 7.1.4.2.2 d, e, f, g and h of the 
Baseline Requirements__

Contents: This field MUST contain the address of the physical location of the 
Subject’s Place of Business.

--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 191 Status: Final Maintenance Guideline

Start time (22:00 UTC)

End time (22:00 UTC)


Discussion (7 to 14 days)

9 May 2017

16 May 2017


Vote for approval (7 days)

16 May 2017

23 May 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.

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 

Re: [cabfpub] Domain validation

[Jeremy Rowley via Public]

No, but it’s not a ballot. It’s just a discussion.

 

From: Kirk Hall [mailto:kirk.h...@entrustdatacard.com] 
Sent: Tuesday, May 16, 2017 1:45 PM
To: CA/Browser Forum Public Discussion List <public@cabforum.org>; Ryan Sleevi 
<sle...@google.com>
Cc: Jeremy Rowley <jeremy.row...@digicert.com>
Subject: RE: [cabfpub] Domain validation

 

Jeremy, was this ballot discussed in the Validation Working Group?

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Jeremy Rowley 
via Public
Sent: Tuesday, May 16, 2017 12:39 PM
To: Ryan Sleevi <sle...@google.com <mailto:sle...@google.com> >
Cc: Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> >; CA/Browser Forum Public Discussion List 
<public@cabforum.org <mailto:public@cabforum.org> >
Subject: [EXTERNAL]Re: [cabfpub] Domain validation

 

The original proposal actually utilized those sections and required checking 
WHOIS for changes within 90 days of issuance. I did want to discuss that during 
this process, but we can table that for the reuse portion.

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Tuesday, May 16, 2017 10:36 AM
To: Jeremy Rowley <jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> >
Cc: CA/Browser Forum Public Discussion List <public@cabforum.org 
<mailto:public@cabforum.org> >
Subject: Re: [cabfpub] Domain validation

 

 

 

On Tue, May 16, 2017 at 12:25 PM, Ryan Sleevi <sle...@google.com 
<mailto:sle...@google.com> > wrote:

So, first and foremost, it's unclear whether you're proposing this as a 'new' 
Ballot 190, or 'in addition to' Ballot 190. It's unclear if you're trying to 
break the problems out, or to solve the problems themselves.

 

I certainly am biased towards approaching this like most organizations approach 
code reviews - attempt to solve the smallest possible problem, provided it's 
solved comprehensively. This is why, for example, I broke out validation and 
reuse into separate draft ballots - because they are separable problems, even 
if closely related.

 

My understanding of your goals, although understandably limited here, is that 
something might be suited as:

 

- Ballot 190 [with whatever short-term fixes were accumulated since the passage 
of BRs 1.4.1]

- [Solve the language use issue - 'confirming control' vs 'validation' vs 
'authenticate']. This would be as a singular ballot, and seemingly is 
independent from these other issues.

- [Solve the random value language]. This too seems solely limited to Section 
2, so it doesn't seem to need to entail the other bits.

- [Solve the wildcard / subdomain issue]. This seems to be independent of any 
of the other aspects, but is also tricky and subtle enough to be worth its own 
discussion.

- [Solve the reuse issue]. Clearly, saving the 'contentious' for last, even if 
the simple goal is to clarify the reuse. As you know, there's a broader 
spectrum of issues at play here. We have the preamble in 3.2.2.4, we have the 
individual restrictions per method, and we even have requirements like those in 
4.1.2, that we want to make sure are entirely self-consistent.

 

That's just a thought, based on the understanding of the issues. It seems like 
each of these can be broken into separate ballots. They're potentially issues, 
but I don't know that trying to solve them 'all in one go' would be the best 
way to resolve them, considering they don't seem interdependent on eachother 
(that is, reuse is not tied to wildcard validation, AFAICT), and some may be 
either more subtle or thornier to sort out.

 

Regardless, _each_ of these would have to be reviewed in the full context of 
the BRs to make sure we don't end up with any conflicts from other sections 
(again, 4.1.2 is an example, as is 4.2.1 in a less-obvious manner but still 
potentially conflicting), and to figure out the best way to resolve those 
issues.

 

I'm not sure "reuse" should go in 3.2.2.4 at all, for example, but that's 
something we could discuss independent of any of the other perceived issues.

 

Oh, and one last piece of advice I offer when reviewing code :)

 

- Don't restructure your code for 'future feature X' until you know what the 
shape of 'future feature X' will look like. To me, that means avoid 
restructuring reuse 'so we can reduce it later' - unless/until we're ready to 
reduce the reuse period :) 



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

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

[Jeremy Rowley via Public]

A “redo” will fix that ballot. However, the underlying question on which 
controls will remain unresolved. 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ben Wilson via 
Public
Sent: Tuesday, May 16, 2017 1:44 PM
To: Ryan Sleevi ; CA/Browser Forum Public Discussion List 

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

 

I think the end goal is to have a version 1.6.3 of the EV Guidelines with the 
language indicated in the redlined version of Appendix F that I circulated a 
short while ago.  So I’d prefer that we find there was no ambiguity and that 
Kirk start the review period over with the correct language and we call that 
good, but of course the cleanest route would be that Ballot 198 be declared 
defective because of ambiguity and a new ballot be presented for a new vote.  
Fortunately this issue only affects the EV Guidelines, which doesn’t have any 
ballots in play, as far as I know. 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Tuesday, May 16, 2017 12:39 PM
To: CA/Browser Forum Public Discussion List  >
Cc: Ben Wilson  >
Subject: Re: [cabfpub] Revised Notice of Review Period - Ballot 198 - .Onion 
Revisions

 

As Ben has highlighted, the result of 198 created a new set of issues.

 

Kirk's original message includes the full text of the ballot (MOTION BEGINS), 
which, unfortunately, used text different from what was adopted in Ballot 144 
(and part of the current EVGs) when Jeremy made his modifications.

 

In examining 198 - https://cabforum.org/pipermail/public/2017-April/010706.html 
- it's clear in Jeremy's redlined versions (which, mistakenly, I reviewed as 
truth), the 'intent' was a small change. See 
https://cabforum.org/pipermail/public/attachments/20170424/80683ba2/attachment-0001.pdf

 

However, as Balloted, it requires a full replacement of the text adopted in 
144, in a way that's structurally incompatible with the ASN.1 encoding.

 

Worse, this is something that was discussed during the voting reform 
discussions - both situations where redlines and text differ (as in this case) 
and questions about redlining as 'source of truth'. We tried to address it as 
best as possible, but also somewhat punted the issue as unlikely :)

 

I think it's worth highlighting this concern broadly, because we have several 
possible interpretations:

 

1) The MOTION BEGINS/MOTION ENDS is authoritative (e.g. as Kirk has distributed)

  - In this case, we've now introduced a bug into the processing that is not 
easily undone.

  - Supporting Argument: This is how we've always done things.

  - Solution Suggestion: Hold a ballot immediately to try to fix this before 
the end of the IP review.

- Approach 1: Nullify the ballot? That is, to keep the version of the BRs 
the same.

- Approach 2: Direct the Chair not to publish any new versions of the BRs 
(thus triggering compliance for CAs) until the matter is resolved

- Approach 3: Introduce a new ballot with a new OID for the service 
descriptor that restores the 144 text

  - Implications:

- If folks don't vote on this, we're stuck in a bad place (effectively, no 
one should issue EV onion certs, because they'd post a compat/interop risk)

 

2) The redline text is authoritative (e.g. as Ben has distributed)

  - In this case, we're saying that the PDFs, not the ballot text, are what is 
authoritative.

  - This means you can no longer read ballots on our website "as is", but must 
ALSO view/post the supporting materials

  - Supporting Argument: The Bylaws seem to support this with respect to 
Section 2.3(a).

  - Solution Suggestion: Hold a ballot to agree on this interpretation for this 
specific ballot

  - Solution Suggestion p2: Hold a (same/different?) ballot to the bylaws 
clarify this for future ballots

  - Implications:

   - We should figure out what this means for future ballots if we go this 
route.

   - It also means our ballot postings to the website are probably incomplete

 

3) The ballot is invalid (due to the inconsistency)

  - In this case, we're saying the ballot is null because of the mismatch

  - Supporting Argument: The Bylaws in 2.3(a) indicate that a Draft Guideline 
Ballot proposing a Final Maintenance Guideline will include a redline or 
comparison, and that such redline or comparison be made against the Final 
Guideline section(s) as they exist at the time the ballot is proposed. Jeremy's 
redline was not against that section, ergo, was not a valid ballot.

  - Solution Suggestion: Hold a ballot to agree on this interpretation for this 
specific ballot

  - Solution Suggestion p2: Adopt it fixed

 

In short, I think we should probably resolve this with a ballot - which can be 
completed in two weeks. The IP Review Notice has been 

Re: [cabfpub] Domain validation

[Jeremy Rowley via Public]

The original proposal actually utilized those sections and required checking 
WHOIS for changes within 90 days of issuance. I did want to discuss that 
during this process, but we can table that for the reuse portion.



From: Ryan Sleevi [mailto:sle...@google.com]
Sent: Tuesday, May 16, 2017 10:36 AM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Domain validation







On Tue, May 16, 2017 at 12:25 PM, Ryan Sleevi  > wrote:

So, first and foremost, it's unclear whether you're proposing this as a 'new' 
Ballot 190, or 'in addition to' Ballot 190. It's unclear if you're trying to 
break the problems out, or to solve the problems themselves.



I certainly am biased towards approaching this like most organizations 
approach code reviews - attempt to solve the smallest possible problem, 
provided it's solved comprehensively. This is why, for example, I broke out 
validation and reuse into separate draft ballots - because they are separable 
problems, even if closely related.



My understanding of your goals, although understandably limited here, is that 
something might be suited as:



- Ballot 190 [with whatever short-term fixes were accumulated since the 
passage of BRs 1.4.1]

- [Solve the language use issue - 'confirming control' vs 'validation' vs 
'authenticate']. This would be as a singular ballot, and seemingly is 
independent from these other issues.

- [Solve the random value language]. This too seems solely limited to Section 
2, so it doesn't seem to need to entail the other bits.

- [Solve the wildcard / subdomain issue]. This seems to be independent of any 
of the other aspects, but is also tricky and subtle enough to be worth its own 
discussion.

- [Solve the reuse issue]. Clearly, saving the 'contentious' for last, even if 
the simple goal is to clarify the reuse. As you know, there's a broader 
spectrum of issues at play here. We have the preamble in 3.2.2.4, we have the 
individual restrictions per method, and we even have requirements like those 
in 4.1.2, that we want to make sure are entirely self-consistent.



That's just a thought, based on the understanding of the issues. It seems like 
each of these can be broken into separate ballots. They're potentially issues, 
but I don't know that trying to solve them 'all in one go' would be the best 
way to resolve them, considering they don't seem interdependent on eachother 
(that is, reuse is not tied to wildcard validation, AFAICT), and some may be 
either more subtle or thornier to sort out.



Regardless, _each_ of these would have to be reviewed in the full context of 
the BRs to make sure we don't end up with any conflicts from other sections 
(again, 4.1.2 is an example, as is 4.2.1 in a less-obvious manner but still 
potentially conflicting), and to figure out the best way to resolve those 
issues.



I'm not sure "reuse" should go in 3.2.2.4 at all, for example, but that's 
something we could discuss independent of any of the other perceived issues.



Oh, and one last piece of advice I offer when reviewing code :)



- Don't restructure your code for 'future feature X' until you know what the 
shape of 'future feature X' will look like. To me, that means avoid 
restructuring reuse 'so we can reduce it later' - unless/until we're ready to 
reduce the reuse period :)



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

Re: [cabfpub] Domain validation

[Jeremy Rowley via Public]

That’s fine.  How would you like it broken up? I could break it up by 
validation method or by issue statement. 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Tuesday, May 16, 2017 10:06 AM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Domain validation

 

 

 

On Tue, May 16, 2017 at 11:55 AM, Jeremy Rowley  > wrote: 

1) The document is presented as a ballot because I based the revisions on 190.  
If there are discrete sub-components someone doesn’t like, I don’t mind 
breaking it up into chunks.  

 

The problem is not about 'not liking'. It's about a tremendous amount of text 
that tries to solve a whole host of issues, all at once, and without clear 
identification of the goals or related changes. This makes it incredibly 
difficult to review, and all the more likely of a Ballot 193/197 problem being 
introduced. Further, the approach to creating the ballot creates issues like 
recently discovered by Ben in Ballot 198, in which the 'proposed text' and the 
'redlined version' actually substantially differed from what was actually 
adopted (more on that for another thread).

 

It's not that I disagree with your goals - I think you've captured some very 
useful things to do. I'm just not sure there's any reasonable hope that we'd be 
confident it was appropriately reviewed, especially in light of the substantive 
discussion re: Ballot 190 that still needs adoption, and because of that, makes 
it very hard to consider voting in favor. This is, for what it's worth, notably 
similar to some of the subordinate CA discussions.

 

While that comes across negative (and almost certainly would be reflected in a 
vote, should it come to that), I'm incredibly thrilled that someone such as 
yourself has taken a comprehensive look at it, and I'm thrilled that you've 
found and identified issues. Just the means of attempting to fix them is 
perhaps less than ideal, and much like I'd send back an overly complex code 
review back to the submitter as "overly complex; simplify", I'm trying to 
figure out if there's a way to tease out the issues or look at incrementalist 
approaches here.

 

This is why even with a 'small' change (the OCSP profile), which only removes a 
few lines of text, I tried to extensively annotate the reasonings behind each 
change, the dependencies, and their relationship - see 
https://github.com/sleevi/cabforum-docs/pull/2

 

I'm also not sure I'd agree with some of your problem statements, so that's 
where helping identify what you see as the problem can sort out an appropriate 
solution :)



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

Re: [cabfpub] Domain validation

[Jeremy Rowley via Public]

This is excellent work and helps people understand each method a lot better.
- Thanks! Let me know if you disagree with anything. 

"The CA MUST record the subsection and version of the Baseline Requirements 
used to validate an Applicant’s control over each FQDN included in an issued 
certificate" 
When is this expected to become effective?
- Immediately after the IPR period expires

In methods 3.2.2.4.1, 3.2.2.4.2, 3.2.2.4.3,  b (2), you say that the CA must 
verify that the WHOIS information for the Base Domain has not changed since the 
CA performed the verification process. Is this the WHOIS information record 
itself or should CAs be looking for the Domain Contact to appear in the WHOIS 
record? I'm asking because some WHOIS databases do not release Domain Contact 
information and CAs require an official document from the Domain Registrar that 
contains information about the domain owner and contacts for the initial domain 
validation.
- Right now the time period in that section specifies the Domain  language 825 
days so it’s identical to the verification period. I put this in explicitly in 
case we wanted to reduce the period to of WHOIS re-confirmation to a lesser 
period (such as 90 days?). It should have said WHOIS or Domain Registrar though 
instead of just WHOIS. I also don’t mind dropping bullet point 2 if everyone is 
opposed to a WHOIS/Domain Registrar refresh.

For example, this is the WHOIS record for example.gr:


Domain Name:example.gr
Domain Handle:dr-1234-gr
Protocol Number:1234
Creation Date:24-07-1997
Expiration Date:31-12-2017
Updated Date:05-11-2015
Registrar:FOO
Registrar Referral URL:http://www.FOO.gr
Registrar Email:regist...@foo.gr  
Registrar Telephone:+30.123456
Whois Server: 
Bundle Name:example.gr
Name Server:.example.gr
Name Server:XX.example.gr


According to your proposal, CAs only need to check if the record above has not 
changed?
- Yes. That is the point of bullet point 2. To try and address issues where 
domain ownership may have changed.


Also, there is a small typo in the 3rd paragraph of 3.2.2.4.2 a (FQNs --> 
FQDNs).
- Thanks!



 



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

Re: [cabfpub] Domain validation

[Jeremy Rowley via Public]

Answering in reverse order:

 

2) Subdomains are labels to the left of a verified FQDN. Authorization domains 
are labels to the right. The reasons for a definition are:

a. Under Section 3.2.2.4, the CA is verifying the FQDN.  This verification 
process for some methods may rely on an Authorization Domain Name but the 
verification is tied to a FQDN (per 3.2.2.4). 

b. Most CAs reuse verification of an FQDN to issue certificates that are 
sub-domains of a verified FQDN. Whether this is allowed is ambiguous under 
169/190. 

c. Wildcard domains are always sub-domains of a verified FQDN. Wildcards are 
called out in the definition of an Authorization Domain Name. However, 
verification of a Wildcard Domain Name is never addressed in the actual section.

d. There could be cases where we don’t want to permit a method to issue 
certificates for sub-domains.  Better to split the permissions out so we can 
discuss each method individually and provide clarity around the circumstances 
permitting reuse of validation information.

 

1) The document is presented as a ballot because I based the revisions on 190.  
If there are discrete sub-components someone doesn’t like, I don’t mind 
breaking it up into chunks.  Some of the reasons for the proposal:

a) As mentioned above, wildcard domains are questionable about how they are 
validated.

b) The language is inconsistent. For example, method 1 says the CA is 
“confirming control”. We then switch terminology to “validation”. Following 
that switch, we move to “authenticate”. Do each of these words mean something 
different? 

c) The language is unclear on reuse of validation information. Splitting the 
info out per section so we can change it on a per-validation type basis. Right 
now reuse is not defined, which means it could either require a validation per 
issuance or permit reuse for the 825 day period.

d) Under method 2, who creates the Random value? The CA specifies the value and 
send its via email. Seems like the CA should create it as well. 

e) Under method 2, the interplay in these three sentences is odd:

“The Random Value SHALL be unique in each email, fax, SMS, or postal mail.”

“The CA or Delegated Third Party MAY resend the email, fax, SMS, or postal mil 
in its entirety, including re-use of the Random Value, provided that the 
communication's entire contents and recipient(s) remain unchanged.”

“The Random Value SHALL remain valid for use in a confirming response for no 
more than 30 days from its creation. The CPS MAY specify a shorter validity 
period for Random Values, in which case the CA MUST follow its CPS.”

Does this mean you can resend for 30 days? Can you send it after 30 days? Why 
does one sentence say it must be unique but the other permit resending? 

 

Etc.

 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Monday, May 15, 2017 4:55 PM
To: CA/Browser Forum Public Discussion List <public@cabforum.org>
Cc: Jeremy Rowley <jeremy.row...@digicert.com>
Subject: Re: [cabfpub] Domain validation

 

Jeremy,

 

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

 

You posed it as a ballot, so it makes it hard to comment on line items (Using 
word to "track changes" is not a very publicly accountable or managable 
process), but I'm hoping to better understand.

 

Could you

1) Highlight what you believe are inconsistencies in the existing language?

2) Highlight why you believe there are differences between subdomains and 
authorized domain names?

 

 

On Mon, May 15, 2017 at 4:41 PM, Jeremy Rowley via Public <public@cabforum.org 
<mailto:public@cabforum.org> > wrote:

While working on implementing the methods defined by ballot 169, we noticed a 
lot of inconsistencies in the language and process. This made some of the 
methods confusing, especially on how they applied to reuse of information and 
verification of subdomains/wildcards.  Attached is a proposal that we think 
clarifies the process and tightens up the language. 

 

A couple of notes:

1.  The proposal doesn’t intend to substantially change any of the methods. 
However, this is DigiCert’s interpretation of the requirements. Given the 
previous language, disagreement on the interpretation is likely and will 
highlight the need for a clarifying ballot.
2.  This method doesn’t necessarily replace 190. If longer discussion is 
needed (because there are lots of changes), then this could be a subsequent 
revision to the validation methods and include more stringent controls (like 
reverifying WHOIS information within 30 days and restricting sub-domain 
methods). For now, I tried to keep the process and reuse the same.
3.  The proposal separates out sub domain reuse, reuse of documentation, 
and splits the longer methods into discrete s

[cabfpub] Domain validation

[Jeremy Rowley via Public]

While working on implementing the methods defined by ballot 169, we noticed
a lot of inconsistencies in the language and process. This made some of the
methods confusing, especially on how they applied to reuse of information
and verification of subdomains/wildcards.  Attached is a proposal that we
think clarifies the process and tightens up the language. 

 

A couple of notes:

1.  The proposal doesn't intend to substantially change any of the
methods. However, this is DigiCert's interpretation of the requirements.
Given the previous language, disagreement on the interpretation is likely
and will highlight the need for a clarifying ballot.
2.  This method doesn't necessarily replace 190. If longer discussion is
needed (because there are lots of changes), then this could be a subsequent
revision to the validation methods and include more stringent controls (like
reverifying WHOIS information within 30 days and restricting sub-domain
methods). For now, I tried to keep the process and reuse the same.
3.  The proposal separates out sub domain reuse, reuse of documentation,
and splits the longer methods into discrete steps.  There are lots of
redundant sections. This is intentional. The goal is to (eventually) talk
about each method discretely and decide what requirements are tied to
document reuse and sub-domain validation. 

 

Look forward to your comments. 

 

Jeremy

 



Domain Validation - revised.docx
Description: MS-Word 2007 document


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

Re: [cabfpub] CAA Customer Identifier

[Jeremy Rowley via Public]

Yes – thanks! I didn’t realize you could have CA specific properties.

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Monday, May 15, 2017 12:59 PM
To: CA/Browser Forum Public Discussion List <public@cabforum.org>
Cc: Jeremy Rowley <jeremy.row...@digicert.com>
Subject: Re: [cabfpub] CAA Customer Identifier

 

Jeremy,

 

You can extend the CAA syntax with issuer-specific properties. Do you think it 
makes sense to first experiment with this deployment, and then subsequently 
report back?

 

Namely, the syntax for the issue property tag is

 

issue  [; = ]*

 

The '=" portion allows you to define CA-specific properties 
without the registration of additional tags. For example, your 'customer ID' 
tag is clearly CA specific, while 'validation method' could be generic (if 
applied to the BRs) or could be a CA-specific construction (if more rigid than 
the BRs)

 

For example, if DigiCert wanted, it could

 

issue digicert.com <http://digicert.com> ;cid=1234;method=1.2.3.4

 

This syntax is expanded upon in Section 5.2, which includes the following:

   An issuer MAY choose to specify issuer-parameters that further

   constrain the issue of certificates by that issuer, for example,

   specifying that certificates are to be subject to specific validation

   polices, billed to certain accounts, or issued under specific trust

   anchors.

 

   The semantics of issuer-parameters are determined by the issuer

   alone.

 

 

Does that help?

 

On Mon, May 15, 2017 at 2:45 PM, Jeremy Rowley via Public <public@cabforum.org 
<mailto:public@cabforum.org> > wrote:

Although CAA significantly narrows the scope of issuers, a tag identifying the 
customer/account where issuance permitted would significantly reduce spam 
domain control emails. Despite CAA limiting issuance of a domain to DigiCert, 
we may still have a dozen entities trying to request the same domain. In fact, 
I suspect the number of requested bad domains will increase on our side if a 
CAA record is present. Although we have methods to control spam validation 
emails, a bad actor could create accounts and annoy customers hoping the domain 
is inadvertently approved. To limit this, I’d like to create a CAA tag that is 
customerID. Something like: 

 

CAA 0 register “customer ID=[ID provided by CA]”

 

The requirement in the RFC for creating tags is to register the tag with IANA. 
I thought I’d float the idea here first though. If there’s interest, we could 
combine it with a validation method restriction

 

CAA 0 register “customer ID=[ID provided by CA] validationMethod=[Validation 
Method OID]”

 

Jeremy

 

 


___
Public mailing list
Public@cabforum.org <mailto: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

[cabfpub] Ballot 191 - Clarify Place of Business Information

[Jeremy Rowley via Public]

Ballot 191 - Clarify Place of Business Information Field Inclusion

The current EV Guidelines are not clear on what address information is
required in a certificate. This ballot clarifies the requirements and
harmonizes the EV Guidelines and Baseline Requirements.

The following motion has been proposed by Bruce Morton of Entrust and
endorsed by Jeremy Rowley of DigiCert and Robin Alden of Comodo:

--Motion Begins--

A. Modify Section 9.2.7 as follows:

9.2.7. Subject Physical Address of Place of Business Field

Certificate fields:

Number and street: subject:streetAddress (OID: 2.5.4.9)

City or town: subject:localityName (OID: 2.5.4.7)

State or province (where applicable): subject:stateOrProvinceName (OID:
2.5.4.8)

Country: subject:countryName (OID: 2.5.4.6)

Postal code: subject:postalCode (OID: 2.5.4.17)

Required/Optional: --(City, State, and country - Required; Street and postal
code - Optional)--__As stated in Section 7.1.4.2.2 d, e, f, g and h of the
Baseline Requirements__

Contents: This field MUST contain the address of the physical location of
the Subject's Place of Business.

--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 199 Status: Final Maintenance Guideline

Start time (22:00 UTC)

End time (22:00 UTC)


Discussion (7 to 14 days)

9 May 2017

16 May 2017


Vote for approval (7 days)

16 May 2017

23 May 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.

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.

 



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

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

[Jeremy Rowley via Public]

+1. I’d prefer not to explicitly state after-ballot applicability as doing so 
raises the question the question for all future ballots. If we were going to 
add language about applicability, the language should be in the scope section 
and broadly state that the BRs only apply to certificates issued after the 
effective date of the latest version. (Note, I am not proposing this)

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Thursday, May 4, 2017 1:30 PM
To: CA/Browser Forum Public Discussion List 
Cc: Ryan Sleevi 
Subject: Re: [cabfpub] [EXT] Re: Ballot 199 - Require commonName in Root and 
Intermediate Certificates

 

Kirk raised that, but it does not seem to be a founded concern.

 

1) That requirement applies to all certificates issued against the current BRs

2) The BRs do not retroactively invalidate - or, especially in the case of 
Ballot 197 - approve - certificate issuance.

 

A CA has always and only been obligated to state compliance with the in-force 
BRs with respect to issuance and its activities.

 

On Thu, May 4, 2017 at 3:27 PM, Steve Medin via Public  > wrote:

Gerv, could we also request explicit forward-looking language? Kirk raised the 
concern about whether this applies to existing roots and intermediates. We have 
a root issued in 1997 that does not have a common name. Some interpretations 
have been discussed, but we would strongly prefer that this be written into 
this change for clear future interpretations.

 

If I may:

 

7.1.4.3. Subject Information – Root Certificates and Subordinate CA Certificates

When issuing a Root Certificate or Subordinate CA Certificate, the CA 
represents that it followed the procedure set forth in its Certificate Policy 
and/or Certification Practice Statement to verify that, as of the Certificate’s 
issuance date, all of the Subject Information was accurate and included the 
content required by this section.

 

 

 

From: Public [mailto:public-boun...@cabforum.org 
 ] On Behalf Of Ben Wilson via Public
Sent: Thursday, May 04, 2017 11:21 AM
To: CA/Browser Forum Public Discussion List  >
Cc: Ben Wilson  >
Subject: [EXT] Re: [cabfpub] Ballot 199 - Require commonName in Root and 
Intermediate Certificates

 

Two questions, Gerv.  

 

1 - Does this ballot rule out “vanity CAs” – CAs with customer names in the 
subject field, even though the key is held by the root CA?  (I can provide 
further clarification, and/or examples, if necessary.

2-  What is the full current wording of Ballot 199?

 

Thanks,

 

Ben 

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase Markham 
via Public
Sent: Tuesday, April 25, 2017 9:03 AM
To: CABFPub  >
Cc: Gervase Markham  >
Subject: [cabfpub] Ballot 199 - Require commonName in Root and Intermediate 
Certificates

 

Ballot 199 - 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 Patrick Tronnier of OATI and Ryan Sleevi of Google:

-- MOTION BEGINS --


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 

Re: [cabfpub] Ballot 198 - Onion Revisions v2

[Jeremy Rowley via Public]

This ballot is now in voting. 

Ballot 198 - .Onion Revisions

Appendix F of the EV Guidelines in unclear on what a CA does with the Tor
Service Descriptor Hash extension. This ballot clarifies that inclusion of
the extension in the TBSCertificate is required. 

The following motion has been proposed by Jeremy Rowley of DigiCert and
endorsed by Ryan Sleevi of Google and Erwann Abalea of DocuSign France to
introduce new Final Maintenance Guidelines for the "Guidelines for the
Issuance and Management of Extended Validation Certificates" (EV
Guidelines).

-- MOTION BEGINS -

Revise Appendix F, Section 1 to read as follows:

Appendix F - Issuance of Certificates for .onion Domain Names

A CA may issue an EV Certificate containing the .onion Domain Name provided
that issuance complies with the requirements set forth in this Appendix:

1.  CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31)

The CAB Forum extension in of the TBSCertificate to convey hashes of keys
related to .onion addresses.  The CA MUST include the Tor Service Descriptor
Hash extension using the following format:

cabf-TorServiceDescriptorHash OBJECT IDENTIFIER ::= { 2.23.140.1.31 }

TorServiceDescriptorHash:: = SEQUENCE { 

algorithmAlgorithmIdentifier

subjectPublicKeyHash   BIT STRING  }

Where the AlgorithmIdentifier is a hashing algorithm (defined in RFC 6234)
performed over the raw Public Key of the .onion service and
SubjectPublicKeyHash is the value of the hash output of the raw Public Key.

--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 198 Status: Final Maintenance Guideline

Start time (22:00 UTC)

End time (22:00 UTC)


Discussion (7 to 14 days)

April 24, 2017

May, 2017


Vote for approval (7 days)

May 1, 2017

May 8, 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.

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. 

 

 



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

Re: [cabfpub] Ballot 190

[Jeremy Rowley via Public]

Should we include the domain name in that sequence so it’s not ordered? 

 

Such as:  

 

BRComplianceDetails ::= SEQUENCE {

dNSName   IA5String,

versionOBJECT IDENTIFIER,

validationMethodINTEGER

}

 

 

From: Ryan Sleevi [mailto:sle...@google.com] 
Sent: Monday, May 1, 2017 9:18 AM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List ; Gervase 
Markham 
Subject: Re: [cabfpub] Ballot 190

 

Well, I was discussing in the broader context :)

 

For example, you "could" simply indicate

 

BRComplianceDetails ::= SEQUENCE {

  version   OBJECT IDENTIFIER,

  validationMethod  INTEGER

}

 

As an extension

 

There are, of course, more efficient ways to structure this data (for example, 
expandable enum of INTEGER values for version). I just provided this as a quick 
and dirty example of how you could provide this information within a 
certificate in a clear and auditable way. It could allow, for example, auditors 
to ensure that their random sampling methodology appropriately covered all 
validation methods the CA practiced, without undermining the purpose and value 
of sampling.

 

On Mon, May 1, 2017 at 11:13 AM, Jeremy Rowley  > wrote:

How does this work if the intermediate doesn't contain the anyPolicy OID?

-Original Message-
From: Public [mailto:public-boun...@cabforum.org 
 ] On Behalf Of Gervase
Markham via Public
Sent: Monday, May 1, 2017 9:08 AM
To: Ryan Sleevi  >; CA/Browser 
Forum Public Discussion List
 >
Cc: Gervase Markham  >
Subject: Re: [cabfpub] Ballot 190

On 01/05/17 16:02, Ryan Sleevi wrote:
> I did. It allows users to make an informed decision of the
> trustworthiness of the information presented in the certificate, much
> like EV policy OIDs and OV policy OIDs reportedly provide a stronger
> level of assertion.

Did you anticipate a marker both for the validation method and also for the
version of the BRs used? Both would be needed to pin it down exactly.

Gerv

___
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] Ballot 190

[Jeremy Rowley via Public]

I like the idea of using policy OIDs better than a new extension, but we
should probably use the extension considering the concern over older
software. Anyone strongly opposed to the extension?  

-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Rob Stradling
via Public
Sent: Tuesday, May 2, 2017 10:19 AM
To: Ryan Sleevi 
Cc: Rob Stradling ; CA/Browser Forum Public
Discussion List 
Subject: Re: [cabfpub] Ballot 190

On 02/05/17 16:52, Ryan Sleevi wrote:
>
>
> On Tue, May 2, 2017 at 11:44 AM, Rob Stradling 
> > wrote:
>
> And if, as today, the Leaf cert doesn't contain 2.23.140.x.y.z, then
> the same is true: the leaf would never validate with the
> 2.23.140.x.y.z OID in the user-initial-policy-set.  Right?  If so,
> I'm not really sure why you think this approach would be "crude", tbh.
>
>
> Because it's asserting a policy OID that's not valid within the policy 
> tree. Obviously, not asserting a policy OID that's not valid in the 
> policy tree is no big deal, as there's an infinite set of those that 
> we don't assert ;)
>
> Again, I want to stress that it should technically work. But it also 
> comes with the side-effect that say, if a CP/CPS says "We only assert 
> policy OIDs that are valid in the policy tree" (and I have seen some 
> CP/CPSes or regulations to that effect, IIRC), then it means asserting 
> the anyPolicy in the intermediate, which may or may not be desirable.

Ah.  I hadn't seen any such CP/CPSes.

> It's assuming that CAs' software even lets them assert such policy OIDs.
> I can totally see an issuance pipeline that refuses to allow issuance 
> of a leaf policy if the intermediate doesn't assert a compatible 
> policy (via policyMappings - which I have zero interest to support and 
> it can die in a fire, or via anyPolicy, or an explicit policy). So 
> it's not necessarily even a 'better' solution, from a "How deployable is
this".
> The purpose of policy OIDs is to constrain through the issuance tree 
> the validity, and this is 'hijacking' that because it's expressing 
> something about the leaf that is explicitly _not_ constrained by the 
> issuing intermediate.

That's the purpose of policy OIDs in intermediate certs, certainly. 
However, I think it'd be reasonable to interpret this as a stand-alone
sentence:
   "In an end entity certificate, these policy information terms indicate
the policy under which the certificate has been issued and the
purposes for which the certificate may be used."
(This kinda reminds me of the "gap" in the spec re: the use of EKU OIDs in
intermediate certs, and the resulting arguments that have spanned the last
decade or two ;-) )

But it's a moot point really.  "How deployable is this?" is indeed the right
question to ask, and the side-effect you just mentioned would be
undesirable.

> The extension avoids that to some extent (because it's "just" an 
> intermediate extension), but comes w/o any ability to apply constraints.
> It's a different trade-off, but one I think at least captures the 
> 'current' thinking. I was trying to avoid the over-engineering 
> discussion (that's possible with either solution) that could come 
> about if, say, we wanted to distinguish "This intermediate from this 
> CA only uses methods 4, 7, and 10" - (for which policy OIDs is 
> absolutely the correct thing, but which clients would need to supply 
> it in the user-initial-policy-set), and instead focus on "facts about 
> the leaf" - for which an extension is entirely sufficient and avoids 
> the extra engineering (which I've now introduced and I'm sure at least 
> some will latch onto as a means of derailing conversion :P)

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
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] Informal discussion of Code of Conduct Ballot

[Jeremy Rowley via Public]

We’ve already seen spats about “demeaning” and “inappropriate” so I think the 
Forum does need to address the scope of that particular issue.

 

From: vfourn...@apple.com [mailto:vfourn...@apple.com] 
Sent: Monday, May 1, 2017 7:17 PM
To: Jeremy Rowley 
Cc: CA/Browser Forum Public Discussion List 
Subject: Re: [cabfpub] Informal discussion of Code of Conduct Ballot

 

Hi Jeremy,

 

I think the words used are pretty clear, and they are used in other SDO Codes 
of Conduct without any confusion, problem or issue.  If you’d like to propose 
specific words that you’d suggest we use instead, we’d be happy to consider 
them and determine if they are any more clear.

 

We should keep in mind that these are common sense, plain English terms.  It is 
troubling that people are picking at words like “demeaning” and 
“inappropriate.”  Do Forum members need to reserve the right to engage in 
certain types of demeaning and inappropriate conduct?  

 

It’s not about stifling conversation.  It’s about treating fellow Forum members 
with professionalism and respect.  I don’t understand why there is resistance 
to that.









Best regards,

 

Virginia Fournier

Senior Standards Counsel

 Apple Inc.

☏ 669-227-9595

✉︎ v...@apple.com  

 

 

 

 

 

On May 1, 2017, at 5:55 PM, Jeremy Rowley  > wrote:

 

Suggestions:

 

(b)  Refrain from conduct __within the Forum__ such as:  

*   Directly insulting or demeaning another person

[JR] This seems vague. Some people take things as demeaning when they are not 
meant to be demeaning.  I think this could be used to stifle conversation. 
We’ve had accusations that conduct has been insulting/demeaning on the forum. 
Would you say it’s risen to that level? I support the principle, but would like 
clarity so we don’t get end up mixing persons with ideas eventually.

*   Touching another person in a physically inappropriate way. 
*   Deliberately intimidating, stalking or following (online or in person) 
another person.

[JR] Following online? Like on twitter? 

*   Inappropriately disrupting official Forum events, including meetings, 
talks, and presentations.

[JR] Inappropriately is too vague. Are we trying to change a specific behavior 
at the CAB Forum? Could we clarify what this means? 

*   Spamming, trolling, flaming, baiting, and other attention-stealing 
behavior.

[JR] Baiting/flaming are too similar to criticism of the idea. Can we add 
clarity? 

 



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

Re: [cabfpub] Informal discussion of Code of Conduct Ballot

[Jeremy Rowley via Public]

Suggestions:

 

(b)  Refrain from conduct __within the Forum__ such as:  

*   Directly insulting or demeaning another person

[JR] This seems vague. Some people take things as demeaning when they are not 
meant to be demeaning.  I think this could be used to stifle conversation. 
We’ve had accusations that conduct has been insulting/demeaning on the forum. 
Would you say it’s risen to that level? I support the principle, but would like 
clarity so we don’t get end up mixing persons with ideas eventually.

*   Touching another person in a physically inappropriate way. 
*   Deliberately intimidating, stalking or following (online or in person) 
another person.

[JR] Following online? Like on twitter? 

*   Inappropriately disrupting official Forum events, including meetings, 
talks, and presentations.

[JR] Inappropriately is too vague. Are we trying to change a specific behavior 
at the CAB Forum? Could we clarify what this means? 

*   Spamming, trolling, flaming, baiting, and other attention-stealing 
behavior.

[JR] Baiting/flaming are too similar to criticism of the idea. Can we add 
clarity? 

 



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

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

[Jeremy Rowley via Public]

A broad removal of DTPs would be difficult for anyone using any sort of hosted 
services.  Scoping the removal to 3.2.2.4 is fine (and in-line with Gerv's 
original proposal).

-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Peter Bowen via 
Public
Sent: Monday, May 1, 2017 7:30 AM
To: Gervase Markham 
Cc: Peter Bowen ; CA/Browser Forum Public Discussion List 

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


> On May 1, 2017, at 6:15 AM, Gervase Markham  wrote:
> 
> On 01/05/17 14:12, Peter Bowen wrote:
>> You understand correctly.  Today CAs use many third parties as part 
>> of operation — they rent space in data centers and office buildings 
>> they don’t own, they contract with companies to provide security 
>> guards, etc.
> 
> OK. This change would be of larger scope than a change merely to 
> prevent the outsourcing of domain ownership validation. The latter got 
> agreement (after discussion) from the participants at the F2F, which 
> makes it a tempting route to go down. What do people think of Peter's 
> expanded proposal?

Looking back at the BRs, you might be right.  If anyone is reading DTP to cover 
the data center or security guard examples above, then simply removing DTP is 
too broad a brush.

We can probably scope the removal of DTP to 3.2.2.4.

Thanks,
Peter
___
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] Ballot 190

[Jeremy Rowley via Public]

How does this work if the intermediate doesn't contain the anyPolicy OID? 

-Original Message-
From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase
Markham via Public
Sent: Monday, May 1, 2017 9:08 AM
To: Ryan Sleevi ; CA/Browser Forum Public Discussion List

Cc: Gervase Markham 
Subject: Re: [cabfpub] Ballot 190

On 01/05/17 16:02, Ryan Sleevi wrote:
> I did. It allows users to make an informed decision of the 
> trustworthiness of the information presented in the certificate, much 
> like EV policy OIDs and OV policy OIDs reportedly provide a stronger 
> level of assertion.

Did you anticipate a marker both for the validation method and also for the
version of the BRs used? Both would be needed to pin it down exactly.

Gerv
___
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] Baseline Requirements v. 1.4.6

[Jeremy Rowley via Public]

At least one of those is part of ballot 190

 

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Dimitris 
Zacharopoulos via Public
Sent: Saturday, April 29, 2017 1:22 PM
To: public@cabforum.org
Cc: Dimitris Zacharopoulos 
Subject: Re: [cabfpub] Baseline Requirements v. 1.4.6

 

Ben,

At some point we should also fix the incorrect references pointing to Section 
3.3.1 instead of 4.2.1, that have been identified in Sections 3.2.2.4 and 
4.1.2. 


Dimitris.



On 29/4/2017 12:34 πμ, Ben Wilson via Public wrote:

All versions are now posted here - 
https://cabforum.org/baseline-requirements-documents/ 

I will upload them to the wiki and update the GitHub version.

From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ben Wilson via 
Public
Sent: Friday, April 28, 2017 1:51 PM
To: CABFPub   
Cc: Ben Wilson   
Subject: [cabfpub] Baseline Requirements v. 1.4.6

 

All,

 

I am in the process of updating the web page for the  Baseline Requirements and 
creating a version 1.4.7 of the Baseline Requirements based on adoption of 
Ballot 196 - Define "Audit Period".  In that process, I compared version 1.4.6 
on GitHub with a Word version (which I’ve used in the past to create the PDFs 
that we post on cabforum.org), and I noticed some minor discrepancies.  

 

Until we abandon one version over the other (and maybe we’re at that point), it 
is important to ensure consistency between GitHub and Word.  I made changes to 
both the GitHub version (see 
https://github.com/cabforum/documents/pull/54/commits/5033553107cad20ac26b8c185b6006463f8df013)
 and the Word version (redlined version attached as PDF) to make them more 
consistent.  My belief is that with these edits that they are now consistent 
(except for instances where section headings have been capitalized in one 
version or the other), and that they reflect the current state of the Baseline 
Requirements (as of Ballot 195 – CAA Fixup, provided that no exclusion notices 
are filed during the IPR review period). 

 

Before I proceed with creating a version 1.4.7 of the BRs, I thought I’d give 
anyone a chance to object, correct me where I’m wrong, etc.  Please review.

 

Thanks,

 

Ben






___
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] Ballot 190

[Jeremy Rowley via Public]

Sorry – that was pretty confusing.  I revised the questions in way that I think 
answers most of your question:

1.  If we include the validation WG proposed language in Section 3.2.2.4, 
does that adequately address the concerns with the previous version of ballot 
190?
2.  If there are still concerns, should we drop the reuse language 
altogether? Note that this will require revalidation of all information prior 
to issuance of new certificates if the original validation was not in 
accordance with one of these ten sections.
3.  If we add the language to Section 3.2.2.4, would you vote against the 
ballot because of the document reuse?
4.  If the reuse language proposed was dropped altogether and re-validation 
became required, would you vote against the ballot?
5.  If you’d vote against the ballot, is there some middle ground that we 
can reach? For example, could we say that all previous validation information 
not complaint with the 10 methods must expire 13 months from the date of the 
ballot? Alternatively, everything under section 7 expires immediately while 
documents affected by a modification to 1-6 will remain valid for 825 days? 
Other proposals.

Basically, we’re at an impasse on the ballot, and I’m not sure which way the 
vote would go.

 

A couple of comments:

 

“I think the general language proposal is a bit awkward - I would rather see it 
pegged to an explicit minimum version (for example, BRs 1.4.1) and explicitly 
forbid using a previous "any other method" validation. Is that problematic?”

 

This seems reasonable to me, but I’ll let others chime in.

 

“I think if we're still unable to agree on a timeline such as that - requiring 
revalidation consistent with the current-3.2.2.4 for anything that was 
validated under a previous-3.2.2.4 that is no longer permitted - my only other 
suggestion would be to require an explicit expression within the certificate 
that it complies with the current version of 3.2.2.4 at the time of issuance. 
This would help give Relying Parties the necessary assurances that the CA is 
committed to security.”

 

This seems reasonable to me as well.

 



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