Nelson Bolyard wrote:
Frank Hecker wrote:
* OCSP. My understanding is that the Microsec practice of having a
separate root for OCSP is very problematic, particularly given the
inclusion of AIA extensions with OCSP URLs in end entity certificates.
As I understand it, Microsec is removing AIA
Frank Hecker wrote:
In accordance with the schedule at
https://wiki.mozilla.org/CA:Schedule
I am now opening the first public discussion period for a request from
Microtec Ltd to add the Microsec e-Szigno Root CA root certificate to
Mozilla. This is bug 370505, and Kathleen has produced an
Frank Hecker wrote:
* OCSP. My understanding is that the Microsec practice of having a
separate root for OCSP is very problematic, particularly given the
inclusion of AIA extensions with OCSP URLs in end entity certificates.
As I understand it, Microsec is removing AIA extensions with OCSP
the OCSP URI in the CA root IS a problem
Nelson, does NSS ever attempt to check the revocation status of a built-in
Root Certificate if that Root Certificate contains CRLDP(s) and/or OCSP
URI(s) ?
On Sunday 12 October 2008 16:40:11 Eddy Nigg wrote:
Eddy Nigg:
Except if Nelson thinks
I think we have a problem here! I wanted to make sure that the CA root
and intermediate CA certificates don't include OCSP AIA extensions and I
noticed the following when importing and examining the CA root...
In fact, our intermediate CA certificates also included an OCSP AIA
extension.
As
Rob Stradling wrote, On 2008-10-12 23:01:
Nelson, does NSS ever attempt to check the revocation status of a built-in
Root Certificate if that Root Certificate contains CRLDP(s) and/or OCSP
URI(s) ?
Good question. The answer is somewhat complex. :-/
As you may know, NSS has two separate
Rob Stradling:
the OCSP URI in the CA root IS a problem
Nelson, does NSS ever attempt to check the revocation status of a built-in
Root Certificate if that Root Certificate contains CRLDP(s) and/or OCSP
URI(s) ?
Adding to Nelson's commentCRL is checked at any level if provided
On Monday 13 October 2008 15:36:02 István Zsolt BERTA wrote:
snip
- The CA root includes the OCSP service URI in the AIA extension:
We accept that it is awkward that our root certificate includes the
OCSP AIA extension, it was a bad idea for us to include it.
Unfortunately our root
It is conformant IF and only IF the user (not the CA) chooses to trust
that responder. If the CERTIFICATE issued by the issuer says to go to
that responder for OCSP, but the responder's cert is not either
a) the the issuer's cert, or
b) a cert issued by the same issuer as the cert under
István Zsolt BERTA:
It is conformant IF and only IF the user (not the CA) chooses to trust
that responder. If the CERTIFICATE issued by the issuer says to go to
that responder for OCSP, but the responder's cert is not either
a) the the issuer's cert, or
b) a cert issued by the same issuer as
Eddy Nigg:
Except if Nelson thinks otherwise, removing the AIA OCSP service URI
solves this issue. More specific the Mozilla CA Policy calls for:
cRLDistributionPoints or OCSP authorityInfoAccess extensions for which
no operational CRL or OCSP service exists.
Therefor the OCSP reference
Eddy Nigg:
I think we have a problem here! I wanted to make sure that the CA root
and intermediate CA certificates don't include OCSP AIA extensions and I
noticed the following when importing and examining the CA root...
- The CA root includes the OCSP service URI in the AIA extension:
On 10/03/2008 12:43 AM, Frank Hecker:
I am now opening the first public discussion period for a request from
Microtec Ltd to add the Microsec e-Szigno Root CA root certificate to
Mozilla. This is bug 370505, and Kathleen has produced an information
document attached to the bug.
Besides the
István Zsolt BERTA wrote, On 2008-10-07 07:07:
As I see we all agree on the fact that a 'trusted responder' can exist
according to RFC 2560, and it is possible that an OCSP responder
certificate is under a separate root. (There are various scenarios for
providing OCSP service, it can be
I vote no on this proposal due to OCSP interoperability issues.
-Kyle H
On Sat, Oct 11, 2008 at 1:58 PM, Nelson B Bolyard [EMAIL PROTECTED] wrote:
István Zsolt BERTA wrote, On 2008-10-07 07:07:
As I see we all agree on the fact that a 'trusted responder' can exist
according to RFC 2560, and
A plain text version would be extremely helpful. Concerning machine
translation, I think I'll be alright ;-)
I have attached a plain text version to Bug 370505, it is available
here:
https://bugzilla.mozilla.org/attachment.cgi?id=342436
I still don't think a machine translation will be of any
Well, I don't get it. Your diagram at
http://srv.e-szigno.hu/menu/index.php?lap=english_ca_hierarchy shows
clearly that you are issuing intermediate CA certificates from the root,
but in the previous comment you claimed that the CA is only allowed to use
* signing qualified end-user
On 10/08/2008 05:07 PM, István Zsolt BERTA:
Thanks for that! I still would like to read your CP/CPS in English (even
if only machine translated). Is it somehow possible to facilitate that?
We would like to avoid having to translate these documents if
possible, as our CPS is over 100 pages
On Wed, Oct 8, 2008 at 8:07 AM, István Zsolt BERTA
[EMAIL PROTECTED] wrote:
Well, I don't get it. Your diagram at
http://srv.e-szigno.hu/menu/index.php?lap=english_ca_hierarchy shows
clearly that you are issuing intermediate CA certificates from the root,
but in the previous comment you
István Zsolt BERTA wrote:
[...]
We had good reasons to choose this solution. According to Hungarian
regulations, a qualified CA is allowed to use its private key for the
following two purposes only:
* signing qualified end-user certificates and
* signing CRLs.
As neither 'signing OCSP
According to the Directive, qualified signatures are equivalent with
handwritten ones, so only natural persons were meant to have qualified
certificates. However, in certain countries, electronic invoices have
to be signed with qualified certificates. This led to the situation
where - in some
On 10/07/2008 04:07 PM, István Zsolt BERTA:
As I read above, it currently does not pose a problem that there is an
OCSP URL in the AIA field of the certificate. If you think that this
shall become problematic in the future, we can modify the profile of
webserver certificates and remove the
Frank Hecker wrote, On 2008-10-02 14:43:
In accordance with the schedule at
https://wiki.mozilla.org/CA:Schedule
I am now opening the first public discussion period for a request from
Microtec Ltd to add the Microsec e-Szigno Root CA root certificate to
Mozilla. This is bug 370505,
Nelson B Bolyard wrote:
Frank Hecker wrote, On 2008-10-02 14:43:
In accordance with the schedule at
https://wiki.mozilla.org/CA:Schedule
Hi Nelson, Hi Frank,
Having read the EU directive at length, here are some perspectives.
I have not looked at the CA's request in question.
(I think
Dear All,
Let me reflect to some of the above points.
First of all, our public website is www.e-szigno.hu.
The webpage at https://srv.e-szigno.hu:/cgi-bin/editugyvedcsv.cgi
is a restricted page, it requires a client-side SSL certificate (with
certain values in the subject DN), so you should
István Zsolt BERTA wrote, On 2008-10-06 06:54:
OCSP:
-
According to section 2 of RFC 2560, there are three ways to operate an
OCSP responder:
All definitive response messages SHALL be digitally signed. The key
used to sign the response MUST belong to one of the following:
Concerning translation tools this search brought me to some
possibilities:
http://www.google.com/search?q=translate+hungarian+englishsourceid=navclient-ffie=UTF-8rlz=1B3GGGL_enIL280IL280aq=t
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: [EMAIL PROTECTED]
Blog:
On 10/06/2008 03:54 PM, István Zsolt BERTA:
We support the second option (Trusted Responder), where the requester
explicitly trusts the OCSP responder. (In our case the link of trust
is established by our CPS stating the the separate root can be trusted
for signing relevant OCSP responses.) I
Eddy Nigg wrote:
On 10/03/2008 12:43 AM, Frank Hecker:
* This CA is based in Hungary. Though it provides a lot of information
in English (including a helpful CA hierarchy diagram) unfortunately all
of its CPS documents are currently available in Hungarian only.
Frank, I think we should buy
On 10/06/2008 11:30 PM, Frank Hecker:
We can consider this in the longer term. In the short term Kálmán
Kéménczy of the Mozilla localization team for Hungary has confirmed the
accuracy of the translations in the Microsoft bug, and is willing to
check further translations as needed.
Frank,
I'll assume he meant Microsec instead of Microsoft, and work from
there. (bug 370505)
-Kyle H
On Mon, Oct 6, 2008 at 3:26 PM, Eddy Nigg [EMAIL PROTECTED] wrote:
On 10/06/2008 11:30 PM, Frank Hecker:
We can consider this in the longer term. In the short term Kálmán
Kéménczy of the Mozilla
On 10/03/2008 12:43 AM, Frank Hecker:
* This CA is based in Hungary. Though it provides a lot of information
in English (including a helpful CA hierarchy diagram) unfortunately all
of its CPS documents are currently available in Hungarian only.
Frank, I think we should buy some tool that helps
In accordance with the schedule at
https://wiki.mozilla.org/CA:Schedule
I am now opening the first public discussion period for a request from
Microtec Ltd to add the Microsec e-Szigno Root CA root certificate to
Mozilla. This is bug 370505, and Kathleen has produced an information
33 matches
Mail list logo
