On 9/1/2015 3:56 AM, Ryan Sleevi wrote:
On Mon, August 31, 2015 5:48 pm, Moudrick M. Dadashov wrote:
  I'm afraid there seems to be a bit misinterpretation of ETSI policies:
  EVCP, EVCP+, DVCP, OVCP are based on the same general requirements and
  have cumulative effect: higher level (e.g. EVCP) conformance assessment
  assumes lower level conformence while the opposite is not true.

  In other words if a CA has an EV audit, it assumes OVCP or DVCP
  conformance and doesn't require respective extra audits.

  Thanks,
  M.D.
1) That's mostly irrelevant for the topic at hand (code signing, email),
since EVCP/DVCP has to do with the EVGs/SSL BRs, which don't concern
themselves with, say, how to validate the information in an S/MIME
certificate. Are you conflating this thread with the SSC policy review,
perhaps, where that distinction may be more relevant?
most probably, Ryan, I thought the remark below is of general interest and needs to be clarified irrelevant to any particular Root inclusion application:

>The ambiguity regarding much of the TLS issuance practices, and in particular, the request for the "Website" trust bits without a corresponding audit for the issuance >practices related to website trust bits (DVCP/OVCP, equivalent conceptually to the "Webtrust for CAs - SSL Baseline Requirements v2.0" documentation), give me strong >concern.

BTW, in ETSI EN 319 411-1 (General requirements) BRs now are normative reference.

Thanks,
M.D.


2) That same argument has been made for WebTrust for CAs vs WebTrust for
CAs - SSL BRs with NetSec, of which the past discussion was that _both_
are required.


My point of raising this was that in the audit schemes required, there's
no "email trust audit", other than perhaps the ISO scheme (no CA is using)
or ETSI (with respect to QCP/QCP-SSCD), and the Mozilla requirements
regarding email trust are... spartan, to say the least :)


_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to