Nelson Bolyard wrote:
The 3 sets of claims used for SSL servers have names DV, OV and EV.
Of those, EV is well defined and documented. DV is pretty well understood
but I don't know of any document that defines it very well. OV is the
least well defined, which is why browsers do not give any
Paul Hoffman wrote:
At 4:59 PM -0700 9/23/08, Nelson B Bolyard wrote:
In finality, you have to pick a table from someone you believe has done a
really good job of analyzing it.
Right.
Given that NIST's tables are the basis
for the US Government's protection of its own secrets, which it
Ian G wrote:
Paul Hoffman wrote:
NIST's tables are for Federal Government unclassified applications
(see the table intro on page 65). NIST does not set the rules for US
Govt secrets; the NSA does. See
http://www.nsa.gov/ia/industry/crypto_suite_b.cfm.
Thank you Nelson! My point
Paul Hoffman wrote:
At 2:29 PM -0700 9/22/08, Nelson B Bolyard wrote:
Ian G wrote, On 2008-09-22 09:45:
* Naming - any constraints?
+ O
+ CN
+ OU - optional?
+ Firefox 3 displays O whereas Thunderbird displays CN.
What is the preference here?
Most
Nelson B Bolyard wrote:
Ian G wrote:
Nelson B Bolyard wrote:
The curiosity here is that the Certificate Policies extension may
not be shown prominently by software. As the point of the cert is
to make some claim to the user, and the essence of that claim is
somehow pertinent to the user's
Ian G wrote, On 2008-09-24 05:12:
Nelson B Bolyard wrote:
Ian G wrote:
Nelson B Bolyard wrote:
The curiosity here is that the Certificate Policies extension may
not be shown prominently by software. As the point of the cert is
to make some claim to the user, and the essence of that claim is
Nelson B Bolyard wrote:
Ian G wrote, On 2008-09-22 09:45:
Hi all,
Hi Ian,
This reply isn't complete. I'm just going to discuss the questions with
easy answers.
Thanks! This has cleared up a few of my questions at least. For
what it is worth, I have knocked up a starter set of notes
At 2:29 PM -0700 9/22/08, Nelson B Bolyard wrote:
Ian G wrote, On 2008-09-22 09:45:
Hi all,
Hi Ian,
This reply isn't complete. I'm just going to discuss the questions with
easy answers.
* the following extended key usage fields within roots:
+ Server Authentication
+ Client
(Sorry, missed this before sending my last message.)
At 8:11 PM +0200 9/23/08, Ian G wrote:
But, either way, the general result seems to be: a top level root
should not generally include an(y) EKU.
Correct. That follows from the RFC.
OK. That looks mostly for the EE certs, so I guess there
Paul Hoffman wrote:
At 2:29 PM -0700 9/22/08, Nelson B Bolyard wrote:
In CA certs, NSS understands the EKUs to mean this CA can only issue
certs valid for these purposes, rather than meaning that the CA cert
itself can be used for those purposes.
I would argue that that interpretation of
Ian G wrote:
Nelson B Bolyard wrote:
The curiosity here is that the Certificate Policies extension may
not be shown prominently by software. As the point of the cert is
to make some claim to the user, and the essence of that claim is
somehow pertinent to the user's choice, it is
At 4:23 PM -0700 9/23/08, Nelson B Bolyard wrote:
Paul Hoffman wrote:
At 2:29 PM -0700 9/22/08, Nelson B Bolyard wrote:
In CA certs, NSS understands the EKUs to mean this CA can only issue
certs valid for these purposes, rather than meaning that the CA cert
itself can be used for those
At 4:59 PM -0700 9/23/08, Nelson B Bolyard wrote:
In finality, you have to pick a table from someone you believe has done a
really good job of analyzing it.
Right.
Given that NIST's tables are the basis
for the US Government's protection of its own secrets, which it guards
jealously, I'm
Hi all,
CAcert is currently working up to create some new roots, as part of
their audit process. They've done some research and covered parts
of the requirements, but many open questions remain as to the
content of a future root.
http://wiki.cacert.org/wiki/Roots/NewRootsTaskForce
Below is a
Ian G wrote, On 2008-09-22 09:45:
Hi all,
Hi Ian,
This reply isn't complete. I'm just going to discuss the questions with
easy answers.
* the following extended key usage fields within roots:
+ Server Authentication
+ Client AUthentication
+ Secure Email
+ ...
15 matches
Mail list logo
