[cabfpub] VWG Question 6 - Request tokens

kirk_hall at trendmicro.com kirk_hall at trendmicro.com
Wed Nov 18 16:09:41 MST 2015


Robin, this question starts with you - there is some confusion about exactly how new Method 7 is intended to work as it relates to (new) Request Tokens.  Here is the current draft ballot language:

7. Having the Applicant demonstrate control over the requested FQDN by the Applicant making a change to information in a DNS record for an Authorization Domain Name where the change is to insert a *** Request Token;

Request Token: A value derived in a method specified by the CA from the public key to be certified. The uniqueness of the Request Token and the irreversibility of the derivation to be at least as strong as those of the cryptographic signature algorithm to be used to sign the certificate.

(I have underlined the phrase "from the public key TO BE CERTIFIED"" as I don't understand the reference to certifying a public key - I thought the purpose of the exercise was to "[have] the Applicant demonstrate control over the requested FQDN".)

A related issue - Richard Barnes has proposed amending (new) Method 9 involving Test Certificates to allow the Applicant to generate the Test Certificate (instead of the CA) but then to insert a Random Value or a Request Token, and then install the Test Certificate on the FQDN.

Here is the question some people have been asking - does the CA issue the "Request Token" to the Applicant for the Applicant to use, or does the Applicant create the Request Token itself (and not receive it from the CA)?

As the ballot stands now, both the Random Value method (Method 6) and the Test Certificate method (Method 9) necessarily use a Random Value or Test Certificate created by the CA and sent to the Applicant to use in classic "challenge and response" fashion.  The whole point of this is to prevent a hacker guessing or finding and reusing the same Random Value or Test Certificate to imitate the real domain owner (the customer) in another session.

But under your original proposal, does the CA provide the Request Token to the Applicant to use?

Some messages have suggested the Request Token is nothing more than a hash - by the Applicant - of the public key associated with a specific CSR or certificate request that includes the domain.  Is that true?

If true, I suppose a single use of the Request Token tied to that specific public key for a one-time validation of (one?) domain contained in the CSR associated with the public key might be adequate security.  But if the hashing method is publicly known to hackers, and if the customer's public key is available to the hackers (which it will be once a certificate associated with the public key is in use on any site), then the hacker can easily create a duplicate of the Request Token that the CA is relying on.  Doesn't that pose a security risk - especially if the same Request Token is ever used after the certificate for the public key used to generate the Request Token is publicly available (after the website secured by the cert with the public key is up and running)?

I think there is a danger during our discussion of domain validation methods in conflating the act of submitting a CSR to request a certificate, versus the act of validating a domain for future certificate requests (which only needs to occur once every 13 months for EV, once every 39 months for DV and OV).  Any domain method that STARTS with a CSR has to be evaluated very carefully so we pull the domain validation process for the customer's future use apart from any specific certificate request.

Can you help us understand your original Request Token proposal in greater detail?  What is the  process flow, and how many times (and for how many domains) do you allow the same Request Token to be used / re-used?

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
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.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151118/10806f62/attachment.html 


More information about the Public mailing list