[cabfpub] Pre-Ballot - Short-Life Certificates

Stephen Davidson S.Davidson at quovadisglobal.com
Wed Nov 5 12:33:57 MST 2014


+1

To the question "Are there any real reasons the Forum isn't permitting this
type of cert?"

I'd currently respond "Because there is no broad implementation for
short-lived certs of which I am aware - and the way this is being proposed
indicates there must be something afoot which is not yet public."

Best, Stephen



-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Tim Hollebeek
Sent: Wednesday, November 05, 2014 3:09 PM
To: Jeremy Rowley; i-barreira at izenpe.net; public at cabforum.org
Subject: Re: [cabfpub] Pre-Ballot - Short-Life Certificates

I haven't seen any argument made that this type of certificate "is not
permitted" by the Forum.

What I have seen is a proposal that we need to permit certificates with no
revocation information so that "CAs and browsers can deploy and gain
experience with" (from original ballot proposal) short-lived certificates.

Since we're essentially running an experiment on the public internet, why is
it important that they have benefits to "clients which do not handle them in
a special way" (from original ballot proposal) ?  What benefits do the
people who do not want to be part of this experiment get, other than
additional complexity?

Issue these certificates and play with them, if you like.  Feel free to
update browsers and clients with support for short-lived certificates.  If
the experiment is successful and short-lived certificates become widely
used, we can update the BRs to allow the omission of OCSP information for
such certificates (though I think I'd prefer must-staple instead).  It just
seems a bit premature to me to be updating the BRs right now, especially
since it does not appear to me to be necessary.

But that's just me.

-Tim

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Jeremy Rowley
Sent: Wednesday, November 05, 2014 1:56 PM
To: i-barreira at izenpe.net; public at cabforum.org
Subject: Re: [cabfpub] Pre-Ballot - Short-Life Certificates

I don't think their responses were encompassing as you indicated that all 9
points are cons. The comments received responded to points 7, 8, and 9 (plus
Rick's general comments). Each are addressed below.

The response to 7 is that the revocation and expiration message aren't as
strong.  Gerv posted on the Mozilla list that they'd consider using the same
message for expired short-lived certs as revoked certs.  Therefore, I don't
think this point has merit.

The response to 8 was that  cert might need to be included in a CRL if the
key is used for multiple certs.  That's not really an argument against
short-lived certs.  Instead, that's an argument that users should have to
frequently change private keys, which is more likely with a short-lived
cert.  I don't see that as a security issue for using short lived certs.

The rebuttal to point 9 was that CAs can use a shorter period.  However,
with short-lived certs the user gets to set the revocation period (up to 3
days) instead of the CA.  This rebuttal missed the point that short-lived
certs let users control the window of risk rather than delegated control to
the CA.

Ricks points were:
"It would be helpful to list the disadvantages. Here's some:
a) Short-lived certs won't work on some number of machines whose clocks are
too far out of sync. The actual number is debatable. It's small, but
non-zero."
[JR] Gerv posted clock skew data.  I think this data refutes this argument.
Plus, does it matter?  If a CA is offering short-lived certs, the CA takes
the risk of clock skew.  It doesn't affect any CA not issuing short-lived
certs.

"b) Subscriber has to deal with the additional risk that their servers have
to call back to the CA every day, obtain a fresh cert, and deploy that new
cert without any negative impact to existing traffic."
[JR] Okay, but that's the subscriber's choice.  If the subscriber warrants
that the risks are worth it, why not let them use it?  This is not a
security argument against short-lived certs.

"c) What a CA saves in OCSP infrastructure is offset by new infrastructure
needed to distribute new certs to these customers every day."
[JR] That's up to the CA.  This is not an argument for allowing short-lived
certs.  Some CAs may not wish to offer short-lived certs, but that's no
reason for the Forum to needlessly restrict an alternative form of
revocation checking.

So far, the arguments against permitting short lived certs seems to be FUD.
Are there any real reasons the Forum isn't permitting this type of cert?

Jeremy

-----Original Message-----
From: i-barreira at izenpe.net [mailto:i-barreira at izenpe.net]
Sent: Wednesday, November 5, 2014 9:24 AM
To: Jeremy Rowley; public at cabforum.org
Subject: RE: [cabfpub] Pre-Ballot - Short-Life Certificates

Jeremy, my concerns were addressed later in emails by Eddy, Rick, etc.


Iñigo Barreira
Responsable del Área técnica
i-barreira at izenpe.net
945067705


ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea.
Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki
idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzuna.
KONTUZ!
ATENCION! Este mensaje contiene informacion privilegiada o confidencial a la
que solo tiene derecho a acceder el destinatario. Si usted lo recibe por
error le agradeceriamos que no hiciera uso de la informacion y que se
pusiese en contacto con el remitente.

-----Mensaje original-----
De: Jeremy.Rowley [mailto:jeremy.rowley at digicert.com]
Enviado el: miércoles, 05 de noviembre de 2014 16:19
Para: Barreira Iglesias, Iñigo; public at cabforum.org
Asunto: Re: [cabfpub] Pre-Ballot - Short-Life Certificates

Then please do so, and I will respond.

With a three day time period, I really don't see the cons.  The cert will
expire by the time any CA revokes. Nearly every CP states that they process
revocation requests in 24 hours, meaning there is at least a day before it
shows up on an OCSP and 10 before it propagates everywhere.

On 11/5/2014 3:19 AM, i-barreira at izenpe.net wrote:
> Jeremy, the 9 pros you mention can also be converted in cons. Don´t 
> see it that easy as you indicate, in fact, I see more cons than pros
>
>
> Iñigo Barreira
> Responsable del Área técnica
> i-barreira at izenpe.net
> 945067705
>
>
> ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta
egotea. Mezua badu bere hartzailea. Okerreko helbidera heldu bada (helbidea
gaizki idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi
erantzuna. KONTUZ!
> ATENCION! Este mensaje contiene informacion privilegiada o confidencial a
la que solo tiene derecho a acceder el destinatario. Si usted lo recibe por
error le agradeceriamos que no hiciera uso de la informacion y que se
pusiese en contacto con el remitente.
>
>
> -----Mensaje original-----
> De: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> En nombre de Jeremy Rowley Enviado el: viernes, 31 de octubre de 2014
> 18:09
> Para: public at cabforum.org
> Asunto: Re: [cabfpub] Pre-Ballot - Short-Life Certificates
>
> I think this discussion could benefit from some of the reasons that people
want short-lived certificates.  These were previously discussed on the
Mozilla mailing list, but not everyone follows what is going on there.
>
> Here are some of the advantages:
> 1) Subscribers in areas prone to unrest and where their server might be
taken over can let the certificate expire, essentially letting the
certificate fail to renew.
> 2) Subscribers can eliminate size from the certificate
> 3) Subscribers can avoid call-backs to the CA
> 4) Subscribers can control how long revocation information takes to 
> propagate (up to 3 days, but could be less)
> 5) This is a change that doesn't require action by the browsers, 
> meaning it's a CA-drive improvement
> 6) The change isn't required for any CA. All it does is permit CAs
interested in offering the services to customers to do so.
> 7) Short-lived certs provide a limited hard-fail since the expiration 
> message for expired certs is more visible than the message received 
> where revocation information is unavailable
> 8) Browsers don't need to add the certs to their CRLSets or do a call to
the CA to retrieve revocation information.
> 9) Short-lived certs provide shorter revocation windows than currently
offered under the BRs.
>
> There are 9 advantages that I could readily find. I'm sure many more
exist.  Of course, short-lived certs aren't for every customer and will be
deployed only by a small percent of the internet population.  However, for
those interested in using them, there are key advantages in deployment.
>
> Jeremy
>
>
>
>
> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Gervase Markham
> Sent: Thursday, October 30, 2014 7:29 AM
> To: kirk_hall at trendmicro.com; Ryan Sleevi; Doug Beattie
> Cc: public at cabforum.org
> Subject: Re: [cabfpub] Pre-Ballot - Short-Life Certificates
>
> On 29/10/14 18:50, kirk_hall at trendmicro.com wrote:
>> Ryan, thanks for the information, and I respect your analysis.  But 
>> many of us would say that revocation (and the ability to check for
>> revocation) is a fundamental aspect of whether a cert is valid at all.
> I think we all agree that the ability to revoke certs is vital. However,
in the real world, there is always going to be a time lag of some sort
between the decision to revoke and all clients becoming aware of that
revocation. Comparing any system to the perfect system of universal instant
revocation is unfair.
>
> An analysis of real-world revocation inevitably involves complex scenarios
about the nature of the attack, the capabilities of the attackers, the type
of revocation system being used, the update frequency of clients, the
characteristics of the network, and so on. And it inevitably involves
vulnerability windows for some clients.
>
> My assertion is that, in reasonable attack scenarios, the vulnerability
windows and overall risk of short-lived certs is about the same as
long-lived certs using OCSP.
>
> Gerv
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> http://scanmail.trustwave.com/?c=4062&d=3_La1GY-diEx81wQCk2t5-PJLbzlNF
> Yu1lvgg0GfGw&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2
> fpublic _______________________________________________
> Public mailing list
> Public at cabforum.org
> http://scanmail.trustwave.com/?c=4062&d=3_La1GY-diEx81wQCk2t5-PJLbzlNF
> Yu1lvgg0GfGw&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2
> fpublic
> .
>


_______________________________________________
Public mailing list
Public at cabforum.org
http://scanmail.trustwave.com/?c=4062&d=3_La1GY-diEx81wQCk2t5-PJLbzlNFYu1lvg
g0GfGw&s=5&u=https%3a%2f%2fcabforum%2eorg%2fmailman%2flistinfo%2fpublic

________________________________

This transmission may contain information that is privileged, confidential,
and/or exempt from disclosure under applicable law. If you are not the
intended recipient, you are hereby notified that any disclosure, copying,
distribution, or use of the information contained herein (including any
reliance thereon) is strictly prohibited. If you received this transmission
in error, please immediately contact the sender and destroy the material in
its entirety, whether in electronic or hard copy format.
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5494 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20141105/8c948b93/attachment-0001.bin 


More information about the Public mailing list