[cabf_validation] Validation proposal edits

[Ben Wilson]

Hi Richard,

 

I agree that it would be a good thing to adjust our approach to express security requirements for validation mechanisms.

 

Also, in your proposal you define the Authorization Domain Name as derived either by:

Removing the “*” label from a wildcard FQDN (see Section 3.2.2.6)

Using the name returned from a DNS CNAME request, or a chain of CNAME redirects

 

But we still haven’t fully addressed the ambiguity between a requested FQDN and the Domain Name that is registered with a Registrar.  

 

On the one hand, we could define an ADN to include the latter.  (Previously we’ve attempted to describe how to derive the registered domain name from the requested FQDN without running afoul of second-level domains.)

 

If we want to distinguish Authorization Domain Name from the Domain Name registered with a Registrar (and use the ADN only for some of the validation methods), then I think we need to be explicit.    

 

I’ll work on this a bit today, see what I can do in both areas, and circulate another draft.

 

Thanks,

 

Ben

 

From: validation-bounces at cabforum.org [mailto:validation-bounces at cabforum.org] On Behalf Of Richard Barnes
Sent: Thursday, July 23, 2015 10: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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/validation/attachments/20150725/f690fe8d/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4954 bytes
Desc: not available
Url : https://cabforum.org/pipermail/validation/attachments/20150725/f690fe8d/attachment.bin