Le jeudi 2 janvier 2014 17:47:36 UTC+1, Chema López a écrit :
> I understand that when we say "Subscriber Certificates" we refer to SSL
> certificates? I mean, there are Certification Services Providers that issue
> SSL certificates as well as Natural Person (sometimes Qualified - according
> to t
Dear all
I understand that when we say "Subscriber Certificates" we refer to SSL
certificates? I mean, there are Certification Services Providers that issue
SSL certificates as well as Natural Person (sometimes Qualified - according
to the Directive 1999/93/EC of the European Parliament and of th
On Mon, Dec 23, 2013 at 8:54 AM, Rob Stradling wrote:
> On 21/12/13 22:57, Phillip Hallam-Baker wrote:
>
>> I thought that what we were trying to do here is break a deadlock
>> where Cas wait for browsers and vice versa.
>>
>> I have no trouble telling a customer with a 15 year 512 bit cert that
>
On 21/12/13 22:57, Phillip Hallam-Baker wrote:
I thought that what we were trying to do here is break a deadlock
where Cas wait for browsers and vice versa.
I have no trouble telling a customer with a 15 year 512 bit cert that
they need to change for a new one if they want it to work for ssl wit
On 21/12/13 22:22, Kathleen Wilson wrote:
On 12/20/13 11:45 AM, Rob Stradling wrote:
To me, "cert revocation" means replying "revoked" via OCSP for that
cert's serial number, and also adding that cert's serial number to the
CRL.
I understand that new versions of browsers will stop accepting 102
I thought that what we were trying to do here is break a deadlock
where Cas wait for browsers and vice versa.
I have no trouble telling a customer with a 15 year 512 bit cert that
they need to change for a new one if they want it to work for ssl with
the browsers
Revoking it without their consent
On 12/20/13 11:45 AM, Rob Stradling wrote:
To me, "cert revocation" means replying "revoked" via OCSP for that
cert's serial number, and also adding that cert's serial number to the CRL.
I understand that new versions of browsers will stop accepting 1024-bit
certs and that site operators will na
On 20/12/13 17:40, Kathleen Wilson wrote:
On 12/13/13 4:03 AM, Rob Stradling wrote:
On 12/12/13 01:08, fhw...@gmail.com wrote:
That's the great part about this, Rob, you don't actually have to revoke
anything.
Peter, thanks for sharing your interpretation. What concerns me is that
the same
On 12/13/13 4:03 AM, Rob Stradling wrote:
On 12/12/13 01:08, fhw...@gmail.com wrote:
That's the great part about this, Rob, you don't actually have to revoke
anything.
Peter, thanks for sharing your interpretation. What concerns me is that
the same interpretation is not shared by everyone.
Kathleen, I think that even if you agree to extend the deadline, it's a moot
point unless Microsoft and other browsers follow suit. Unless there are web
site owners that only support Firefox.
___
dev-security-policy mailing list
dev-security-policy@list
On 12/12/13 01:08, fhw...@gmail.com wrote:
That's the great part about this, Rob, you don't actually have to revoke
anything.
Peter, thanks for sharing your interpretation. What concerns me is that
the same interpretation is not shared by everyone.
I don't really care whether or not these
On 12/12/13 2:11 AM, Jan Schejbal wrote:
Roots can be removed by disabling the trust bits (i.e. a reasonably
simple change). This should be done ASAP after the relevant date -
shouldn't it have been included in the Gecko/Firefox 27 beta currently
running? Can it still be included, or is it too l
Le jeudi 12 décembre 2013 11:11:40 UTC+1, Jan Schejbal a écrit :
> RSA-768 has been practically broken in 2010:
> http://eprint.iacr.org/2010/006.pdf
> The authors note that "factoring a 1024-bit RSA modulus would be about a
> thousand times harder". I wouldn't call that a comfortable safety mar
Am 2013-12-11 23:31, schrieb Kathleen Wilson:
>
> I am inclined to grant more time to CAs for customers who are working
> hard to transition off of 1024-bit certs, but need a little more time to
> complete their transition.
We need to distinguish between roots, intermediates and end-entity
certif
On Wed, Dec 11, 2013 at 3:47 PM, wrote:
> Well let's be clear about one thing: in Firefox land (as in others) there
> is no such thing as revocation; there is only changing the code.
>
Changing the code is required because currently-standardized revocation
mechanisms don't work effectively or in
een Wilson';
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Exceptions to 1024-bit cert revocation requirement
The requirement is from Mozilla's policy, not the BRs:
https://wiki.mozilla.org/CA:MD5and1024
Note that the Microsoft policy doesn't require revocation. Ins
That's the great part about this, Rob, you don't actually have to revoke anything. The certs will just stop working at some point. I'm being somewhat facetious but
curity-pol...@lists.mozilla.org
Subject: Re: Exceptions to 1024-bit cert revocation requirement
On 12/12/13 00:25, Kathleen Wilson wrote:
> From Rob:
>> Kathleen, are you saying that "must expire by the end of 2013" is a
>> "revocation requirement" ?
>>
&
On 12/12/13 00:25, Kathleen Wilson wrote:
From Rob:
Kathleen, are you saying that "must expire by the end of 2013" is a
"revocation requirement" ?
Expiration != Revocation.
Is there actually a requirement that says "By the end of 2013, CAs
MUST revoke all unexpired certificates with <2048-bi
On 12/11/13 2:55 PM, Gervase Markham wrote:
On 11/12/13 14:31, Kathleen Wilson wrote:
There are a few cases where customers are asking CAs for more time to
transition off of their 1024-bit certificates.
What exactly are CAs asking for? Are they asking for permission to
continue issuing such ce
Well let's be clear about one thing: in Firefox land (as in others) there is no such thing as revocation; there is only changing the code.I think what Kathleen is saying is that starting Jan 1, Mozilla would like to take out the code supporting certs with small keys. What needs to be negotiated the
On 11/12/13 22:31, Kathleen Wilson wrote:
According to https://wiki.mozilla.org/CA:MD5and1024
"All end-entity certificates with RSA key size smaller than 2048 bits
must expire by the end of 2013.
Kathleen, are you saying that "must expire by the end of 2013" is a
"revocation requirement" ?
On Wed, Dec 11, 2013 at 2:48 PM, Jeremy Rowley
wrote:
> If you are granting more time, I have a whole bunch of customers who are not
> happy about the 2013 cutoff. Extending it for some CAs is patently unfair
> to those of us who have taken a hard stance on the deadline and not
> requested exten
On 11/12/13 14:31, Kathleen Wilson wrote:
> There are a few cases where customers are asking CAs for more time to
> transition off of their 1024-bit certificates.
What exactly are CAs asking for? Are they asking for permission to
continue issuing such certs? Or are they asking for permission to "n
If you are granting more time, I have a whole bunch of customers who are not
happy about the 2013 cutoff. Extending it for some CAs is patently unfair
to those of us who have taken a hard stance on the deadline and not
requested extensions of time. If you are granting some CAs an extension,
you'l
On 12/12/2013 12:31 AM, From Kathleen Wilson:
I understand that this is not fair to the CAs who have done a great
job of transitioning off of 1024-bit certs.
Right - potential customers knock at various doors in respect to such
certificates and I believe to have given the right answers to them
26 matches
Mail list logo
