[cabf_validation] Validation proposal edits

[kirk_hall at trendmicro.com]

Richard, I sort of understand your proposal (security requirements + specific examples), but not sure.

Can you give us one or two examples?  (We won’t hold you to the details.)

My first concern is that a general requirement (security requirements above) might not be auditable – auditors need very clear, hard requirements to audit against.  If you give us an example or two, we can check with Don Sheehy, a WebTrust auditor from Deloitte, who helps us on audit issues – ask him if it would be auditable.

Kirk

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of Richard Barnes
Sent: Thursday, July 23, 2015 9:50 AM
To: validation at cabforum.org
Subject: [cabf_validation] Validation proposal edits

Hey guys,
Last week, I promised edits on the validation proposal in about a week.  I pulled the proposal into a Google doc, and started making some edits.  I haven't done anything with the specific validation methods, but I've done some stuff with the preamble that I would appreciate the group's feedback on.

https://docs.google.com/document/d/1_myTluMpMD7vaBkjVEIFiI1Q8u7tWuzlvEvLF3oDCZ8/edit
Allow me to riff for a moment about the specific validation mechanisms:

I'm concerned about the descriptions of the more technical mechanisms (3, 5, 6, 7, 8, 9).  On the one hand, they're general enough that one could implement them insecurely, and on the other hand, they're specific enough that they rule out some valid techniques.
It seems like what we really need for this document to do is express the security requirements for validation mechanisms, in a specific enough way that it's difficult for CAs to do bad things.  If we only do that, though, I'm worried that we won't be giving auditors enough tools to evaluate CAs; we'll be requiring them to do technical analysis on CAs' validation mechanisms to determine whether they meet the security requirements.  So it would be good to provide specific examples of acceptable techniques.

It seems like if we do those two things (security requirements + specific examples), we will strike a better balance between enhancing security and allowing flexibility.  It basically gives CAs a choice between a fast path and a slow path -- either use one of the approved methods, or do a lot of work to convince your auditor that your custom thing is OK.
Does that seem like a sensible direction?
--Richard


<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/20150725/401dbd41/attachment.html