Re: Microtec CA inclusion request

2008-10-17 Thread Frank Hecker
Nelson B Bolyard wrote: One final question: Does anyone know what Thunderbird 3 will be doing in terms of OCSP checks? Will this problem affect end entity certificates issued by Microsec for S/MIME use? I would expect it to be identical to FF3. They use the same PSM and NSS. Thanks for the

Re: Microtec CA inclusion request

2008-10-17 Thread Nelson B Bolyard
Frank Hecker wrote, On 2008-10-17 06:57: > Please refresh my memory here: As I understand it, the basic problem was > that if the Microsec root were included in Firefox (or other products) > and a user surfed to an SSL/TLS-enabled site with an end entity > certificate issued by Microsec (a cert

Re: Microtec CA inclusion request

2008-10-17 Thread Frank Hecker
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 exte

Re: Microtec CA inclusion request

2008-10-17 Thread Rob Stradling
On Wednesday 15 October 2008 15:14:10 István Zsolt BERTA wrote: > > Just a thought... > > If Nelson's investigation does find that the OCSP AIA extension in your > > Root Certificate is a problem for NSS, is there really anything to stop > > you from issuing a new Root Certificate? This new Root C

Re: Microtec CA inclusion request

2008-10-16 Thread Nelson Bolyard
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

Re: Microtec CA inclusion request

2008-10-16 Thread Frank Hecker
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

Re: Microtec CA inclusion request

2008-10-15 Thread István Zsolt BERTA
> Just a thought... > If Nelson's investigation does find that the OCSP AIA extension in your Root > Certificate is a problem for NSS, is there really anything to stop you from > issuing a new Root Certificate? This new Root Certificate could be identical > to your current Root Certificate except

Re: Microtec CA inclusion request

2008-10-13 Thread Rob Stradling
On Monday 13 October 2008 15:36:02 István Zsolt BERTA wrote: > > - 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 certific

Re: Microtec CA inclusion request

2008-10-13 Thread Eddy Nigg
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 (requ

Re: Microtec CA inclusion request

2008-10-13 Thread Nelson B Bolyard
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

Re: Microtec CA inclusion request

2008-10-13 Thread István Zsolt BERTA
> 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

Re: Microtec CA inclusion request

2008-10-12 Thread 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) ? On Sunday 12 October 2008 16:40:11 Eddy Nigg wrote: > Eddy Nigg: > > Except if Nelson thinks oth

Re: Microtec CA inclusion request

2008-10-12 Thread Eddy Nigg
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: OCS

Re: Microtec CA inclusion request

2008-10-12 Thread Eddy Nigg
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 MU

Re: Microtec CA inclusion request

2008-10-12 Thread Eddy Nigg
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 the

Re: Microtec CA inclusion request

2008-10-12 Thread 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 the cert under

Re: Microtec CA inclusion request

2008-10-11 Thread Kyle Hamilton
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,

Re: Microtec CA inclusion request

2008-10-11 Thread Nelson B Bolyard
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 pro

Re: Microtec CA inclusion request

2008-10-11 Thread Eddy Nigg
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 is

Re: Microtec CA inclusion request

2008-10-09 Thread István Zsolt BERTA
> 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

Re: Microtec CA inclusion request

2008-10-08 Thread Kyle Hamilton
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 y

Re: Microtec CA inclusion request

2008-10-08 Thread Eddy Nigg
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 pag

Re: Microtec CA inclusion request

2008-10-08 Thread István Zsolt BERTA
> 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 certi

Re: Microtec CA inclusion request

2008-10-07 Thread Eddy Nigg
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

Automated Qualified Signatures. Re: Microtec CA inclusion request

2008-10-07 Thread Anders Rundgren
>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

Re: Microtec CA inclusion request

2008-10-07 Thread István Zsolt BERTA
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 provided by a CA directly or by proxy responders, etc. but

Re: Microtec CA inclusion request

2008-10-07 Thread Jean-Marc Desperrier
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

Re: Microtec CA inclusion request

2008-10-06 Thread Kyle Hamilton
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 Mo

Re: Microtec CA inclusion request

2008-10-06 Thread Eddy Nigg
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. > Fra

Re: Microtec CA inclusion request

2008-10-06 Thread Frank Hecker
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 sho

Re: Microtec CA inclusion request

2008-10-06 Thread Ian G
Nelson B Bolyard wrote: > István Zsolt BERTA wrote, On 2008-10-06 06:54: >> 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

Re: Microtec CA inclusion request

2008-10-06 Thread Eddy Nigg
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.)

Re: Microtec CA inclusion request

2008-10-06 Thread Eddy Nigg
Concerning translation tools this search brought me to some possibilities: http://www.google.com/search?q=translate+hungarian+english&sourceid=navclient-ff&ie=UTF-8&rlz=1B3GGGL_enIL280IL280&aq=t -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom

Re: Microtec CA inclusion request

2008-10-06 Thread Nelson B Bolyard
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:

Re: Microtec CA inclusion request

2008-10-06 Thread István Zsolt BERTA
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 n

Re: Microtec CA inclusion request

2008-10-06 Thread Ian G
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

Re: Microtec CA inclusion request

2008-10-06 Thread Rob Stradling
On Monday 06 October 2008 08:53:01 Rob Stradling wrote: > IINM, FF3 by default has the "When an OCSP connection fails, treat the > certificate as invalid" tickbox set to *disabled*, meaning that most users > won't see browser warnings.  Therefore, IMHO, if Microsec don't think it's a > problem, th

Re: Microtec CA inclusion request

2008-10-06 Thread Nelson B Bolyard
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 370

Re: Microtec CA inclusion request

2008-10-04 Thread Eddy Nigg
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 hel

Microtec CA inclusion request

2008-10-02 Thread Frank Hecker
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 document