Kyle Hamilton wrote:
> RFC 2818 ("HTTP Over TLS"), section 3.1.
Definitely not a PKIX RFC. "Removal of support for wildcards" doesn't
need any PKIX action.
Kaspar
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
RFC 2818 ("HTTP Over TLS"), section 3.1.
-Kyle H
On Mon, Feb 23, 2009 at 10:09 PM, Kaspar Brand wrote:
> Kyle Hamilton wrote:
>> Removal of support for wildcards can't be done without PKIX action, if
>> one wants to claim conformance to RFC 3280/5280.
>
> Huh? Both these RFCs completely step out
Kyle Hamilton wrote:
> Removal of support for wildcards can't be done without PKIX action, if
> one wants to claim conformance to RFC 3280/5280.
Huh? Both these RFCs completely step out of the way when it comes to
wildcard certificates - just read the last paragraph of section
4.2.1.7/4.2.1.6. PKI
Okay, meta-discussion here...
My understanding is that:
If an extension is marked critical, and an implementation does not
understand it, it MUST stop processing the certificate or CRL.
If an extension is NOT marked critical, and an implementation does not
understand it, it MAY stop processing th
Kyle Hamilton wrote, On 2009-02-23 20:19:
> There is only one last question that I'm going to ask, since it is
> relevant here: Which version of PKIX (3280 or 5280) does HKP issue
> certificates to be conformant to? My understanding is that NSS supports
> 3280 (and not 5280); if there are certi
Sorry. I hate having to do this, but with all the spam that has gone
to the mailing list today, because it came through google groups, I must
disable the news->mail gateway for a time to stop the spam.
It frustrates me to no end that postings to the mailing list are filtered
for all sources EXCEP
So. If I understand correctly:
(I'll abbreviate Hongkong Post as HKP)
1) HKP issued certs currently do not cause problems.
2) HKP has been notified how their system may cause problems in the future.
3) HKP is not requesting EV status, so any EV-specific discussion is
irrelevant at this time.
4)
Nelson B Bolyard wrote:
Frank Hecker wrote, On 2009-02-20 16:53:
"However, implementations that do not support this extension MUST
either treat the status of any certificate *not listed on this CRL*
as unknown or locate another CRL that does not contain any
unrecognized critic
Longines Istituto Idrografico R. Marina Mens Watch L2.677.4.53.2, Best
Wristwatch World
Click Here To Website :
http://www.watchebay.net/Longines-Istituto-Idrografico-R-Marina-Mens-Watch-L2.677.4.53.2.html
Wristwatch World: http://www.watchebay.net/
Longines Istituto Idrografico R. Marina Mens Wat
Blancpain Leman Perpetual Calendar Mens Watch 2685F-3630-53B, Best
Wristwatch World
Click Here To Website :
http://www.watchebay.net/Blancpain-Leman-Perpetual-Calendar-Mens-Watch-2685F-3630-53B.html
Wristwatch World: http://www.watchebay.net/
Blancpain Leman Perpetual Calendar Mens Watch 2685F-363
Corum Fallaci Stainless Steel Ladies Watch 137.111.20/V500B, Best
Wristwatch World
Click Here To Website :
http://www.watchebay.net/Corum-Fallaci-Stainless-Steel-Ladies-Watch-137.111.20-V500B.html
Wristwatch World: http://www.watchebay.net/
Corum Fallaci Stainless Steel Ladies Watch 137.111.20/V50
On 02/24/2009 02:35 AM, Ian G:
The point that is made is that the "positive response" is so weak that
it doesn't support the overall effect; the attacker just prefers to
trick the user using HTTP and some favicons or other simple symbols. And
(so the author claims) gets away with it easily enough
Frank Hecker wrote, On 2009-02-20 16:53:
> Nelson B Bolyard wrote:
>> Here is some info that should help with understanding all this.
>
> Thanks, this is very useful. So to sum up my understanding:
>
> If NSS had support for CRL DP, but no support for CIDP, then what would
> happen with Hongkong
To amplify the response to Gerv's question on "positive / negative
imbalance in responses in FF3", here's a forward from another list.
On 21/2/09 15:34, Peter Gutmann wrote:
"Steven M. Bellovin" writes:
http://www.theregister.co.uk/2009/02/19/ssl_busting_demo/ -- we've talked
about this at
On 24/2/09 00:20, Gervase Markham wrote:
On 19/02/09 17:36, Ian G wrote:
1. He has clearly laid out the trap of negative versus positive
feedback, and explained why Firefox 3 UI changes make the result less
secure than Ff2.
You'll need to elaborate on what you are saying here, because the way
On Mon, Feb 23, 2009 at 4:10 PM, Eddy Nigg wrote:
> On 02/24/2009 02:01 AM, Kyle Hamilton:
>>
>> It's important to realize something rather important... security must
>> be designed into the system from the ground up, and all pieces of a
>> secure system must operate together properly. It's not *
On 02/24/2009 02:01 AM, Kyle Hamilton:
It's important to realize something rather important... security must
be designed into the system from the ground up, and all pieces of a
secure system must operate together properly. It's not *just* the CA,
it's everything.
Ideally yes, your are right...
Eddy:
It's important to realize something rather important... security must
be designed into the system from the ground up, and all pieces of a
secure system must operate together properly. It's not *just* the CA,
it's everything.
Since we don't have a secure system, we need to find a way to mak
Nelson B Bolyard wrote:
1. As you may know, the EV spec says that a client should not give a
cert the full EV treatment unless/until it has done some successful
revocation check (CRL or OCSP, this year) at least on the EE cert.
Beginning with FF 3.1 (IINM) FF will enforce that rule. This will
me
On 02/24/2009 01:23 AM, Gervase Markham:
All the registries added to the list had this when they were added. As I
said in my previous message, if you know of a registry which no longer
meets these criteria, please let me know.
How to prove? Does Mozilla buy domain names (or purchase certificate
On Mon, Feb 23, 2009 at 11:30 AM, Frank Hecker
wrote:
> I can't speak for the NSS developers, however speaking personally I see no
> reason to drop support for manual import of CRLs.
Does the CRL processing:
1) handle the notAfter date properly?
2) throw an error when the imported CRL is evaluat
On 02/24/2009 01:18 AM, Gervase Markham:
The "rationale" section of this document explains very well why our
policy and technical implementation is as it is:
http://www.mozilla.org/projects/security/tld-idn-policy-list.html
OK, reading the IDN policy I understand that registrars uses human, a
Frank Hecker wrote, On 2009-02-23 14:42 PST:
> Based on the discussion so far, my understand is as follows: In the near
> term Hongkong Post's certificates will work OK in Firefox et.al. with
> the default settings (i.e., no CRL checking), and users wanting to do
> revocation checking can manua
On 22/02/09 21:56, Paul Hoffman wrote:
I think part of what's going on here is a confusion between CAs and
domain name registrars. IIRC there was indeed some sort of
agreement among domain name registrars to implement special
checking for internationalized domain names.
There was no such agreem
On 19/02/09 17:36, Ian G wrote:
1. He has clearly laid out the trap of negative versus positive
feedback, and explained why Firefox 3 UI changes make the result less
secure than Ff2.
You'll need to elaborate on what you are saying here, because the way I
read it, he _hates_ the new FF3 securit
On 20/02/09 18:28, Benjamin Smedberg wrote:
I'm proposing that when Firefox displays the domain name of a site, it
should only use punycode display for the portion of the domain name which
actually appears in the certificate. So for a wildcard cert *.ijjk.cn, the
display would be
xn--blahblahunr
On 23/02/09 17:58, Paul Hoffman wrote:
Jean-Marc, you have fallen for Gerv's wishful thinking and security
theater. There are multiple TLDs on that list that have policies that
say *nothing* about preventing homograph spoofing.
Every TLD on that list should have a published set of characters it
On 02/23/2009 04:57 PM, Ian G:
* IDNs present more danger than wildcards,
* wildcards present more danger than IDNs,
* they are approximately the same level of danger,
and trying to separate them out is not efficacious
at this level of discussion?
Anything which can be misused in such a way s
Nelson B Bolyard wrote:
Frank Hecker wrote, On 2009-02-23 11:30:
I have no problem with NSS ignoring CRLs with CIDP extensions in the
context of CRLDP support; however I think that (e.g.) Firefox should not
treat this as an error but should proceed as if no CRL were ever seen.
(I think it's OK t
Frank Hecker wrote, On 2009-02-23 11:30:
> I have no problem with NSS ignoring CRLs with CIDP extensions in the
> context of CRLDP support; however I think that (e.g.) Firefox should not
> treat this as an error but should proceed as if no CRL were ever seen.
> (I think it's OK to show an error mes
ma...@e-mice.net wrote re ignoring CRLs with the IDP extension:
This approach makes a lot of sense to the implementation because if
the implementation could know whether the certificate is on the list,
it has already supported CIDP and the question itself is not a
question any more. Right?
I'm
Jean-Marc Desperrier wrote, On 2009-02-23 04:01:
> Nelson and everyone else not knowing the details of this :
> The problem is solved not at the CA level, but at the registry/TLD level.
I think you mean that IF it were solved, the solution would be at ...
But I think it is evident that it is NOT s
At 2:19 AM +0200 2/23/09, Eddy Nigg wrote:
>You don't like that I mention particular CAs, but the one I'm affiliated with
>does to some extend. ;-)
I do not like you mentioning particular CAs to advertise (yourself) or attack
(your competitor); asking for a list of CAs that implement policies th
At 1:14 PM +0100 2/23/09, Jean-Marc Desperrier wrote:
>Paul Hoffman wrote:
>>TLD registries ask which language a name is in; some then do some
>>filtering based on what characters they think are used by particular
>>languages. This is far from a science and fails miserably for most
>>European langu
I'm scratching my head here...I'm trying to connect to an SSL server
with a full EC chain using a JSS SSLSocket.
Using NSS 3.12.2 libs taken from my Firefox 3.0.6 install I get:
org.mozilla.jss.ssl.SSLSocketException: SSL_ForceHandshake failed:
(-5978) Network file descriptor is not connected.
On 23/2/09 13:41, Eddy Nigg wrote:
On 02/23/2009 02:01 PM, Jean-Marc Desperrier:
When issuing a SSL server cert there is no need for a special checking
at the CA level, because nobody will first be able to obtain a dangerous
domain name within that TLD.
Like the IANA requirement to state corre
On 02/23/2009 02:01 PM, Jean-Marc Desperrier:
When issuing a SSL server cert there is no need for a special checking
at the CA level, because nobody will first be able to obtain a dangerous
domain name within that TLD.
Like the IANA requirement to state correct information in the WHOIS
records
Paul Hoffman wrote:
TLD registries ask which language a name is in; some then do some
filtering based on what characters they think are used by particular
languages. This is far from a science and fails miserably for most
European languages.
If it fails, then report it to secur...@mozilla.org a
Nelson B Bolyard wrote:
Benjamin Smedberg wrote, On 2009-02-20 10:28:
[...] CA guidelines
Which (whose) guidelines? Are you referring to RFC 5280 section 7, or
to some other guidelines?
Mozilla's CA cert policy doesn't even mention this subject.
say that certificates should not be issued w
On Feb 21, 8:53 am, Frank Hecker wrote:
> Nelson B Bolyard wrote:
> > Here is some info that should help with understanding all this.
>
> Thanks, this is very useful. So to sum up my understanding:
>
> If NSS had support for CRL DP, but no support for CIDP, then what would
> happen with Hongkong P
On Feb 21, 8:53 am, Frank Hecker wrote:
> Nelson B Bolyard wrote:
> > Here is some info that should help with understanding all this.
>
> Thanks, this is very useful. So to sum up my understanding:
>
> If NSS had support for CRL DP, but no support for CIDP, then what would
> happen with Hongkong P
41 matches
Mail list logo
