On 02/11/2009 06:20 AM, Frank Hecker:
Ian G wrote:
The policy says, we need published information, *eg* the CPS.
Not, CPS must be published.
Yes, exactly. We typically use the CPS and/or CP because almost all CAs
publish those documents; however there is no requirement that the
information
On 11/2/09 01:59, Eddy Nigg wrote:
It's perhaps an opportunity for me to explain why I'm here and why I
think others - specially representatives and employees of CAs - should
too.
OK, invitation accepted! I'm here to get a couple of fixes spliced into
the Mozilla DNA:
1. add a
Eddy Nigg wrote:
Well no, than any CA can write whatever it feels in such a document
which would be entirely non-binding and not audited.
Yes in theory, but I'm not convinced that this is a real risk in
practice. In the past we've had several cases where we've accepted
public statements by
On 02/11/2009 04:12 PM, Frank Hecker:
Yes in theory, but I'm not convinced that this is a real risk in
practice. In the past we've had several cases where we've accepted
public statements by CAs that went beyond what was in their CPS or CP.
In some cases these were clarifications of CP/CPS
At 5:09 PM + 2/4/09, Frank Hecker wrote:
1. To what extent do typical CPSs and CPs address this issue? In other words,
if we were to read the average CPS/CP, would it have language that would
unambiguously tell us whether our policy requirement were met or not? Or is
this something that's
At 6:23 PM -0800 2/4/09, Kyle Hamilton wrote:
There are two states in the NIST key state transition diagram that are
appropriate to this entire concept... compromised (state entered
when the private information associated with it -- i.e., the private
key and its passphrase, and has only one
kathleen95...@yahoo.com wrote:
As reported inhttps://bugzilla.mozilla.org/show_bug.cgi?id=408949#c27
this CA uses partitioned CRLs with CRL IDP extensions marked critical.
NSS does not handle partitioned CRLs at this time, and any CRLs with
critical CRL IDP extensions are rejected due to the
On 11/2/09 17:20, Paul Hoffman wrote:
At 5:09 PM + 2/4/09, Frank Hecker wrote:
1. To what extent do typical CPSs and CPs address this issue? In other words,
if we were to read the average CPS/CP, would it have language that would
unambiguously tell us whether our policy requirement were
On 11/2/09 02:19, Kyle Hamilton wrote:
That's a very good question. The most important part of the answer to
it would have to be: don't discount what they say.
Right.
However, I have a suggested strategy for reviewers: don't limit your
review to only those trust bits that are initially
On 11/2/09 05:20, Frank Hecker wrote:
Ian G wrote:
The policy says, we need published information, *eg* the CPS.
Not, CPS must be published.
Yes, exactly. We typically use the CPS and/or CP because almost all CAs
publish those documents; however there is no requirement that the
information
On 2/10/2009 8:16 PM, Frank Hecker wrote:
David E. Ross wrote:
On 2/10/2009 12:06 PM, Frank Hecker wrote:
If you cannot publish the CPS because it contains private information, I
suggest as an alternative that you provide some sort of official
Certigna document that summarizes the portions
On 2/11/2009 8:43 AM, Ian G wrote:
On 11/2/09 05:20, Frank Hecker wrote:
Ian G wrote:
The policy says, we need published information, *eg* the CPS.
Not, CPS must be published.
Yes, exactly. We typically use the CPS and/or CP because almost all CAs
publish those documents; however there is
If the information is critical for determining whether a CA's root
should be in the certificate store, then the document should be
audited.
In the case at hand, the issue is whether the root should be enabled
for E-mail validation. Because that issue is addressed in the CPS,
which we cannot
On 02/11/2009 06:33 PM, Ian G:
Whether or not the average CPS/CP has it is irrelevant. Let's look at
the standards that all CAs are supposed to be using, in this case RFC
5280:
Where in the policy does it mention RFC 5280?
I guess Mozilla strives to follow standards.
The CA is not
On 02/11/2009 07:12 PM, David E. Ross:
However, the last sentence should be modified to say:
* All documents supplied as evidence should be publicly available and
must be addressed in any audit.
I don't have (don't want) an account to update the Wiki.
I agree on this definition. Is there
On 02/11/2009 07:19 PM, Yannick LEPLARD:
So What should we do ?
Should we ask our auditor a certified document about our practices for
e-mail validation ?
Yannick, what are the chances to publish the CPS? Please note that all
CAs which have been included into Mozilla NSS during the last few
On 11/2/09 21:29, Eddy Nigg wrote:
On 02/11/2009 07:12 PM, David E. Ross:
However, the last sentence should be modified to say:
* All documents supplied as evidence should be publicly available and
must be addressed in any audit.
I don't have (don't want) an account to update the Wiki.
I
A notary does not verify content, a notary verifies identity.
What we need is an opinion (hey! using your own terminology, Ian,
that means AUDIT, and thus AUDITOR) that the document substantially
reflects the CP/CPS. If not an auditor, who would you suggest to do
it, given that a notary isn't
On 02/12/2009 01:37 AM, Ian G:
I object.
OK, then back to square one.
All documents supplied to Mozilla is within a Mozilla context.
Huuu?
Audit does an audit context. The two are different. Don't mix them; most
all audits are done according to defined audit criteria, such as
WebTrust
On 12/2/09 00:58, Kyle Hamilton wrote:
A notary does not verify content, a notary verifies identity.
Actually I meant a notary rather than a notary public, but the
difference is moot.
What we need is an opinion (hey! using your own terminology, Ian,
that means AUDIT, and thus AUDITOR) that
On 12/2/09 01:17, Eddy Nigg wrote:
On 02/12/2009 01:37 AM, Ian G:
Audit does an audit context. The two are different. Don't mix them; most
all audits are done according to defined audit criteria, such as
WebTrust or ETSI or DRC.
Yes, and Mozilla relies on them, period.
Yes, it's just
On 02/12/2009 01:58 AM, Kyle Hamilton:
...and has thus been bullied and
intimidated into accepting things into its root program that are
analytically damaging to the PKI
I believe - and that's another reason why I'm here, that this can be
reversed and improved. It requires some work and we've
22 matches
Mail list logo
