On Mon, Jan 12, 2009 at 5:59 AM, Rob Stradling <rob.stradl...@comodo.com> wrote:
> On Monday 12 January 2009 13:30:35 Kyle Hamilton wrote:
>> I believe that this is not only exactly what he is saying, but also
>> exactly what must be done.
>>
>> Once a "potentially problematic practice" is shown to have moved from
>> "potential" to "actual", it is a problematic practice. Once that
>> happens, it must be addressed.
>
> I fully agree.
>
> Right now, as I see it, we have...
> 1). "potential" - The "Potentially Problematic Practices" wiki page.
> 2). "actual" - The Mozilla CA Certificate Policy.
>
> So when a problem "is shown to have moved from 'potential' to 'actual'",
> surely the way to address it would be to update the Mozilla CA Certificate
> Policy and require CAs to conform to the new version (or risk having their
> Root(s) pulled) ?
I am inclined to agree.
Investigating along these lines, what would the procedure be for
getting Mozilla to update the Certificate Policy with explicit
algorithm acceptance/deacceptance policies?
It would be helpful for everyone if a full list of the algorithms that
NSS supports were available somewhere. Since that list defines "every
possible algorithm" (as relates to NSS, anyway), there can also be
list of algorithms and key sizes which are considered "too weak" for
CAs.
This kind of list ("weak algorithms") could also be usefully embedded
in the NSS code, but reliably warning on exceptions would likely
require an API change. (Instead of returning an int-as-int, one
possible way to handle it might be returning a bitfield-as-int, with
one bit stating 'there's a warning, you need to get the description of
the warning by calling another API function'. This would be very much
like OpenSSL's get_last_error mechanism, or Winsock's
WSAGetLastError.) (Note to the devs: would this be enough of a reason
to make an API change, in addition to the change in semantics for
startup/shutdown required for multiple NSS clients in a single
process?)
The basis for the "Potentially Problematic Practices" document is to
determine things which MAY (depending on the threat model employed by
the CA and other mitigating factors in place) be determined to be
problematic with regards to any given CA.
Putting aside political arguments (and everything related to policy is
political), I think that this situation could perhaps be better fixed
simply by stating "you can create certificates using any algorithm you
want, but we're not going to allow your MD5-signed certificates to
verify with our software".
-Kyle H
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
