[cabf_validation] Preparation for next VWG call on Thurs. Jan. 14

[kirk_hall at trendmicro.com]

Good call today.  I believe our next call will be in four weeks, on Thurs. Jan. 14.  Jeremy - can you cancel the call for Dec. 31?

I would like to suggest a deadline of three weeks - no later than Jan. 7 - for people to circulate updated versions of their proposals, so that VWG members will have a week to consider (and consult with their vetting staff too).

One general observation - based on today's call, I think the VGW (and the Forum and public as well) can only really evaluate a validation method if they have a process flow for how the method would be implemented (which can help explain the wording of the proposed method).  For example, someone today (Peter?) commented that Robin's Method 7 as proposed was intended to make the validation and issuance process just two communications - one round trip -  between CA and Applicant, while changes (like a Random Value sent from the CA to the Applicant) could make it two round trips.  >From this I have assumed Robin's original Method 7 would work something like this:


*        CA's website says "If you want a cert for one or more FQDNs, create a CSR, do a hash of all the public key for your CSR using this algorithm (which is now your Request Token), and post the Request Token in the DNS record or on this page of each of the FQDNs you have requested in the CSR.  Then email us the CSR and we will verify by looking for the Request Token in for each of the FQDNs in your CSR

*        Applicant does all this, and sends the CSR to the CA

*        CA confirms the Request Token is posted in all the places required for all the FQDNs, and issues cert to customer using the public key in the Request Token

Robin, is this more or less the process flow in your original Method 7?  If yes, I think it's secure for that particular certificate request (and even if a hacker tries to trick the CA by using the same public key in a later Request Token, the resulting cert will be useless to the hacker).  But I would have concerns (or want to know more) if a hash of the public key is dropped, and the generic Applicant instructions instead tell Applicants "do a hash of your Experian credit rating and put it in the DNS record and/or the webpage for each FQDN you want to validate), as that is not tied to a public-private key pair that only the Applicant has, and does not contain an unknown variable (such as a Random Value) so could be imitated by a hacker.

So what I'm suggesting is, it will be very useful for the proponents of all new methods (or proponents of broader implementations of methods such as Method 7) can give us a clear process flow to help us evaluate the security of the idea.

That said, here is what I think we need by Jan. 7:

Robin - you will do a redraft of new Method 7 (Request Token).  I suggest you draft as you originally intended (maybe adding the requirement of a Random Value along with a hash of the public key in the cert request), and separately, if you want to try to encompass some of Jeremy's concepts today (but only if you think that will work with the Request Token concept).  When you circulate, please include a brief analysis of why you think the method as amended provides adequate security.

Also, did you intend that your Method 7 Request Token could only be used in connection with a certificate request (or multiple certificate requests) for certs for one particular public key?  If so, should you add that as a limitation to the Method 7 description?

Jeremy - if you want to broaden Method 7 as discussed on the call today, can you give us a process flow so we can understand exactly how a broader method (e.g., having the Applicant do a hash of its Experian credit code, or...), and discuss the security implications?

Doug - same request for the changes you previously indicated you wanted to make for Method 9 (Test Certificates).  Again, please include a brief analysis of why you think the method as amended provides adequate security and discuss the theoretical process flow, if that will help.

Peter - I'm not sure if you want to make any changes to the various edits you suggested today - but if yes, please do (with explanation) and recirculate.  Take a look at the proposed clarification Jeremy sent out after the call.

My plan would be to split your groups of changes (as you did) and put them forward on the next call as Issue 5,6,7, and 8 (or whatever).   I would send an Agenda-type email for the call.

Any other suggestions from the group about how to prepare for the next call?

<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/validation/attachments/20151217/9a89b8f5/attachment.html