[cabfpub] Question 5 - Domain Validation pre-ballot

Robin Alden robin at comodo.com
Fri Nov 13 14:38:48 UTC 2015

I don't think the security policy associated with the 3 types are


It depends upon what the CA marker is being used for.  It seems to me
there are two types of challenge being employed here.

1) When a CA has a reliable means of communication with someone
pre-defined or identified as an owner or controller of the domain, we
use a Random Value in the request to that person asking for their
confirmation of the certificate request.  
Those Random Values cannot be re-used because, once the value is known
outside the CA, it may be replayed to spoof a confirmation response to
any future challenge the CA makes using that same Random Value.

This would apply for Random Values used in methods 2, 3, 4.


Note, however, that combining multiple challenges associated with a
single certificate request and going to the same recipient is
permissible with a single Random Value and actually desirable when
validating the domains of a multi-SAN certificate having determined they
have a common owner/controller.


E.g. A multiple SAN certificate request where all the domains share
common contact information in WHOIS.



.. And so on to 100 SANs.

For this example, the registered domain names in all 100 SANs have in
their WHOIS entry an ADMIN email address of domains at entity.com

It is sufficient to send an email to domains at entity.com listing the 100
FQDNs going into the SANs and including a single Random Value which the
recipient must provide back into the certificate request flow as
confirmation.  There is a chance the email recipient will even check the
list of domains in the email.

It is overkill to send 100 emails to domains at entity.com each listing 1
FQDN going into a SAN and including a Random Value.  The recipient
providing all 100 Random Values back into the certificate request flow
does not provide any better security of the confirmation.  


2) When a CA wishes the applicant to provide a practical demonstration
of control of the domain to be certified (methods 6 & 7, lines H & J)
the CA passes a value to the applicant which the applicant must then use
in their demonstration of control.  
Re-use of these values is OK, provided that the value used is unique to
the applicant.

This would apply for Random Values used in methods 6, 7
and for Request Tokens used in method 7.

CAs may sometimes not be able to accurately identify whether the
applicant for one certificate request is the same as the applicant for
another and if that is the case then each certificate request (not just
each applicant) will need a new value.  This may be the case for CAs who
accept certificate requests through resellers or other third parties
where the identification of the applicant is handled by the reseller or
third party - and so is not done within the scope of an organization
audited as complying with the BRs.


I think that a Request Token should be permitted for method 6, too.


The working group looked at introducing a non-reuse requirement and a
time limit for how long CA markers could be relied on but removed that
language from the draft when it became clear it was not straightforward
to set limits.  We were sure that limits to reuse and lifetime could be
agreed, but a) it's complicated and b) these are Baseline Requirements -
not a complete CPS, so the work group punted on the issue.


Robin Alden



From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
On Behalf Of Tim Shirley
Sent: 13 November 2015 12:57
To: kirk_hall at trendmicro.com; CABFPub (public at cabforum.org)
Subject: Re: [cabfpub] Question 5 - Domain Validation pre-ballot


If we want to make the requirements and security policies associated
with the 3 "CA Marker" types equivalent, which seems to me like a good
idea, then we're going to be inherently limited by the one to one
relationship between a Request Token and Public Key.  That is, the
Request Token value is going to be the same for all domains in a
particular certificate because they all share the same Public Key.
Furthermore, if the customer comes back a year later to renew their
certificate, and uses the same Public Key, they're going to get the same
Request Token again.

In light of that, perhaps it makes sense to simply require that the CA
Marker (regardless of type) is unique per Public Key?  You wouldn't be
able to put a time limit on the use of a Request Token unless you
required the customer to generate a new key pair after that time limit
expired.  But is a time limit really necessary if the value is tied to
the key?  An attacker who gains access to an "unused CA Marker" can't
use it to obtain a certificate he/she can use without also gaining
access to the private key associated with it. 


From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
On Behalf Of kirk_hall at trendmicro.com
Sent: Thursday, November 12, 2015 8:08 PM
To: CABFPub (public at cabforum.org)
Subject: [cabfpub] Question 5 - Domain Validation pre-ballot


Question 5 - Domain Validation pre-ballot


Richard Wang of WoSign posted the following comment on the pre-ballot:


"I think the ballot should include some sort of requirement that a
Random Value, Request Token, or Test Certificate can only be used once
by the CA and customer to validate one domain, and that a new Random
Value, Request Token, or Test Certificate must be generated by the CA
for the customer for each domain being validated, and each time a domain
is validated."


Currently, there is no limitation on how many times the same Random
Value, Request Token, or Test Certificate (call them all "CA markers")
can be used, or for confirming how many domains, or for what period of


On the call today, there was general agreement that the CA Markers
should not be reused, but that a new CA Marker should be generated by
the CA for validation of each new domain.  By extension, a CA should
also generate a new CA Marker each time the CA re-validates the same
domain (every 13 months or earlier for EV domains, every 39 months or
earlier for DV and OV domains).


There was one suggestion that maybe a CA could use a single CA Marker
for validating all the domains included in a single CSR.


Gerv also suggested there should be a time limit on how long a CA Marker
would be valid, as a hacker could perhaps find an unused CA Marker sent
to a domain owner and then use it to get a bogus cert.   For this
reason, if the customer does not use the CA Token in a fairly short
period, the CA should generate and send a new CA Marker to the customer
for the domain.


Eddy said that applicants are sometimes slow to complete their vetting
process, and so any time limit should not be too short.  He will explain
and offer suggestions in an email.


Question for Discussion:  


(1) Should all "CA Markers" (Random Values, Request Tokens, Test
Certificates) be prohibited from re-use?  Should the limitation be one
of the following?


(a) CA Markers should only be used one time for one domain being
validated for an Applicant

(b) CA Markers should only be used one time, but can be re-used for
confirming control of multiple domains so long as they are all contained
in one CSR from an Applicant

(c) In any case, no CA Marker may be used more than x days after it has
been generated and issued by the CA to the Applicant - if the domain
validation is not completed in that period, the CA must generate and
give a new CA Marker to the Applicant.


What rule(s) should we set for this?


The information contained in this email and any attachments is
and may be subject to copyright or other intellectual property
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply
mail or
telephone and delete the original message from your mail system.




This transmission may contain information that is privileged,
confidential, and/or exempt from disclosure under applicable law. If you
are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or use of the information contained
herein (including any reliance thereon) is strictly prohibited. If you
received this transmission in error, please immediately contact the
sender and destroy the material in its entirety, whether in electronic
or hard copy format.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151113/7764404f/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5156 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20151113/7764404f/attachment-0001.p7s>

More information about the Public mailing list