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
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 anot
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 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 o
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 au
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 ag
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 ye
On 02/11/2009 06:59 PM, David E. Ross:
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
On 02/11/2009 06:43 PM, Ian G:
OK, I made some changes on the wiki and added these words:
https://wiki.mozilla.org/CA:Recommended_Practices#Recommended_practices
# (we rely on public documents only).
# If you do not publish the CP/CPS (not recommended), you will need to
publish an extract
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 an
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 follo
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 s
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; h
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 th
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 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 requ
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 me
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 pres
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 p
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'
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 langus
On 11 fév, 05:16, Frank Hecker wrote:
> Eddy Nigg wrote:
> > On 02/10/2009 10:06 PM, Frank Hecker:
> >> If you cannot publish the CPS because it contains private information, I
> >> suggest as an alternative that you provide some sort of official
> >>Certignadocument that summarizes the portions o
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 CA
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 feedbac
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 02/11/2009 06:16 AM, Frank Hecker:
My assumption was that if the material in the document was based on the
CPS then it would have been covered in the audit, since presumably the
audit was based on what was in the CPS.
Well no, than any CA can write whatever it feels in such a document
whi
26 matches
Mail list logo