Gervase Markham wrote:
> (Can we use section numbers rather than page numbers? Because there are
> two sets of page numbers - document page numbers and those on the pages
> themselves. Thanks.)

Sorry, was being lazy.

> Heikki Toivonen wrote:
>> p. 11: Warranties
>> * What are the reasonable steps? Were they all described later in the
>> doc?
> 
> In general, if the draft has language like that, it means that the
> WebTrust auditor will check they are doing it in a sane manner. Does
> that answer your question?

Hmm, ok, that answers my question, but I'd rather it was spelled out in
more detail, like at least listing some minimum steps.

>> p. 15: Domain name
>> * Would it be possible to go with dNSName only?
>> * If both commonName and dNSName are present, how is this situation
>> handled?
>> * Wildcards are not allowed, but are multiple dNSNames allowed?
> 
> The technical details are really being overseen by Bob Lord, Bob Relyea
> and Nelson Bolyard, who joined the CA/Browser Forum mailing list a few
> months ago. I believe there was some discussion on this mailing list
> about this issue, but I didn't follow it.

I think those issues need to be clarified in the the spec. Would be nice
if Bob et. al. could clarify on mozilla.dev.security as well.

>> p. 17: validity period
>> * Where does 27 months come from?
> 
> I believe it's probably "2 years plus some wiggle room for issue in
> advance".
> 
>> * The documents listed all have 1 year expiration, so how is 27 months
>> even possible?
> 
> I'm not sure what you mean by this.

The spec listed some documents that can be used to verify identity etc.
and in all cases they mentioned that the document is good for one year.
So I don't see how that can lead to certificates with longer validity
period than one year... Unless it was meant that the documents can not
be older than a year at the time of EV cert application.

>> p. 21: reporting
>> * There doesn't actually seem to be much incentive for the applicant to
>> report if they have to pay for the new certificate as well. You could
>> make it so that the CA would give a free corrected certificate for the
>> remainder of the old one, or you could have the renewal process check if
>> the old information is correct and if not, refuse to supply a new EV
>> certificate until a year later. I am in favor of the first as the latter
>> leaves a window of unsafe/inaccurate information.
> 
> I guess some CAs could offer free updates as a market differentiator.
> I'm not sure we could refuse to supply based on past bad behaviour,
> because that would require a conspiracy among the CAs not to serve a
> particular "blacklisted" customer.

Right, but my concern is that unless there is an incentive for the
applicant to report quickly, they won't and we have a weaker system for
it. The spec could spell this out so that they would have an incentive,
either carrot or stick or both.

>> p. 26: verifying private registration
>> * I think it needs to be MUST to contact the applicant even in the case
>> of private registration to confirm the identity of the applicant. 
> 
> So you are objecting to the possibility of 18 b) 1) a)?

I am objecting to the wording of 18 b) 1) c), and I think CAs MUST
contact the applicant even if they used private registration. Otherwise
private registration seems like a convenient way of avoiding some CA
scrutiny.

>> p. 27: Mixed character set
>> * This leaves me a bit uneasy feeling. Are there no standards for mixed
>> charset domain names? Must we rely on domain registrar's judgement?
>> Could there be any algorithms to compare these to other High Risk domain
>> names?
> 
> I, in fact, argued for the removal of anything about this because it's
> out of scope for this forum. Protection against homograph spoofing is
> important, but if we have lots of different layers with different rules,
> it's going to cause problems.
> 
> Mozilla already has an effective anti-homograph-spoofing system (modulo
> bugs).

I might be ok to leave this out too, but I think in that case I would
expect here to be a reference to other specifications on how these are
handled. The reason I like them here is because my assumption is that a
CA would do a more thorough job of it than a domain registrar.

Mozilla having an effective system means nothing for the EV spec.

-- 
  Heikki Toivonen
_______________________________________________
dev-security mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security

Reply via email to