t;
> The scheme we have now trades off maximum control for implementability.
> We have relatively coarse-grained controls, and then we rely on CAs to
> implement more fine-grained controls (e.g., using certificatePolicies,
> EKU, etc.). This means that CAs in theory could abuse t
gh review of
> this CA in place in order to guaranty conformance to the Mozilla CA
> policy? Because an upgrade to EV would tie this CA further into NSS I
> believe that such a review should be performed prior to any other step.
> I haven't invested a lot of time into this req
?id=401587#c16
>
> The details at the "Pending" page have been updated by Frank concerning
> this CA root. There are no objections to adding this root, but please
> note that this root will only issue EV certificates * and should be
> enabled for EV only, provided if and
On Wednesday 19 March 2008, Eddy Nigg (StartCom Ltd.) wrote:
> Rob Stradling:
> > Now, Frank has said "At present there are two subordinate CAs under
> > the "COMODO Certification Authority" root: "COMODO EV SSL CA" and "COMODO
> > EV SGC CA&q
not work with 4096 bit
> root.
>
> Ciao, Michael.
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
--
Rob Stradling
Senior Research & Development S
___
> > dev-tech-crypto mailing list
> > dev-tech-crypto@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-tech-crypto
>
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.o
On Wednesday 04 June 2008 21:32:17 Nelson B Bolyard wrote:
> Rob Stradling wrote, On 2008-06-04 04:45:
> > 2. Give each affected CA the opportunity to submit a replacement
> > 1024-bit RSA Root Certificate for inclusion in new versions of Mozilla
> > software. Each of t
dea is worth considering?
>
> Definitely worth considering.
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
--
Rob Stradling
Senior Research & Development Sc
On Thursday 05 June 2008 12:05:42 Eddy Nigg (StartCom Ltd.) wrote:
> Rob Stradling:
> >> Rob, in the past, any time that we have suggested that a CA issue a new
> >> root CA cert for any reason, even if only to change something minor,
> >> we've received
On Thursday 05 June 2008 12:59:13 Eddy Nigg (StartCom Ltd.) wrote:
> Rob Stradling:
> >> Additionally, most of the times the old and the new root will be both
> >> present in NSS for some time in order to allow a smooth transition,
> >> until the old root is being
that key anyway, and I would expect it to adhere to the
> CPS espoused by that key -- but that's how it was explained.)
>
> -Kyle H
>
> 2008/6/5 Eddy Nigg (StartCom Ltd.) <[EMAIL PROTECTED]>:
> > Rob Stradling:
> >
> > Sorry Rob, yes I missed that one. But w
/TLS
handshakes.
With this approach, Mozilla could even continue to accept new 1024-bit Root
Certificate submissions for the next few years (not that I'm advocating that,
of course!)
> Gerv
> ___
> dev-tech-crypto mailing list
> d
ailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
--
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, R
ve multiple candidate CAs having
their "public discussion periods" simultaneously?
Having watched this list for a number of months, I think I'm right in saying
that you're only allowing one at a time...in which case, how is having "more
people now working on CA-rela
On Thursday 17 July 2008 13:33:04 Frank Hecker wrote:
> Rob Stradling wrote:
> > Frank, is there any reason why you can't have multiple candidate CAs
> > having their "public discussion periods" simultaneously?
>
> No reason at all;
Thanks Frank. That's
On Thursday 17 July 2008 16:50:50 Frank Hecker wrote:
> Rob Stradling wrote:
> > Frank, in Bug #421946 Comment #15 you said:
> > "I'll proceed with the first public comment period once I figure out
> > where this request sits in the queue relative to other similar r
ficate did not verify for unknown reasons" message.)
>
> That is a bad sign, yes?
>
> It seems unwise for us to approve a trust anchor we can't even
> verify. I am quite sure we will eventually be able to verify it (or a
> corrected version if Comodo made a mistake), but
On Saturday 19 July 2008 19:30:51 Paul Hoffman wrote:
> At 11:04 AM +0100 7/19/08, Rob Stradling wrote:
> >I think that the ECDSA signature algorithms will only be supported in
> > OpenSSL 0.9.9 (not yet released) and above.
> >
> >Try a recent openssl-SNAP-2
look for that cert in the Authorities tab, and see if it is in the
> "Builtin Object Token" or the "Software Security Device".
> Also, look in the tab for "your certificates" and see if your code signing
> cert is listed there.
> Then repeat these steps with FF3 and see
odule."
Here's the FIPS 140-2 cert:
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#997
Of course, Windows XP/SP1/SP2 and Windows 2000 still don't support anything
stronger than SHA-1, so we're still stuck with using RSA-with-SHA1 in order
to maintain comp
uch as those on a ship)."
> This first public comment period will be for one week, and then I'll
> make a preliminary determination regarding this request.
>
> Frank
>
> [1] Fun fact: Within Hungary names are normally given in "Eastern order"
> (i.e., like C
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&
s or OCSP authorityInfoAccess extensions for
> which no operational CRL or OCSP service exists.
>
> Micorsec doesn't provide an operational OCSP responder when used in
> conjunction with AIA service URI. Over to Frank.
--
Rob Stradling
Senior Research & Development Scienti
erstand why anyone would check the revocation status
> of a trust anchor via CRL or OCSP.
>
> Regards,
>
> István
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-t
ozilla.org link above mentions a number of good advantages
w.r.t. activating the EV UI in Internet Explorer 7.
I'd be more than happy to answer any further questions.
> Regards,
> /Nelson
> _______
> dev-tech-crypto mailing list
>
t it is awkward to have an OCSP AIA extension
> in a root certificate.
>
> Regards,
>
> István
> ___________
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
--
Rob
;
> The Mozilla CA policy is my domain...indeed are there CAs which perform
> "key escrow" without the consent of the user (or without the user having
> explicitly asked beforehand)?
--
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
O
ing to postpone further consideration of the request. This
> will allow time to try to get the issues resolved, after which we can
> start a new public discussion period.
>
> Frank
--
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Offi
"minimum standards
for domain validation" initiative mentioned by that Reg article.
--
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, Registered in E
__
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
--
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +4
v
>
> ___
> dev-tech-crypto mailing list
> dev-tech-crypto@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
--
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel
ures. Reseller != RA.
>
> As such, I believe that it would be good to improve the Mozilla CA
> Policy and work towards better definitions and requirements. Even if the
> validation aspect is clearly defined and *required*, we might exclude
> certain practices outright. There are of
xtensions. Only 8 out of the 125 roots
> >in nssckbi have them.
>
> Now *that* is sad. I was hoping for closer to 50%. It does not make my
> argument wrong, just pretty moot.
>
> --Paul Hoffman
> ___
> dev-tech-crypto mailin
> the possibility that you have out of band information that the key is
> > not compromised and that you should be able to access the site.
>
> Yes, I view an expired certificate differently than a revoked one. There
> are indeed situations which require to access a site
On Monday 12 January 2009 11:00:59 Eddy Nigg wrote:
> On 01/12/2009 12:45 PM, Rob Stradling:
> > "and required by EV" ?
> >
> > Eddy, the EV Guidelines impose certain requirements on Intermediate CAs
> > *when* they are used, but AFAIK they don't mand
gt; Just a by-note on this one...It doesn't have to be in the CA Policy, but
> may be also in some by-laws or as we have it currently in the
> "problematic practices". This document is presented to every CA for a
> while already, so the CAs know about it, even if it's not
On Monday 12 January 2009 12:10:17 Eddy Nigg wrote:
> On 01/12/2009 01:20 PM, Rob Stradling:
> > The "Entrust.net Secure Server Certification Authority" is used for
> > legacy ubiquity only. Entrust and SecureTrust (aka Trustwave) have
> > different EV
d then use "non-compliance" to anything on that page as grounds
for pulling a previously approved Root Certificate from the trust pile?
On Monday 12 January 2009 11:26:03 Eddy Nigg wrote:
> On 01/12/2009 01:08 PM, Rob Stradling:
> > Eddy, I apologize if I'm misinterpreting you
y point wasn't *because* of Verisign, but *even* Verisign does it ;-)
OK.
--
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, Registered in England No. 040
s proposal of a "retroactive change to its (Mozilla's)
> > acceptance policy in the pile" in order to curtail the use of MD5 by CAs
> > who have *already* been accepted by Mozilla.
> >
> > Are you saying that Mozilla could change the Potentially Problema
gt; That list is not going to be long, but it *will* be valuable.
>
> OK, I'm not sure if this is/was the intention of Frank and the
> objectives of the Mozilla CA Policy.
>
> Nevertheless I suggest to start the work for a possible change to the
> policy in order to addres
e to introduce such a thing now, it could help us all in
the future when we need to move from SHA-1 to SHA-2, or from SHA-1/SHA-2 to
SHA-3, etc.
--
Rob Stradling
Senior Research & Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.7309
09 09:39:06 Ben Bucksch wrote:
> On 13.01.2009 09:48, Rob Stradling wrote:
> > I made a similar suggestion to ietf.pkix in October 2006. See...
> > http://www.imc.org/ietf-pkix/mail-archive/msg01964.html
> > ...and the rest of that thread, including...
> > http://www.im
licy could be
updated to require CAs to implement it?
On Tuesday 13 January 2009 14:50:32 Paul Hoffman wrote:
> At 9:55 AM +0000 1/13/09, Rob Stradling wrote:
> >Thanks Ben. Perhaps it's time to have another go at canvassing support
> > for the idea. In 2006, the PKIX WG didn
On Tuesday 13 January 2009 15:47:22 Paul Hoffman wrote:
> At 3:31 PM + 1/13/09, Rob Stradling wrote:
> >Why "almost every piece of PKIX validating software" ?
> >
> >I think it would be worth it if, at a minimum...
> > - the majority of CAs added t
ply be
ignored.
On Monday 19 January 2009 22:07:46 Nelson B Bolyard wrote:
> Rob Stradling wrote, On 2009-01-14 03:24 PST:
> > To the NSS developers: If there existed a standardized certificate
> > extension in which a CA could put additional signatures using different
> > alg
#x27;s an interesting thought. I've just posted a message to the
CA/Browser Forum mailing list to suggest that the Forum could invite server
software vendors to participate. If anything happens, I'll report back here.
--
Rob Stradling
Senior Research & Development Scientist
Com
g dates
> for the old roots. Rationale: This ensures that NSS will
> deterministically select the newer root in cases where there is a choice
> to be made. (Does this include the case when Firefox, etc., receive a
> full cert chain that includes the old root?)
>
> Is the above a co
> Here's a straw man:
>
> OK:
> 200 response with OK
> No response (network problems)
>
> Not OK:
> 200 response with revocation
> 400 response (OCSP responder actively denying response)
> 500 response (OCSP responder broken)
>
> What do people think? Putting 400 and
on't take this as complaining...just trying to put the info out
> there and understand the what's and why's. I appreciate all the hard
> work you do.
>
> Dave
>
> PS Nelson, I've been trying to email you directly and haven't been
> getting any response
On Tuesday 03 November 2009 14:29:43 Rob Stradling wrote:
> On Tuesday 03 November 2009 13:42:14 David Stutzman wrote:
>
> Hi David.
>
> Gentoo's NSS package supports ECC because I asked them to enable it:
> http://bugs.gentoo.org/247221
>
> I don't think it
09 18:49:57 Frank Hecker wrote:
> David Stutzman wrote:
> > Rob Stradling wrote:
> >> A question for the NSS devs:
> >> Is there any reason why NSS couldn't be changed to assume
> >> "NSS_ENABLE_ECC=1" by default?
> >
> > Yes...
> > htt
ld notes from Nelson.
AFAIK, this extension is still supported by NSS, but having said that I
wouldn't be surprised if Nelson replies to this message with words to the
effect of "that extension is deprecated, so please don't use it any more!"
Rob Stradling
Senior Research &a
but they are still useful
(e.g. the CA may subsequently detect that the key or hash algorithm used in
the certificate is weak).
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists
consider addressing some of these issues.
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
AFAIK, such configurations are not widespread today, but this would
change if/when ECC certs start to be used more widely.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
the union of all those CRLs be huge, even if they strip off certain
reason codes?
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 0
On 09/02/12 13:10, Gervase Markham wrote:
On 09/02/12 12:54, Rob Stradling wrote:
We've calculated that there are currently ~53,000 revoked Server
Authentication certs that were issued by Comodo's CA systems, each with
a serial number of 16 bytes (+ a leading zero byte if required
ermediate revocation
checking? (I'd expect the size of this data to be well under 100K !)
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
ry and then ii)
petition Mozilla and the NSS team to accept my patch and ship it in
Firefox 14 or sooner.
Thanks.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
2. I tried removing one of the affected UTN root-certificates and then
adding the relevant AddTrust->UTN cross-certificate as a built-in. This
didn't work either, presumably because the UTN root-certificate was for
some reason still listed as a Software Security Device.
ting
one of these two patches ASAP!
On 11/06/12 15:25, Rob Stradling wrote:
On 09/06/12 06:03, Wan-Teh Chang wrote:
Rob,
Please fix the bug in the "old" certificate verification library. Thanks.
Are you going to use the approach outlined by Nelson in bug 479508 and
bug 482153?
>
&
s? [2]
Thanks.
[1]
https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/ckfw/builtins/certdata.txt
[2]
https://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/src/nsIdentityChecking.cpp
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating T
On 18/04/13 13:54, Rob Stradling wrote:
On 20/10/12 18:33, Brian Smith wrote:
B2G (Firefox OS) does use NSS.
Brian,
I presume that Firefox OS trusts NSS's "Built-in" Root Certificates [1],
but what (if anything) does Firefox OS do for EV SSL?
Does Firefox OS import PSM'
x27;s Agreement, but you don't
need committer privileges in order to create a bug on Bugzilla, attach a
patch, etc).
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.
NSS/PSM)
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comod
On 16/08/13 16:18, Ryan Sleevi wrote:
On Fri, August 16, 2013 6:36 am, Rob Stradling wrote:
On 15/08/13 18:15, Chris Richardson wrote:
I believe this plan would have poor side effects. For example, if Apple
ships clients with a broken ECDSA implementation [0], a server cannot
detect detect
webserver wants to prefer ECDSA over RSA, then it can override the
browser-supplied cipher-suite order.
e.g. http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslhonorcipherorder
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.73
NSA has manipulated them
through their relationships with industry."
Does that affect your proposal?
Wasn't he talking about http://en.wikipedia.org/wiki/Dual_EC_DRBG#Controversy ?
No, he actually said he doesn't trust any ECC, but on the other
hand said that we should probably move t
7;t he talking about http://en.wikipedia.org/wiki/Dual_EC_DRBG#Controversy ?
No, he actually said he doesn't trust any ECC, but on the other
hand said that we should probably move to at least 500 bit ECC.
Kurt
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creati
ST ignore those cipher suites, and process the remaining
ones as usual."
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
to visit https://www.sonderbewilligungen.admin.ch.
Kaspar
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
netheless, that IPv6 omission means that this CA certificate is
unfortunately _not_ considered technically constrained according to the
Mozilla CA Certificate Inclusion Policy.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
--
dev-tech-crypto mail
ZbPXYWg6f8bbMA==
-END CERTIFICATE-
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com
COMODO CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor
al-requirements-version-2-0.aspx
[2] http://csrc.nist.gov/publications/fips/fips180-4/fips-180-4.pdf
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
[1] https://wiki.mozilla.org/CA:ImprovingRevocation
[2] https://www.imperialviolet.org/2012/02/05/crlsets.html
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
udFlare's Universal SSL uses ECDSA certs exclusively, so as of a few
weeks ago there are now _a lot_ of ECDSA certs in the wild.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
source for when we get those emails that say
"my cert isn't working in Firefox - why?"
Thanks to Andrew of SSLMate for putting the site together.
Gerv
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
--
dev-tech-crypto mailing list
lists.w3.org/Archives/Public/www-tag/2015Sep/thread.html
> [3] https://code.google.com/p/chromium/issues/detail?id=514767
> [4] https://bugzilla.mozilla.org/show_bug.cgi?id=1024871
>
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel
79 matches
Mail list logo