On 12/1/09 22:03, Kyle Hamilton wrote:
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.
In principle, yes. Which is to say, Problematic Practices aren't of any
weight, they are just hints as to what sticky questions a CA is going to
receive.
Investigating along these lines, what would the procedure be for
getting Mozilla to update the Certificate Policy with explicit
(Note freudian slip above, it's CA Policy... :)
algorithm acceptance/deacceptance policies?
First figure out whether it is a good idea. I'm "-1" on that. This is
CA business, not Mozo business. It is what CPS/CPs are for.
Now, I for one do not disagree with the core frustration of the people
here. But, replacing the CPS/CP function of a CA is not a good idea.
To start telling the CA what hash functions to use is to change the PKI.
The CPS tells the relying party what it does, that's its job.
Reference, Chokhani:
===============
4.6.1. Key Pair Generation and Installation
Key pair generation and installation need to be considered for the
issuing CA, repositories, subject CAs, RAs, and subscribers. For
each of these types of entities, the following questions potentially
need to be answered:
...
5. What are the key sizes? Examples include a 1,024 bit RSA modulus
and a 1,024 bit DSA large prime.
===============
http://tools.ietf.org/html/rfc3647#section-4
Although it doesn't say it, it is hard to conclude otherwise.
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".
Right. No change needed, just do it.
iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
