Nelson B Bolyard wrote:
But one could imagine that we make use of them, and allow the values of
the CKA_END_DATE to be different from (earlier than) the notAfter date
in the related certificate.
It's good to know that this is technically possible.
But actually, I don't see this as a high
Frank Hecker wrote:
I agree that it would be a good thing if Entrust (or any CA, for that
matter) used technical means (like sending email to postmaster or
whatever) to verify domain name ownership for non-EV SSL certs, in
addition to whatever other procedures are used.
In the past, at
Paul Hoffman wrote:
[...]
Sure, but that's not the model most CAs have with their customers. I
would bet that if a CA sent out a message saying we're revoking your
cert tomorrow, here's a new one to all of its affected customers, fewer
than 95% would have the new cert installed correctly. The
Jean-Marc Desperrier wrote:
Michael Ströder wrote:
[...]
RFC 2818 (only INFORMATIONAL) references RFC 2459 concerning matching
rules which was obsoleted by RFC 3280 which was recently obsoleted by
RFC 5280. RFC 5280 references Preferred name syntax in RFC 1034.
Glancing over these documents
Michael Ströder wrote:
[...]
RFC 2818 (only INFORMATIONAL) references RFC 2459 concerning matching
rules which was obsoleted by RFC 3280 which was recently obsoleted by
RFC 5280. RFC 5280 references Preferred name syntax in RFC 1034.
Glancing over these documents I found no provision that
At 11:22 AM +0200 6/9/08, Jean-Marc Desperrier wrote:
Paul Hoffman wrote:
[...]
Sure, but that's not the model most CAs have with their customers. I
would bet that if a CA sent out a message saying we're revoking your
cert tomorrow, here's a new one to all of its affected customers, fewer
Paul Hoffman wrote:
However, given that a CA cannot know whether or not a domain has been
compromised, a CA that tries to save the customer by revoking the
possibly-compromised domain's keys is overstepping its responsibility.
Whether the CA is overstepping its responsibility is subject
Eddy Nigg (StartCom Ltd.) wrote:
For internal networks, internally assigned domain names should be used,
like NETWORK = intern.domain.com
Thinking further about this whole stuff:
I consider the hostname checking to be a very important validation of
whether the browser really connects to a
On Sun, Jun 8, 2008 at 6:54 PM, Nelson B Bolyard [EMAIL PROTECTED] wrote:
I recently encountered a web site with a certificate that chained through
two intermediate CAs to one of Mozilla's trusted roots.
This cert's Subject Alt Name (SAN) extension included:
- 43 wildcard domain names (e.g.
Kyle Hamilton wrote, On 2008-06-08 13:28:
My thought is that if there's any knowledge that a CA has that a key
has been compromised, the CA can no longer verify the binding of the
key to the subject -- which means that the certification should not
exist, and thus must be revoked.
On the
Paul Hoffman wrote, On 2008-06-09 09:41:
At 11:22 AM +0200 6/9/08, Jean-Marc Desperrier wrote:
Aren't the people who send their credit card number on an https
connexion where the private key of the server is public knowledge
already screwed ?
Yes, of course. The question for this thread
Wan-Teh Chang wrote:
There is a bug on certs containing unqualified host names:
https://bugzilla.mozilla.org/show_bug.cgi?id=401317
I really wonder what makes a host name an unqualified hostname?
No doubt that https://www/ looks like a valid example to us humans. But
how about https://com/
Eddy Nigg (StartCom Ltd.) wrote, On 2008-06-09 15:23:
Nelson B Bolyard:
(quoting Paul Hoffman, quoting Jean Mark Desperrier)
Aren't the people who send their credit card number on an https
connexion where the private key of the server is public knowledge
already screwed ?
Yes, of
At 2:56 PM -0700 6/9/08, Nelson B Bolyard wrote:
Paul Hoffman wrote, On 2008-06-09 09:41:
At 11:22 AM +0200 6/9/08, Jean-Marc Desperrier wrote:
Aren't the people who send their credit card number on an https
connexion where the private key of the server is public knowledge
already screwed
Eddy Nigg (StartCom Ltd.) wrote, On 2008-06-09 17:19:
Nelson B Bolyard:
In this case, the guy held up a bag of ~96 thousand private keys and said
See, here are 96 thousand private keys that I possess. Anyone can have a
copy of them. I can't imagine better proof of key compromise than that.
15 matches
Mail list logo
