ssible development projects for the Mozilla Foundation to
fund.)
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
quot;probation", where their roots
were still included but sites chained to that root would be a warning
message of some sort. (As always, if people think something like this
would be worthwhile, we can always consider funding the work.)
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
ot;EV-capable", by issuing it a CA certificate with the
necessary EV policy OID(s) included.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
.g., based
on NSS enhancements and fixes already planned, or those that might be
possible assuming additional funding from the Mozilla Foundation or
whomever).
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lis
real any possible threats actually
are, and whether they would rise to the level that would warrant denying
a request for inclusion. That also includes looking at the issue of the
standards we're applying to WISeKey vs. what's been applied in the
my view of the situation one way or another. I'll look again through the
information WISeKey has provided already (which is a fair amount), and
then ask a few more questions if needed.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypt
Go Daddy's request, as per the mozilla.org CA
certificate policy:
http://www.mozilla.org/projects/security/certs/policy/
and plan to officially approve this request after a public comment period.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
__
the extent it addresses this case) should reflect these differences.
(Thus, for example, we might not impose exactly the same audit
requirements as we would for other CAs.)
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev
what
the practical effect would be of your suggested policy change.
> I might even suggest that Mozilla's root CA policy be amended to explicitly
> disclaim any responsibility for security of users who rely on the certs in
> Mozilla's root CA list
previous message).
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
n Blackman of
WISeKey about that), but note that the constraints are discussed in
section 2.1.4 of the WISeKey "technical security controls" doc. (It's
linked to from the WISeKey entry in the pending list.) Note that in this
context we are talking about "standard" c
eration; I've been
and remain reluctant to hold new CA applicants to standards that aren't
clearly spelled out in our policy, if we're not yet applying those same
standards to older CAs.)
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
root.
This is really a question for the future, but it might be useful to
think about for long-term NSS/PSM planning. It's sort of a special case
of the general problem of having NSS/PSM be able to take special actions
(either built-in or user-specifie
use
of separate roots (or separate intermediate CAs) for EV vs. non-EV
certs. Granted, we don't currently have a preferences UI to allow end
users to select these options, but that's ultimately our problem, not
the CA's.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
_
save time I want to start the comment period
now.)
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Paul Hoffman wrote:
> Will there be a cutoff for when Mozilla requires audits against the
> final guidelines instead of allowing draft guidelines?
Yes, per the revised policy the cutoff date is June 30.
Frank
--
Frank Hecker
[EMAIL PRO
Frank Hecker wrote:
> I've therefore proposed a new revision 1.2 of the policy to accept all
> valid WebTrust EV audits, whether against the draft or final criteria
> and guidelines, for all CA EV applications submitted on or before June
> 30 of this year:
>
> https
save time I want to start the comment period
now.)
Note that the WebTrust EV audit for Digicert was done under the final EV
guidelines and WebTrust EV criteria, so its acceptance under our policy
is not dependent on making the proposed policy change discussed in my
earlier message.
Frank
--
previous message.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
lla.mozilla.org/show_bug.cgi?id=413545
Based on comments thus far this seems to be a relatively
non-controversial change, so I'm going to go ahead and make it after one
final call for comments.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech
Frank Hecker wrote:
> The first step is getting a complete list of all
> current EV-related CA requests. I believe the following is the complete
> list, based on searching bugzilla:
I've got several of these listed now on the pending list, as noted
below; I 'll get the rema
Nelson Bolyard wrote:
> Yes, Sorry. Bug 413375 .
See my comments in the bug. The bottom line is that IMO we need more
information before we can reasonably discuss policy changes related to
the issues you raise.
Frank
--
Frank Hecker
[EMAIL PROTEC
an for most common query"; it's resolved FIXED. Do you mean some other
bug?
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Eddy Nigg (StartCom Ltd.) wrote:
> Frank Hecker wrote:
>> To make this more concrete, I'll file a bug with a proposed policy
>> change to reflect this line of thinking.
> OK. Please send me the bug number for reference, thanks!
https://bugzilla.mozilla.org/show_bug.cg
delines to both be acceptable (at
least until some future date), and we wouldn't need to determine exactly
which version of the guidelines was used when.
To make this more concrete, I'll file a bug with a proposed policy
change to reflect this line of thinking.
Frank
--
Frank Hecker
e at some point in
the future, maybe July 1 2008; after that we'd revert the policy to
specify the final criteria and guidelines only, to emphasize that the
drafts are obsolete and deprecated.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-te
ed actively in CAB Forum meetings and related discussions. IMO
they have as good a grasp of the relevant issues as Gerv or I.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozill
sue end entity certificates
directly, but has subordinate CAs which do so. (As you note, this is a
common setup in many countries.) That's why Gerv and I invested a fair
amount of effort trying to determine what these subordinate CAs actually do.
Frank
--
Frank Heck
Eddy Nigg (StartCom Ltd.) wrote:
> Frank Hecker wrote:
>> (Because after all our ultimate concern is users'
>> security, not guidelines and criteria per se.)
> Well, this is a dangerous statement, because CAs are all about policies
> and criterion, security is only
Here I could use help both to do the triage and also to follow
up and get the relevant questions asked and answered regarding the CAs
we're looking at first.
Does this help answer your question?
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
, please submit them now.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
eria?
This was stated by MIC in their public statement. I don't know if they
used the actual WebTrust criteria themselves, or something else judged
equivalent; this is worth asking about, and I have done so.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
the situation was here, please feel
free to ask in the bug.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Frank Hecker wrote:
> The first step is getting a complete list of all
> current EV-related CA requests. I believe the following is the complete
> list, based on searching bugzilla:
Here's a quick take on each request. The principal parameters I looked
for are as follows:
* I
to this
group and/or email me.
Next step is figuring out the basic parameters for each request. Till
later...
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
then.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
, or know of facts which might influence this decision, please
make them known before then.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
ite a while (since Gerv started doing them) and don't know how
responsibilities might have shifted since then.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/li
Frank Hecker wrote:
> I've therefore signaled my approval of this
> application in bug 380635, and will proceed to file an NSS bug for
> inclusion of the actual root CA certs.
Filed bug 410821 for inclusion of the TURKTRUST certs into NSS:
https://bugzilla.mozilla.org/show_bug
Frank Hecker wrote:
> TÜRKTRUST has applied to add two root CA certificates to the Mozilla
> root store, as documented in the following bug:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=380635
>
> and in the pending certificates list here:
>
> http://www.mozil
Frank Hecker wrote:
> Therefore absent objection tomorrow (Friday November 30) I am going to
> officially approve inclusion of the three SwissSign root CA
> certificates, and proceed with the other steps needed to get the certs
> into NSS.
Well, I was a week late, for which I a
Nelson B Bolyard wrote:
> Frank Hecker wrote:
>> For the record, I am pretty sure that we have CAs already in the root
>> list that have issued test certs under their hierarchies. IIRC the last
>> instance of this I saw was a CA that had a subordinate CA used to
>>
Frank Hecker wrote:
> SwissSign has applied to add three root CA certificates to the Mozilla
> root store, as documented in the following bug:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=343756
>
> and in the pending certificates list here:
>
> http://www.mozil
ch strings by
CAs. I've made a note of this on the "CA recommended practices" wiki
page, as a reminder.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
e at least the understanding
> that the CP/CPS should be in English...
I'm happy to make it a recommendation that CAs provide a CPS in an
English version; I'm not ready (at least, not now) to make it a
requirement. This needs more discussion IMO.
Frank
--
Frank Hecker
[EMAIL PROT
ose certificates will probably be seen primarily by users in those
countries. Since most of those users won't speak English, it makes sense
for domain names, names in certificates, and so on, to be in their
native language and the associated character set
t; 3) There is currently no definition of how recently an audit must have been
> performed by a trusted third party, only that one must have been performed.
This is an issue worth discussing; I don't have any finished thoughts on
it right now.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
I would feel more comfortable.
See my previous message; the English version of the current CPS is at
http://www.turktrust.com.tr/pdf/cps_third.pdf
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.
CPS provided by this CA as in attachment
> https://bugzilla.mozilla.org/attachment.cgi?id=286696 is in PDF format I
> think
Please don't use the CPS documents attached to the bug. The English
version of the CPS is now available in PDF format directly from the
TÜRKTRUST site:
http
have any objections, or know of facts which
might influence this decision, please make them known before then.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinf
document.
I think a similar procedure of independent confirmation is worth doing
in other cases where CAs provide documents like this, especially if the
document in question is the sole or primary source of information we
have relating to independent audits and evaluations.
F
ain
based on WHOIS data, then do an identity check to verify that the
certificate applicant is that person. Plus they do the email check.
If you have further questions please feel free to ask them in the bug; I
think Melanie Raemy of SwissSign is following the bug traffic but not
the newsgroup
ld be very useful to have the NSS
developers' perspectives on EV as applied to object signing, so we can
do a better job of deciding what the official Mozilla position should in
fact be.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto m
think we necessarily
need originals of the audit letter and other documents; notarized copies
should suffice.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
then.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
From our point of view it would be perfectly fine if the audit criteria
encompassed both ETSI TS 101.456 and ZertES, as long as the requirements
of ETSI TS 101.456 were satisfied.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mai
"Details SwissSignAG" page seems pretty clear that ETSI TS 101.456
was (one of) the criteria used in the audit. I'm confused by your
question: Is your concern that SAS/KPMG used a variant of ETSI TS
101.456, or a subset of it, or some other practice that did not actually
amount to
s a document comparable to the WebTrust
for CAs "auditors' report on management assertions" (or whatever it's
called). However you can ask Melanie Raemy of SwissSign about that; just
post a comment in bug 343756 and she should see it.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
rom the NSS team for temporary EV upgrades and related changes in order
to do testing of the NSS EV code (e.g., for Firefox 3 beta). Such
approval does not constitute approval for permanent upgrades, which will
be handled per policy as discussed above.
Frank
Frank Hecker wrote:
> OK, absent any objections my plan is to go ahead and commit this change
> later today or tomorrow.
Done. The 1.1 release of the Mozilla CA certificate policy is now live
at the standard URL:
http://www.mozilla.org/projects/security/certs/policy/
Thanks to Eddy
dinate 2, even though the end entity cert may have a policy OID
meant to indicate EV-ness, the subordinate 2 CA lacks that policy OID
(or the anyPolicy OID) and so the EE cert will fail the "EV test".
So AFAICT there's no need for NSS to pre-load the subordinate 1 CA cert.
Fra
ous members of the CAB
Forum, and documented in (e.g.) section 7 of the EV guidelines.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
d policy changes; based
on the results of those discussions I think we now have consensus on a
1.1 policy revision, and I want to finish this up so we can proceed to
invite CAs to submit requests for EV treatment for their CA certs.
Frank
--
Frank Hecker
[EMAIL P
there is no
EV certificate extension per se. The EV policy OID is just added as
separate metadata to be associated with the pre-loaded root CA
certificate; there is nothing in the CA certificate itself that is
specifically EV-related.
Frank
--
Frank Hecker
[EMA
requests
from CAs that have explicitly asked to be included. If I invite a CA to
have their EV root be included (or an existing root be marked as
EV-capable), and they don't respond to that invitation, then I likely
won't feel any obligation to do anything about their E
Eddy Nigg (StartCom Ltd.) wrote:
> Frank Hecker wrote:
>> I think I understand what you mean here: Are you saying that the
>> WebTrust EV criteria in effect incorporate the traditional WebTrust
>> criteria by reference, since a WebTrust EV audit has as a prerequisite
>
Eddy Nigg (StartCom Ltd.) wrote:
> Frank Hecker wrote:
>> Your implication here is that the CAB Forum EV guidelines can be used
>> as stand-alone guidelines comparable to the other criteria referenced
>> in section 8 (WebTrust for CAs, ETSI TS 101 456 and 102 242, and ANS
cy then I'll solicit requests from
VeriSign and everyone else who'll be issuing EV certs, and those
requests will be handled in the normal way.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@l
erning the policy update and intend to this soon.
OK, looking forward to your comments.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
timely manner.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
om/>. <https://www.paypal.com/> shows this as well.
Also, you can try these in Vista/IE7 to see how they're handled there
vs. XP/IE6.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://
parate known root (PCA3 G1).
Note that the VeriSign case is distinct from the case where an existing
root CA cert is simply marked with EV metadata. I don't know which (if
any) CAs plan to take this approach.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
ertificate path processing in these cases can get tricky
because there two valid paths (up to the existing root and up to the new
EV "root"); hence the need to get some good testing of these scenarios
well before Firefox 3 final release.
Does this answer your question?
Frank
--
F
root entirely. If it is chained to an existing root
> in
> NSS, we don't need to add it to NSS.
Not so, as I understand it. See my message I just posted, and blame
blord if I have it wrong :-)
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
d
erefore my priority is to get the 1.1 revision of the Mozilla
CA certificate policy in place as soon as possible and proceed
immediately to consider other CAs who have EV roots they'd like to include.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
de
Frank Hecker wrote:
> However the general changes to be made to the policy are
> clear, even if the language is final,
s/final/not final/
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozil
Eddy Nigg (StartCom Ltd.) wrote:
> Frank Hecker wrote:
>> After thinking about it, I think it may be possible to do this just by
>> adding a final paragraph to section 6 of the current policy:
> Shouldn't be this be part of section 8 as this is a criteria for CA
> oper
Frank Hecker wrote:
> I've filed a bug against myself (399214) to update the current Mozilla
> CA certificate policy to address the issue of "extended validation"
> certificates.
After thinking about it, I think it may be possible to do this just by
adding a final parag
icy on solving the problem of defining a
WebTrust-equivalent EV audit regime. Second, I would prefer that we use
the standard CAB Forum mechanisms to try and address this issue.
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto ma
Frank Hecker wrote:
> I wasn't implying that we would require an audit; see below.
Sorry, s/would/would not/
(Those double negatives will trip you up every time :-)
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
Gervase Markham wrote:
> Frank Hecker wrote:
>> My initial conclusion is that we don't need to reference the WebTrust
>> draft document, but can confine ourselves to referencing the relevant
>> section(s) of the guidelines.
>
> Without an audit, how do we assur
quot; to
the policy itself. My primary goal is to address the EV-related policy
changes, and to do so as expeditiously as possible.
Anyway, if you have comments on this general topic please feel free to
post them here. In the meantime I'll work to come up with an initial
draft of proposed
cal WebTrust-authorized auditor.
Clearly in the case of a totalitarian state we wouldn't have such
confidence, so I think the North Korean example is a red herring. Per
our policy we always reserve the right to bar a CA from inclusion if we
think things are "hinky" (to use o
nt thinking on modulus
length I think we should do two things:
1. Stop accepting new 1024-bit CA certs immediately (or at least very soon).
2. Set a target date (or dates) for removal of legacy 1024-bit CA certs.
(This can also encompass looking at intermediate CA certs and related
issues, of c
traints information could be stored as metadata with the root CA.)
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
se requirements and mention your
use of NSS, etc., in other contexts I'm sure the NSS/NSPR/JSS developers
wouldn't mind the publicity.)
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozil
and congratulations on getting closer to
final validation! You didn't mention the exact NSS release being
validated in this message, but your last message on this topic
identified it as 3.11.4 (in case anyone else besides me was interested
in this).
Frank
--
Fran
My apologies for the semi-spam, but I thought that readers of this forum
might be interested in this NIST-sponsored PKI-related workshop. (I'll
most likely attend it myself, especially since it's not that far from
where I live.)
Frank
--
Frank Hecker
[EMAIL PROTECTED]
--- Beg
such patent issues in the US
that I'm aware of, but I can't speak for other countries.)
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
leversafe.org/forums/viewtopic.php?t=95
Based on other posts I've read, the lead developer for Cleversafe's use
of NSS appears to be Jason Resch; for contact info see
http://www.cleversafe.org/wiki/Cleversafe_Contributors
IIRC the person asking questions earlier in m.d.t.crypto
ersafe.org/
Besides the general idea, I found it interesting that they're using NSS
as part of their product. (In fact, someone from Cleversafe was on this
forum a while ago asking questions about static linking of NSS.) Also
note that they're using NSS code under the GPL licensing optio
he user.
From the Firefox preferences: Advanced -> Security -> Verification
Frank
--
Frank Hecker
[EMAIL PROTECTED]
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Frank Hecker wrote:
Frank Hecker wrote:
As I noted in an earlier message, Geotrust has applied to have three
more root CA certificates added; this is basically to support a
multi-year migration away from their current Equifax root certs. See
bug 294916 for details:
http
Frank Hecker wrote:
As I noted in an earlier message, Geotrust has applied to have three
more root CA certificates added; this is basically to support a
multi-year migration away from their current Equifax root certs. See bug
294916 for details:
http://bugzilla.mozilla.org/show_bug.cgi?id
Frank Hecker wrote:
To echo my comments in bug 342470:
My apologies for not following up on this before now. As far as I'm
aware all questions relating to Swisscom have been answered, and they
appear to be in compliance with our CA policy, I am formally approving
their request to have
Frank Hecker wrote:
I'm now soliciting comments on the CA application from Swisscom, bug
342470:
https://bugzilla.mozilla.org/show_bug.cgi?id=342470
Swisscom is a public commercial CA based in Switzerland; see the bug
report and my CA certificate list page for more information.
Swi
Frank Hecker wrote:
Nelson B wrote:
Frank Hecker wrote:
In looking at Geotrust's request to add more root CA certs (bug
294916) I happened to notice that Geotrust offers a somewhat similar
service, [snip]
From the product description it appears that one domain goes in the
CN attribut
Frank Hecker wrote:
Nelson B wrote:
Frank Hecker wrote:
In looking at Geotrust's request to add more root CA certs (bug
294916) I happened to notice that Geotrust offers a somewhat similar
service, [snip]
From the product description it appears that one domain goes in the
CN attribut
I've
misinterpreted the description at
http://www.geotrust.com/products/ssl_certificates/power_server_id.asp
Thanks in advance for any info you can provide on this.
Frank
Nelson B wrote:
Frank Hecker wrote:
In looking at Geotrust's request to add more root CA certs (bug 294916)
I happened
Nelson B wrote:
Frank Hecker wrote:
In looking at Geotrust's request to add more root CA certs (bug 294916)
I happened to notice that Geotrust offers a somewhat similar service,
[snip]
From the product description it appears that one domain
goes in the CN attribute and the re
301 - 400 of 437 matches
Mail list logo
