Key Continuity Management
Ben Bucksch
Based on request by Johnathan in
mailman.1145.123142243...@lists.mozilla.org , and by
Nelson in the bug (to keep out advocacy), I hereby open a thread to work
out the technical details how we could make that work.
Some open questions:
* How to deal with cert expiry
* How to educate admins to manage the private keys
* How to treat self-signed certs in UI after this is implemented
* Other questions which need to be discussed
Please separate advocacy from technical questions as far as possible, by
using different sub-threads.
For the technical questions, please try to concentrate on finding
*solutions* to the problems.
Ben Bucksch
* How to deal with cert expiry
- Require website owners to continue using the same private key.
- A fingerprint of that private key is put in the certificate.
- We store on first site: host, port, cert fingerprint, private key fingerprint
- After expiry of the cert (even now, only the cert expires, not the private key), the web site owner requests another cert from the CA, which certifies the same private key for another year, with a new certificate.
- We see that the private key stayed the same, and we're happy - it's the same party. We can implement "KCM".
- Revocation in case of key loss via CRL or OSCP is still possible.
- If, for some reason - be it key stolen, cryptographic weakness, or that the admin prefers to generate a new private key all the time - the private key changes, the public cert *must* also be signed by the old private key, in addition to the CA. This is what GPG does, too. This shows us that the new key is authorized by the old owner, so continuity is maintained. The CA certification shows that it's not a fraudster who stole the private key.
The only problem is if the admin is ignorant of this new scheme and does not sign the new cert or the private key is lost insofar as the admin cannot find it anymore. This is a separate discussion, see thread opener.
Is it technically possible for a cert to have two or more signatures? (I think it is - if I'm not mistaken, a cert can also have both MD5 and SHA2 signatures.) If not, can it be added by extensions?
Nelson B Bolyard
Thank you for starting this thread. This is a MUCH better place than
in bugzilla for such a discussion to take place.
> A possible solution (already posted in comment 18 in the bug):
I encourage people to read through that bug, especially the early
comments, before contributing here. (The later comments are mostly
"me too")
> * Require website owners to continue using the same private key.
This flies in the face of best current practices.
> * A fingerprint of that private key is put in the certificate.
Such a fingerprint already exists in the cert. It is the public key.
> * After expiry of the cert (even now, only the cert expires, not the
> private key), the web site owner requests another cert from the
> CA, which certifies the same private key for another year, with a
> new certificate.
Certs expire for the same reason that credit cards do. Do you understand
why that is?
> * We see that the private key stayed the same, and we're happy -
> it's the same party. We can implement "KCM".
> * Revocation in case of key loss via CRL or OSCP is still possible.
It requires that CAs NEVER "forget" about any certs they previously
issued, not even after they expire. It means that a CA's list of revoked
certs will grow boundlessly. It makes CRLs become impractically big.
CACert tried that once. They had a multi-megabyte CRL (maybe they still do).
> * If, for some reason - be it key stolen, cryptographic weakness, or
> that the admin prefers to generate a new private key all the time
> - the private key changes, the public cert *must* also be signed
> by the old private key, in addition to the CA.
Certs do not have multiple signatures.
> This is what GPG
> does, too. This shows us that the new key is authorized by the old
> owner, so continuity is maintained.
So, after a key is compromised, it remains desirable that replacement keys
are authorized by a signature made with the compromised key?
> The only problem is if the admin is ignorant of this new scheme and does
> not sign the new cert or the private key is lost insofar as the admin
> cannot find it anymore. This is a separate discussion, see thread opener.
>
> Is it technically possible for a cert to have two or more signatures?
No. X.509 certificates do not have multiple signatures.
> (I think it is - if I'm not mistaken, a cert can also have both MD5 and
> SHA2 signatures.)
You are mistaken.
> If not, can it be added by extensions?
No, because the content of all extensions are included in the computation
of the signature.
Eddy Nigg
> It requires that CAs NEVER "forget" about any certs they previously
> issued, not even after they expire. It means that a CA's list of revoked
> certs will grow boundlessly. It makes CRLs become impractically big.
Well...StartCom NEVER removes a certificate from the CRL once revoked.
That's because people tend to view expired certificates as an annoyance,
not critical. However a revoked certificate should never be accessible
anymore. (Just think about the mozilla.com certificate. I bet that the
majority would click through that certificate in case of "expiration",
whereas they can't because of revocation. There is an inherent
difference between the two).
>
> CACert tried that once. They had a multi-megabyte CRL (maybe they still do).
>
We manage however intermediate CA issuers per class and purpose, hence
the CRLs stay relatively small. The intermediate CAs are valid for five
years, whereas after the fourth year a new issuer takes over (leaving
the fifth year for revocations only). That's perhaps another good
practice...besides that, OCSP hasn't the draw-back of large downloads
anyway - and Firefox doesn't use CRLs really.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: star...@startcom.org
Blog: https://blog.startcom.org
Ben Bucksch
> I encourage people to read through that bug, especially the early
> comments, before contributing here. (The later comments are mostly "me
> too")
important, while agreeing comments are just "me too", right?).
>> * Require website owners to continue using the same private key.
>>
>
> This flies in the face of best current practices.
>
I think the current practices, of the whole PKI system on many levels,
are extremely bad.
Please be specific and rational in your arguments. "This is how we're
doing things so far" or "This is how this system was defined" is not an
argument.
> Certs expire for the same reason that credit cards do. Do you
> understand why that is?
No, quite frankly, I do not.
First off, my credit cards (VISA, MasterCard) are valid until Jan 1, 2013.
My GPG key expires in 10 years or something, and it hasn't been any
problem. My SSH keys also never expire, and that's good. The CA root
certs don't expire for 20 years.
If the private key on the server is secure, all is fine. If somebody
breaks into the server and the private key gets known to the attacker,
it's being revoked.
> It means that a CA's list of revoked certs will grow boundlessly. It makes CRLs become impractically big.
>
With OCSP, it's not a problem anymore, because the question is "is
*this* cert still valid?" not "tell me all revoked certs".
> It requires that CAs NEVER "forget" about any certs they previously
> issued, not even after they expire.
They get paid for it, for each cert. Hotmail and Yahoo also never forget
the email addresses that were issued (they may get deactivated, but the
account still exists), and it's not even a paid service.
>> This is what GPG
>> does, too. This shows us that the new key is authorized by the old
>> owner, so continuity is maintained.
>>
>
> So, after a key is compromised, it remains desirable that replacement keys
> are authorized by a signature made with the compromised key?
>
Yes. It - at worst - means that either rightful owner or the attacker
endorses the new key, reducing the candidates from the whole world to
two. The CA needs to approve the new key as well, though, so the
attacker has to gain *both* the old private key and get the approval of
the CA.
More importantly, it helps the normal situation that a the owner decides
to use a new key, for whatever reason, and prevents a spurious warning
for users in that case.
The warning, in turn, ensures that you cannot just walk to *any* CA,
without any connection to the victim site, and get a valid cert. It
*has* to be signed by the private key, which means the attacker *has* to
break into my systems.
This means that if I can manage to keep my systems secure, there's
really no way an attacker can get between me and my existing users /
communication partners. This is as secure as it gets. (If an attacker
breaks into one of the partners' systems, all bets are off, in any system.)
CAs and their verification processes are currently a potential
vulnerability, even if my systems are entirely secure. They would no
longer be for me and my friends.
>> Is it technically possible for a cert to have two or more signatures?
>>
>
> No. X.509 certificates do not have multiple signatures.
>
> No, because the content of all extensions are included in the computation of the signature.
>
Can we create another extension? The signature itself is a shell around
the certified bits. Add the second signature around that first signature.
There must be a way to add signatures. It's a base feature in PGP! If
it's entirely impossible to have two signatures, and no way to add it to
the spec, that's a design error. It's hard to believe that it's so limited.
Ian G
>> Certs expire for the same reason that credit cards do. Do you
>> understand why that is?
>
> No, quite frankly, I do not.
>
> First off, my credit cards (VISA, MasterCard) are valid until Jan 1, 2013.
I had to think about it too ... I think it is because in the old days,
the retailers had little pieces of paper with all the "revoked" credit
card numbers. Shop assistants were paid a reward for spotting the bad
credit cards. Back in the early days (I remember being trained on these
papers, we kept them under the register) there were around 100-1000
numbers on them.
Obviously that model didn't survive (there was real money involved) and
now all CCs are checked online, real time. So expiry should not be a
big deal anymore for *security* reasons.
Business reasons may still play a part, I think my (awful huge) online
bank wants to give me a new CC with a smart card, tell me its more
secure, not to worry, and by the way, all the liability has shifted to
me because I won't ever lose any money. Or somesuch complete travesty...
> With OCSP, it's not a problem anymore, because the question is "is
> *this* cert still valid?" not "tell me all revoked certs".
It's the net, dude! Only an online model makes sense. The 1980s telcos
didn't really know what they were looking at with this whole telephone
book in a cert thing.
>> It requires that CAs NEVER "forget" about any certs they previously
>> issued, not even after they expire.
>
> They get paid for it, for each cert. Hotmail and Yahoo also never forget
> the email addresses that were issued (they may get deactivated, but the
> account still exists), and it's not even a paid service.
CAs probably have to remember the certs -- all of them -- for many years
for verification reasons. It will be in the CPS somewhere.
(OK, let me backtrack ...) it will be in the CPS for some CAs. The
reasons are obscure and possibly only Verisign really has a good
understanding of this, they are the only CA that seems to have a legal
"competence" to use the word correctly.)
Nelson's point was that CRLs become unbounded; but that's not a problem
(a) if there are no disputes or (b) in an OCSP world. Pick (a) or (b).
>>> Is it technically possible for a cert to have two or more signatures?
>>
>> No. X.509 certificates do not have multiple signatures.
>>
>> No, because the content of all extensions are included in the
>> computation of the signature.
>
> Can we create another extension? The signature itself is a shell around
> the certified bits. Add the second signature around that first signature.
It is possible ... but you'd be better off trying to move Everest into
China. One of the core assumptions of the x.509 world is ONE SIGNATURE,
and ONE AUTHORITY. Nobody's going to agree with you.
> There must be a way to add signatures. It's a base feature in PGP! If
> it's entirely impossible to have two signatures, and no way to add it to
> the spec, that's a design error. It's hard to believe that it's so limited.
Different school of thought. Sorry :)
iang
Ben Bucksch
> One of the core assumptions of the x.509 world is ONE SIGNATURE, and
> ONE AUTHORITY.
Thing is: There is no one authority :-). God doesn't issue SSL
certificates. Apart from him, I trust only me and my friends.
> Different school of thought.
Yes, definitely.
It's the reason why S/MIME never took off for private mail - it just
doesn't fit. It's a 1:1 relationship, with no place for a CA (apart from
first sight maybe).
This proposal has the potential to let these two camps make peace. To
let SSL be useful in the other scenario, too, where I need a strong,
direct, continuous trust relationship with another party online.
Please don't fend it off because the proposal is somewhat different from
the old model. It has to be. It's a relatively small change in
comparison to using an entirely different system for those other needs.
Robert Relyea
> On 08.01.2009 23:15, Nelson B Bolyard wrote:
>> I encourage people to read through that bug, especially the early
>> comments, before contributing here. (The later comments are mostly
>> "me too")
> Esp. because the first are from you (and are dissenting, and therefore
> important, while agreeing comments are just "me too", right?).
>
>>> * Require website owners to continue using the same private key.
>>>
>>
>> This flies in the face of best current practices.
>>
>
> I think the current practices, of the whole PKI system on many levels,
> are extremely bad.
> Please be specific and rational in your arguments. "This is how we're
> doing things so far" or "This is how this system was defined" is not
> an argument.
Allowing the same private key over an extended time is a question of CA
policy. Such allowances are already questionable *CRYPTO* (not PKI)
policy. A system that requires the same key is a non-starter. This is
crypto 101, right up there with not signing data passed to you in mass
by an attacker, or encrypting 2 different streams of data with the same
key in a stream cipher.
>> Certs expire for the same reason that credit cards do. Do you
>> understand why that is?
>
> No, quite frankly, I do not.
>
> First off, my credit cards (VISA, MasterCard) are valid until Jan 1,
> 2013.
>
> My GPG key expires in 10 years or something, and it hasn't been any
> problem. My SSH keys also never expire, and that's good. The CA root
> certs don't expire for 20 years.
Several of these are problem. Debian-weak SSH keys never expire. The
risk these keys pose to PKI based apps are small and shrinking. SSH has
to depend on actively detecting those keys proactively. Those that
weren't detected slowly expire out of the system. It's the built-in
safety valve that adds robustness even with a weak revocation model.
Debian-weak SSH keys will plague the backwaters of the internet for a
long time.
>
> If the private key on the server is secure, all is fine. If somebody
> breaks into the server and the private key gets known to the attacker,
> it's being revoked.
The security value of a private key degrades over time. The rate of
this effective degradation depends on the usage of the key, the
strength, etc. 10-20 years for an RSA 1024 bit key issued today is
definitely too long (independent on how it's used). A private key that's
stored on a hard drive on a machine should be treated as having a
smaller potential life than one stored in secured hardware. A key which
many potential people may have access to (including administrators) will
have a smaller potential life than one that doesn't.
Re: Revocation
Revocation in any Key system is a hard and expensive problem. PKI's have
tools and infrastructures in place to allow this, but even today it's
not really turned on everywhere.
--------------------------
There's a more fundamental problem here, though. KCM is popular among
people who "know a little security" because it puts the burden of
security in the users own hands. It makes sense. I want to control my
own destiny. The big secret is few (and I mean a lot fewer than people
think) of us are sufficiently diligent enough to use such a scheme on a
regular basis.
KCM is good for a single pipe between to fixed and seldom changing
computers, which are set up by a conscientious, knowledgeable person. In
the day to day operations it is an accident waiting to happen. I use ssh
daily. The only way I've found to keep myself honest is to use 'client
auth' to make up for the risk posed by using KCM for a many to many
connection scenario. In the many to many or the one to many case, KCM
trains the user to ignore the warning messages. Machines get reloaded
with new operating systems, events cause rekeying, I visit new machines
that I don't deal with every day. The whole burden is placed on me to
decide if I'm being attacked. 99.9% of the time I get a warning that is
benign That .1 % when it's not, I'm now trained to ignore it.... and I
know what I'm doing. I know what is going on under the covers. I keep
myself safe by never typing a password in an SSH pipe. If I can't make a
connection with a cert, it means I'm probably not connecting to the
machine I thought.
Mozilla is the same. Users are making lots of connections, often to new
sites that they have never visited before. They trash their profiles.
They reload their machines. They visit sites from their mom's computers.
Even if you could get every website to follow the (poor security)
practice of never changing their keys, you are generating so much noise
that users will ignore key change warnings.
The only use that I see of KCM is for a small community of users that
have some security training and believe that they can manage this system
themselves. For those users we have a solution today.... rm
{firefox_bin_dir}/nssckbi.dll and add each site as a security exception.
bob
Robert Relyea
> Advocacy:
>
>> One of the core assumptions of the x.509 world is ONE SIGNATURE, and
>> ONE AUTHORITY.
>
> Thing is: There is no one authority :-). God doesn't issue SSL
> certificates. Apart from him, I trust only me and my friends.
In very real ways you trust a lot more than yourself and your friends...
for a lot more than whether this website is who it says it is...;).
Julien R Pierre - Sun Microsystems
Eddy Nigg wrote:
> On 01/09/2009 12:15 AM, Nelson B Bolyard:
>> It requires that CAs NEVER "forget" about any certs they previously
>> issued, not even after they expire. It means that a CA's list of revoked
>> certs will grow boundlessly. It makes CRLs become impractically big.
>
> Well...StartCom NEVER removes a certificate from the CRL once revoked.
> That's because people tend to view expired certificates as an annoyance,
> not critical. However a revoked certificate should never be accessible
> anymore.
FYI, if a certificate is expired, NSS won't even bother performing a
revocation check on it, either CRL or OCSP. It would be a waste of time,
CPU and network resources to do so, and the revocation information would
be irrelevant since NSS already knows the cert is expired.
Ie. the expiration of the cert is more critical information than its
revocation status - NSS can be certain the cert is no longer valid,
because the validity date has been signed, and there is no point in
checking revocation status.
Yet the PSM UI lets you click to override the expiration of a cert, but
not for revocation. I don't think it makes much sense to override either
case.
Note that the the argument about keeping or removing expired certs from
CRLs is mostly about non realtime protocols, eg. S/MIME, where old
messages with old certs may need to be reverified. Of course, since
NSS/PSM doesn't do secure timestamps for S/MIME messages, much of this
is academic, even if the CRL grows forever.
Julien R Pierre - Sun Microsystems
Ben Bucksch wrote:
> With OCSP, it's not a problem anymore, because the question is "is
> *this* cert still valid?" not "tell me all revoked certs".
No, the question OCSP asks is not that . It is "is this cert revoked, as
of the current date" ?
Note that OCSP does not allow revocation checks for date prior to the
current date (whether of not that makes sense without secure timestamps,
is another discussion). CRLs do.
The OCSP responder is also allowed to forget about the revocation status
of any cert that's outside its validity period.
For more info on this, see RFC 2560, section 4.4.4, "Archive cutoff".
>> It requires that CAs NEVER "forget" about any certs they previously
>> issued, not even after they expire.
>
> They get paid for it, for each cert. Hotmail and Yahoo also never forget
> the email addresses that were issued (they may get deactivated, but the
> account still exists), and it's not even a paid service.
Nevertheless, the X.509 and PKIX standards don't require them to
remember revocation status after cert expiration. It is allowed, but not
required.
I heard that the Archive cutoff extension was also allowed for CRLs, but
I haven't found any reference that confirms that.
>
>>> This is what GPG
>>> does, too. This shows us that the new key is authorized by the
>>> old
>>> owner, so continuity is maintained.
>>>
>>
>> So, after a key is compromised, it remains desirable that replacement
>> keys
>> are authorized by a signature made with the compromised key?
>>
>
> Yes. It - at worst - means that either rightful owner or the attacker
> endorses the new key, reducing the candidates from the whole world to
> two. The CA needs to approve the new key as well, though, so the
> attacker has to gain *both* the old private key and get the approval of
> the CA.
Sorry, but that just doesn't make sense. And old keys can and do get
lost all the time.
> More importantly, it helps the normal situation that a the owner decides
> to use a new key, for whatever reason, and prevents a spurious warning
> for users in that case.
When someone chooses to use a new key, they can simply get a new
certificate containing the public key and get it signed by the CA. There
doesn't need to be any spurious warnings for anybody.
> The warning, in turn, ensures that you cannot just walk to *any* CA,
> without any connection to the victim site, and get a valid cert. It
> *has* to be signed by the private key, which means the attacker *has* to
> break into my systems.
You could also solve that problem by having only one trusted root, or
having roots that use name constraints. Then everybody would have only
one CA they could go to. That actually fits with x.500 pretty well. But
of course that would mean the end of competition between CAs, and it
would be a bad thing.
> This means that if I can manage to keep my systems secure, there's
> really no way an attacker can get between me and my existing users /
> communication partners. This is as secure as it gets. (If an attacker
> breaks into one of the partners' systems, all bets are off, in any system.)
Given what we know about warnings and how they are ignored by most users
who don't understand them, I certainly wouldn't put too much faith into
that !
Having roots with name constraints would be much more secure - since you
couldn't have other CAs issuing valid certs for your identity.
>> No, because the content of all extensions are included in the
>> computation of the signature.
>>
>
> Can we create another extension? The signature itself is a shell around
> the certified bits. Add the second signature around that first signature.
>
> There must be a way to add signatures. It's a base feature in PGP! If
> it's entirely impossible to have two signatures, and no way to add it to
> the spec, that's a design error. It's hard to believe that it's so limited.
If one wanted to have another signature, it wouldn't be as an extension,
since, as Nelson pointed out, extensions are part of what gets signed.
The current single signature is not an extension.
Well, I guess somebody did it anyway :
http://www.freepatentsonline.com/y2008/0270788.html
sigh.
Julien R Pierre - Sun Microsystems
Ian G wrote:
> Nelson's point was that CRLs become unbounded; but that's not a problem
> (a) if there are no disputes or (b) in an OCSP world. Pick (a) or (b).
Uh ?
In case a, even if there are no disputes, the CRL consumers all have to
update the ever-growing CRLs. This can consume gigantic amounts of
network bandwidth over time, especially if both the CRL and the number
of consumers of that CRL grows.
As for case b, if I understand correctly, you are saying CRLs growing
unbounded is not a problem in a world without CRLs. Right :) ?
The fact is that both CRLs and OCSP have their uses, in different places.
IMO, CRLs belong on backends, which have to process large volume of
incoming transactions, and can't afford to send outgoing OCSP requests
for all their incoming requests, under severe performance penalties.
OCSP is better suited for client apps, which should encounter a
relatively small number of certs from a given CA.
Eddy Nigg
>
> FYI, if a certificate is expired, NSS won't even bother performing a
> revocation check on it, either CRL or OCSP.
Are you sure?
> Ie. the expiration of the cert is more critical information than its
> revocation status
I think that's wrong as I explained in the previous mail.
> Yet the PSM UI lets you click to override the expiration of a cert, but
> not for revocation. I don't think it makes much sense to override either
> case.
Well...I think expiration has some use for control panels and such
stuff, without it one would have a hard time updating the cert in case
it was forgotten. The same is true for overriding an eventual exception
for initial cases (on a temporary basis). It happens to me every time I
install a new server.
Ben Bucksch
First off, please note that this is a proposed *change* to the PKI
system. A small change, but nevertheless a change, yes. We're trying to
make it more secure. So, "That goes against current definitions" is not
an argument, it's inherent.
> No, the question OCSP asks is ... "is this cert revoked, as of the
> current date" ?
That's what we need, yes.
> The OCSP responder is also allowed to forget about the revocation
> status of any cert that's outside its validity period.
Our CAs would not be allowed to do that. It's fairly trivial to keep the
whole list.
It's not going to grew over a Gigabyte, any MySQL could do that.
Including the replication to have it redundant.
Thanks for the note, though.
[Key continuity by old key signing new one]
> When someone chooses to use a new key, they can simply get a new
> certificate containing the public key and get it signed by the CA.
Currently, yes. But so could anybody else in the world who manages to
get past the CA. And immediately get access to all customers. (See below)
This is what I consider the inherent and most important weakness of the
PKI system, what makes it impossible for me to trust it. This is exactly
what this proposal is supposed to stop.
>> The warning, in turn, ensures that you cannot just walk to *any* CA,
>> without any connection to the victim site, and get a valid cert. It
>> *has* to be signed by the private key, which means the attacker *has*
>> to break into my systems.
> You could also solve that problem by having only one trusted root, or
> having roots that use name constraints. Then everybody would have only
> one CA they could go to.
No. If that one CA then doesn't do a decent job, makes an error, that's
no help either.
With "connection to the victim site", I meant that *I* (as cert owner)
have to be involved somehow in approving the certificate when it wants
to be valid for my existing users. "Involved" includes my site being
hacked, but that's at least something I can influence to some degree.
I have absolutely no control over how a CA does it job.
I don't want it to get into the middle of my *existing* relationships,
that's the core.
>> This means that if I can manage to keep my systems secure, there's
>> really no way an attacker can get between me and my existing users /
>> communication partners. This is as secure as it gets. (If an attacker
>> breaks into one of the partners' systems, all bets are off, in any
>> system.)
>
> Given what we know about warnings and how they are ignored by most
> users who don't understand them, I certainly wouldn't put too much
> faith into that !
If you assume that users ignore and override all warnings, we are
already screwed with the current system, because the user can also
override a self-signed cert. Yet, that warning is now a serious stopgap
for attackers of a bank. And it definitely helps security-conscious users.
> If one wanted to have another signature, it wouldn't be as an
> extension, since, as Nelson pointed out, extensions are part of what
> gets signed.
Yes, sorry for the inprecision, I meant here "extension" in the sense
that it's something added to the cert definition, not the existing
extension mechanism.
> The current single signature is not an extension.
>
> Well, I guess somebody did it anyway :
> http://www.freepatentsonline.com/y2008/0270788.html
Thanks for the link.
What I am thinking of (which I think is different from that patent) is
that we attach something to the end (or beginning) of the binary blob
that is the cert, in a way that it treated as garbage by older browsers.
Ben Bucksch
> The OCSP responder is also allowed to forget about the revocation
> status of any cert that's outside its validity period.
>
> Our CAs would not be allowed to do that. It's fairly trivial to keep
> the whole list.
P.S. That wouldn't even be strictly necessary, as I am not proposing to
dishonor the CA certificate. If the CA says it's expired, we would
consider it so, no change to now.
There's merely an *additional* requirement of the new key being signed
by the old one.
Ben Bucksch
I wasn't talking about money. There are more important things than money.
I was talking about emails (where the damage can be far higher, even for
private mails), application update, configuration frontends of my own
systems etc..
Obviously I "trust" the software I run, out of necessity. I do not trust
the CA operations. If there was minimal hope that they'd do a decent
job, that has been destroyed over last Christmas.
Ben
Ben Bucksch
Hi Robert,
thanks for the reply.
I think there are two major misconceptions, at least one of them my fault:
* I am not proposing to mandate that the private key stays the same
(contrary to what my original bullet list said). I am merely
proposing that the new key is signed by the old one, to authorize
the new one by the owner.
* I am not proposing to get rid of CAs, not proposing an SSH model.
KCM is in *addition* to current requirements.
Most of the discussion below can be explained with that.
On 09.01.2009 02:10, Robert Relyea wrote:
> Allowing the same private key over an extended time is a question of
> CA policy. Such allowances are already questionable *CRYPTO* (not PKI)
> policy. A system that requires the same key is a non-starter. This is
> crypto 101
I hope to see some reasons for that bold statement below, as most crypto
systems which are considered very secure use long-lasting or not
expiring keys.
That includes both SSH and PGP, which are both widely considered very
secure when fingerprints are verified correctly. The CAs are not a
threat to the security of *existing* relationships. This vector is
exactly what we propose to remove.
All the rest stays the same.
Note that I later said that the keys *can* be changed, if you consider
that better. The old one merely needs to sign the new one, to ensure
continuity.
> Debian-weak SSH keys never expire. The risk these keys pose to PKI
> based apps are small and shrinking.
Yes, that was a major screw-up.
However, fixing it is not a major problem for a responsible admin - he'd
just replace them. I don't think I was affected, but I changed the keys
of the systems which might have been affected anyways.
Also, the CA still can revoke the keys, even with this proposal.
(I think the fact that the CAs didn't do that was also a major screw-up
on their part. Any admin which didn't exchange the key himself would
quickly have noticed and replaced the cert. When waiting for expiry,
they were vulnerable for a year and didn't notice it.)
> The security value of a private key degrades over time. The rate of
> this effective degradation depends on the usage of the key, the
> strength, etc. 10-20 years for an RSA 1024 bit key issued today is
> definitely too long (independent on how it's used).
Sure. You're very welcome to replace the key in 5 years, when it's time
to do so.
> --------------------------
> KCM is popular among people who "know a little security" because it
> puts the burden of security in the users own hands. It makes sense. I
> want to control my own destiny.
Exactly.
> KCM is good for a single pipe between to fixed and seldom changing
> computers, which are set up by a conscientious, knowledgeable person.
> In the day to day operations it is an accident waiting to happen. I
> use ssh daily.
(Note: You're speaking of a KCM system without CA and without key
verification on first sight in practice. That's not the proposal here.)
> Machines get reloaded with new operating systems, events cause
> rekeying, I visit new machines that I don't deal with every day. The
> whole burden is placed on me to decide if I'm being attacked. 99.9% of
> the time I get a warning that is benign That .1 % when it's not, I'm
> now trained to ignore it....
FWIW:
I use SSH only for a few third-party machines, including the Mozilla CVS
and hg servers. When/If the key changed there, I asked or even filed bugs.
I use SSH mostly for my own machines, and I didn't have unexplainable
key changes so far. And the keys of machines at home are of course
exchanged at first sight by a direct wire inside my home. And I know
that if there is no way (apart from software bugs) for a third party
like a CA to introduce himself between me and my machines without an
alert (which I never had). That combination (and some trust in the
openbsd/openssh team and open source in general) makes me fairly
confident in the system. I can't have that confidence in solely
PKI-based systems, because I get no warning (or lots of spurious
warnings) in the same situation. That's why I propose to *add* KCM in
addition to PKI.
> The big secret is few (and I mean a lot fewer than people think) of
> us are sufficiently diligent enough to use such a scheme on a regular
> basis.
We all are less competent than we think, esp. in security, yes.
(I'm *not* pointing to you.)
> Mozilla is the same. Users are making lots of connections, often to
> new sites that they have never visited before. They trash their
> profiles. They reload their machines. They visit sites from their
> mom's computers. Even if you could get every website to follow the
> (poor security) practice of never changing their keys, you are
> generating so much noise that users will ignore key change warnings.
There would be no warning when the user first encounters a host with a
cert and he's never seen the host (as far as the profile goes) - we rely
on CAs as we currently do for the first connection. Only on the second
connection, the KCM kicks in and verifies that it's the same key, or the
new key is signed by the old key, the old one authorizing the new one
(if you prefer to change private keys, which is fine). So, in normal
scenario, there are no warnings for users, and we lose no security that
we currently have. We only add restrictions, namely that the admin signs
the new key with the old one. (I hope I explained in previous posts what
that is good for.)
Jean-Marc Desperrier
> [...]
> As for case b, if I understand correctly, you are saying CRLs growing
> unbounded is not a problem in a world without CRLs. Right :) ?
>
> The fact is that both CRLs and OCSP have their uses, in different places.
Also the problem is that if only the CA in a central location can answer
the OCSP response it becomes a single point of failure, so in many case
you need to have several responding entity, or at least several response
location. And need to transmit the revocation information between them.
So again you have a size problem even with OCSP.
Eddy Nigg
>
> Obviously I "trust" the software I run, out of necessity. I do not trust
> the CA operations. If there was minimal hope that they'd do a decent
> job, that has been destroyed over last Christmas.
>
I anticipated comments like this one, but the good thing is that stakes
are rather high for CAs, hence they are improving and resolutions happen
rather fast. This is at least true for some of the events we've seen
(Verisign, StartCom).
On the other hand, any flaw outside of CAs are up to individuals which
couldn't care less sometimes (as shown in the Debian fiasco). But as
Robert and Julien already said, those who care know in such cases.
Jean-Marc Desperrier
> [...]
> KCM is good for a single pipe between to fixed and seldom changing
> trains the user to ignore the warning messages. [...]
>
> Mozilla is the same. Users are making lots of connections, often to new
> sites that they have never visited before. They trash their profiles.
I wanted to make more or less the same point.
KCM in SSH works well with a small number of computer, if you have to
establish trust with a new one rarely, and if you keep connecting to the
same computers again and again, and their config almost never changes.
This really doesn't scale to the internet and SSL. Even casual users can
visit hundred of sites in one day, and for most of them never come back
to visit them again later.
Also, there's another important pattern I notice with SSL use on the
internet :
- They are few sites on which SSL is both really important and that are
misconfigured.
- They are many sites (the most in those 8% of self-signed certs) where
SSL is completely misconfigured but it's not so important, because
whilst there's some info I want to *read* on the site I certainly don't
intend to send it any sensitive info.
Which means that more often than not the default checking of the
"Permanently store this exception" check-box of Fx, is annoying for me.
Because I just want to see what's on this site this one time, thank you
Fx for warning me it hasn't proper protection, but don't clutter my
profile with that, and on the whole I'd prefer to be warned again if I
ever come back again to the same site.
Paul Hoffman
>On 01/09/2009 12:15 AM, Nelson B Bolyard:
>>It requires that CAs NEVER "forget" about any certs they previously
>>issued, not even after they expire. It means that a CA's list of revoked
>>certs will grow boundlessly. It makes CRLs become impractically big.
>
>Well...StartCom NEVER removes a certificate from the CRL once revoked. That's because people tend to view expired certificates as an annoyance, not critical. However a revoked certificate should never be accessible anymore. (Just think about the mozilla.com certificate. I bet that the majority would click through that certificate in case of "expiration", whereas they can't because of revocation. There is an inherent difference between the two).
Eddy, do your postings *always* have to sound like blatant advertising for StartCom, even when you are saying that you make one of the many valid choices?
RFC 5280 explicitly allows CAs to only list unexpired certs in its CRLs. In fact, that is the only scenario that is listed; the one that you have chosen is allowed but not emphasized as much as the one that Nelson described.
Julien R Pierre - Sun Microsystems
Eddy Nigg wrote:
> On 01/09/2009 03:41 AM, Julien R Pierre - Sun Microsystems:
>>
>> FYI, if a certificate is expired, NSS won't even bother performing a
>> revocation check on it, either CRL or OCSP.
>
> Are you sure?
Yes. The validity check is one of the earliest ones that happens on the
cert.
See
http://mxr.mozilla.org/security/source/security/nss/lib/certhigh/certvfy.c#1091
Also
http://mxr.mozilla.org/security/source/security/nss/lib/certhigh/certvfy.c#1326
There are a few new cert validation in libpkix for NSS 3.12 , but I
think still the expiration check remains an early one, and it definitely
is optimized to do revocation checks only when needed.
>> Ie. the expiration of the cert is more critical information than its
>> revocation status
>
> I think that's wrong as I explained in the previous mail.
Well, we'll just have to agree to disagree :) IMO revocation really
doesn't matter if you already know the certificate is invalid at the
time you are checking it. It's like trying to check a dead person's pulse.
>> Yet the PSM UI lets you click to override the expiration of a cert, but
>> not for revocation. I don't think it makes much sense to override either
>> case.
>
> Well...I think expiration has some use for control panels and such
> stuff, without it one would have a hard time updating the cert in case
> it was forgotten. The same is true for overriding an eventual exception
> for initial cases (on a temporary basis). It happens to me every time I
> install a new server.
Time zone issues, perhaps. Or time sync. I have seen those kinds of
problems before. They shouldn't last very long though.
Julien R Pierre - Sun Microsystems
Ben Bucksch wrote:
> Our CAs would not be allowed to do that. It's fairly trivial to keep the
> whole list.
> It's not going to grew over a Gigabyte, any MySQL could do that.
> Including the replication to have it redundant.
Certainly it's trivial, but not inexpensive especially on large scales.
And currently it just isn't guaranteed to happen in most CAs. It
certainly should be allowed to a degree. I think many CAs will keep the
serial numbers of expired certs on their CRLs for a few years after
expiration. But I don't think most do that indefinitely.
One big problem is that there is currently no way to tell which CAs do
and do not.
>>> The warning, in turn, ensures that you cannot just walk to *any* CA,
>>> without any connection to the victim site, and get a valid cert. It
>>> *has* to be signed by the private key, which means the attacker *has*
>>> to break into my systems.
>> You could also solve that problem by having only one trusted root, or
>> having roots that use name constraints. Then everybody would have only
>> one CA they could go to.
>
> No. If that one CA then doesn't do a decent job, makes an error, that's
> no help either.
If that happens, then you could stop trusting it, and replace it with
another root that does a better job.
But overall I think it's better to have a system with multiple roots and
ovelapping name spaces to maintain competition. However it definitely
reduces security - the more roots we have, the more difficult it is to
trust them all. That's why audits become even more important.
> If you assume that users ignore and override all warnings, we are
> already screwed with the current system, because the user can also
> override a self-signed cert. Yet, that warning is now a serious stopgap
> for attackers of a bank. And it definitely helps security-conscious users.
Well, I do consider that a serious problem - most users don't understand
PKI, and probably have no business overriding any self signed cert warning.
> What I am thinking of (which I think is different from that patent) is
> that we attach something to the end (or beginning) of the binary blob
> that is the cert, in a way that it treated as garbage by older browsers.
Unfortunately, that wouldn't be possible, because it would violate the
existing ASN.1 definition of the signed certificate. There is no
optional field where you could fit a second signature.
In any case, you can just get a second certificate with the same public
key from another CA if you need that ability. It doesn't have to be in
the same unique cert.
Eddy Nigg
> At 12:42 AM +0200 1/9/09, Eddy Nigg wrote:
>> On 01/09/2009 12:15 AM, Nelson B Bolyard:
>>> It requires that CAs NEVER "forget" about any certs they previously
>>> issued, not even after they expire. It means that a CA's list of revoked
>>> certs will grow boundlessly. It makes CRLs become impractically big.
>> Well...StartCom NEVER removes a certificate from the CRL once revoked. That's because people tend to view expired certificates as an annoyance, not critical. However a revoked certificate should never be accessible anymore. (Just think about the mozilla.com certificate. I bet that the majority would click through that certificate in case of "expiration", whereas they can't because of revocation. There is an inherent difference between the two).
>
> Eddy, do your postings *always* have to sound like blatant advertising for StartCom, even when you are saying that you make one of the many valid choices?
>
Some CAs which participate here refer to what they are doing - in this
specific case I think it was relevant to show the experience in not
removing the entries in the CRL/OCSP. Or how else should I have told you
that there were no negative effects if done correctly? But I agree with
you that it shouldn't look like an advertisement for the organization I
work. I'll try to refrain from mentioning whenever possible.
> RFC 5280 explicitly allows CAs to only list unexpired certs in its CRLs. In fact, that is the only scenario that is listed; the one that you have chosen is allowed but not emphasized as much as the one that Nelson described.
Correct, still I believe in the point I made before, based on
experience. Apparently others thought the same independently of me.
Eddy Nigg
> Well, we'll just have to agree to disagree :) IMO revocation really
> doesn't matter if you already know the certificate is invalid at the
> time you are checking it. It's like trying to check a dead person's pulse.
>
Then there isn't perhaps much logic in disallowing any override
capability for revocations, whereas expiration can be overridden via
exception. No exception can be added for revoked certificates, but for
expired ones it's possible - hence it suggests that revocation is more
severe than expired (if one can think in those terms). Or how would you
explain that?
Julien R Pierre - Sun Microsystems
Eddy Nigg wrote:
> On 01/09/2009 10:20 PM, Julien R Pierre - Sun Microsystems:
>> Well, we'll just have to agree to disagree :) IMO revocation really
>> doesn't matter if you already know the certificate is invalid at the
>> time you are checking it. It's like trying to check a dead person's
>> pulse.
>>
>
> Then there isn't perhaps much logic in disallowing any override
> capability for revocations, whereas expiration can be overridden via
> exception. No exception can be added for revoked certificates, but for
> expired ones it's possible - hence it suggests that revocation is more
> severe than expired (if one can think in those terms). Or how would you
> explain that?
I agree, the UI is not logical. IMO, there should be no override for
either case.
Eddy Nigg
>> Then there isn't perhaps much logic in disallowing any override
>> capability for revocations, whereas expiration can be overridden via
>> exception. No exception can be added for revoked certificates, but for
>> expired ones it's possible - hence it suggests that revocation is more
>> severe than expired (if one can think in those terms). Or how would
>> you explain that?
>
> I agree, the UI is not logical. IMO, there should be no override for
> either case.
Can you open a bug (and propose a patch :-) ). Kai should be copied on it.
Jean-Marc Desperrier
> [...]
> I think many CAs will keep the serial numbers of expired certs on
> their CRLs for a few years after expiration. But I don't think most
> do that indefinitely. One big problem is that there is currently no
> way to tell which CAs do and do not.
The policy could *strongly suggest* for CA to include the
expiredCertsOnCRL extension ?
http://www.imc.org/ietf-pkix/mail-archive/msg01962.html
It's quite unfortunate that efforts to include the description of
expiredCertsOnCRL inside RFC5280 from X.509 were not successful ("it has
already too many things" like if it didn't have a lot of things that are
massively less useful than expiredCertsOnCRL), but I don't think it a
good enough reason to deter any effort to use this simple but effective
extension to document which certs are and aren't removed from the CRL.
Jean-Marc Desperrier
> [...] No exception can be added for revoked certificates, but for
> expired ones it's possible - hence it suggests that revocation is more
> severe than expired (if one can think in those terms). Or how would you
> explain that?
As I have already found myself in the situation of really needing to
override an expired certificate, I beg to differ and find an explanation.
In the case of revoked certificates, you have positive proof that the CA
wants that cert to be revoked.
In the case of expired certificates, you just don't know. So it leave
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.
Another way of seeing this : The trouble here is that the Firefox SSL
model mixes two things, telling me that the site is invalid, and letting
me access it or not. Which as a consequence means that I sometimes need
to override it whilst knowing the site is really invalid but I just need
to access it despite that.
The mail security model doesn't do that : I'll have a broken key but
I'll still be able to read the mail even if the signature is invalid.
Eddy Nigg
> Eddy Nigg wrote:
>> [...] No exception can be added for revoked certificates, but for
>> expired ones it's possible - hence it suggests that revocation is more
>> severe than expired (if one can think in those terms). Or how would you
>> explain that?
>
> As I have already found myself in the situation of really needing to
> override an expired certificate, I beg to differ and find an explanation.
>
> In the case of revoked certificates, you have positive proof that the CA
> wants that cert to be revoked.
Indeed! That was the point I was trying to make (and why i believe that
expired but revoked certificates should never be removed from the CRL).
Considering that intermediate CAs are more and more common and the
encouraged practice anyway (and required by EV), those CRLs shouldn't
grow that badly until the issuing CA certificate expires. As Julien also
mentioned, some CAs keep the revoked certs for a period of N years in
the CRL - with intermediates assumed limited life-time, we aren't really
far from that.
>
> In the case of expired certificates, you just don't know. So it leave
> 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 with an expired cert.
Rob Stradling
Eddy, the EV Guidelines impose certain requirements on Intermediate CAs *when*
they are used, but AFAIK they don't mandate that Intermediate CAs MUST be
used.
Visit https://www.securetrust.com in FF3 for an example of an EV-enabled Root
Certificate (CN = SecureTrust CA) that issues EV SSL Certificates without
involving any Intermediate CA(s) in the certificate chain.
--
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. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
Eddy Nigg
> "and required by EV" ?
>
> Eddy, the EV Guidelines impose certain requirements on Intermediate CAs *when*
> they are used, but AFAIK they don't mandate that Intermediate CAs MUST be
> used.
>
> Visit https://www.securetrust.com in FF3 for an example of an EV-enabled Root
> Certificate (CN = SecureTrust CA) that issues EV SSL Certificates without
> involving any Intermediate CA(s) in the certificate chain.
>
Did just that....and this site's certificate is signed by "SecureTrust
CA" which chains to "Entrust.net Secure Server Certification Authority".
But besides that, it's perhaps not clearly defined in the EV Guidelines,
but section 7 suggests that there are no roots issuing directly.
Rob Stradling
> 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 mandate that Intermediate CAs
> > MUST be used.
> >
> > Visit https://www.securetrust.com in FF3 for an example of an EV-enabled
> > Root Certificate (CN = SecureTrust CA) that issues EV SSL Certificates
> > without involving any Intermediate CA(s) in the certificate chain.
>
> Did just that....and this site's certificate is signed by "SecureTrust
> CA" which chains to "Entrust.net Secure Server Certification Authority".
The "Entrust.net Secure Server Certification Authority" is used for legacy
ubiquity only. Entrust and SecureTrust (aka Trustwave) have different EV
Certificate Policy OIDs. https://www.securetrust.com only gets the EV UI in
FF3 (and other EV-capable browsers) because the "SecureTrust CA" self-signed
Root Certificate is enabled for EV.
That's why Larry says "Verified by: SecureTrust Corporation", rather
than "Verified by: Entrust, Inc." for https://www.securetrust.com.
> But besides that, it's perhaps not clearly defined in the EV Guidelines,
> but section 7 suggests that there are no roots issuing directly.
I disagree. Section 7 says that "EV Subordinate CA Certificates" may exist,
and it imposes some restrictions relating to Certificate Policy OIDs. But it
does not say that "Root CA Certificates" should not be used for issuing
end-entity EV Certificates. In fact, it says...
"The Application Software Vendor identifies Root CAs that are approved to
issue EV Certificates..."
...which surely cannot mean "Root CAs are not approved to issue EV
Certificates" !
Eddy Nigg
> The "Entrust.net Secure Server Certification Authority" is used for legacy
> ubiquity only. Entrust and SecureTrust (aka Trustwave) have different EV
> Certificate Policy OIDs. https://www.securetrust.com only gets the EV UI in
> FF3 (and other EV-capable browsers) because the "SecureTrust CA" self-signed
> Root Certificate is enabled for EV.
I can't find the SecureTrust CA request for enabling EV. It's not on the
pending list, not on the included list, nor could I find bug for it...
anybody know where the paper trail is for this CA?
>
> That's why Larry says "Verified by: SecureTrust Corporation", rather
> than "Verified by: Entrust, Inc." for https://www.securetrust.com.
>
I'm almost certain that the "Verified by" usually lists the last CA
certificate in the chain. At least for regular SSL certs.
> I disagree. Section 7 says that "EV Subordinate CA Certificates" may exist,
> and it imposes some restrictions relating to Certificate Policy OIDs. But it
> does not say that "Root CA Certificates" should not be used for issuing
> end-entity EV Certificates. In fact, it says...
> "The Application Software Vendor identifies Root CAs that are approved to
> issue EV Certificates..."
> ...which surely cannot mean "Root CAs are not approved to issue EV
> Certificates" !
Than this is another issue to suggest change. Perhaps I wanted it to
read that EV roots which are approved to issue EV certs, but issuing
from intermediate - as most CAs actually have done so. That includes
Verisign (most notable) which transitioned to issuing from
intermediate's a while ago. Mozilla doesn't enable intermediate CAs, it
enables roots, even if only one intermediate issues EV and the root
never does directly.
Ian G
> Eddy Nigg wrote:
>> [...] No exception can be added for revoked certificates, but for
>> expired ones it's possible - hence it suggests that revocation is more
>> severe than expired (if one can think in those terms). Or how would you
>> explain that?
>
> As I have already found myself in the situation of really needing to
> override an expired certificate, I beg to differ and find an explanation.
>
> In the case of revoked certificates, you have positive proof that the CA
> wants that cert to be revoked.
And in the case of an expired certificate, you have positive proof that
the CA wants that cert expired.
These are word games. What is the definition of these words? If you
look in the RFCs, likely (I have not, please correct me if I am wrong)
it will defer the precise definition of these two words and their
relationship up to the CPS. Which means they are anything that *each
CA* decides upon.
The end result is quite open in practice. There are some reason codes
for revocation, but they are not necessarily followed. Some people
revoke certs because they are no longer using them, not because they are
compromised in any way. CAs can offer to unrevoke certs by taking them
out of the CRLs. Some CAs apparently offer the "suspended" state...
For some reason, revocation is not the killer-option it is in the
OpenPGP world, where a key signs its own death warrant, and once
released can never be called back.
So we end up with revocation being approximately like expiry. About the
only thing you can say is "the CA doesn't want us to use that cert."
Indeed if you consider the structure of certs over time, revocation has
to be more or less the same as expiry, because the real reason for
expiry is that the CRLs need to be bounded. PKI doesn't need expiry if
it doesn't need revocation. We need revocation therefore we need expiry.
("Need" here means, to make the thing work, as opposed to a useful
user-level feature of choice.)
> In the case of expired certificates, you just don't know. So it leave
> 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.
Perhaps a way to ask this is, when you see a revoked certificate listed
in a CRL, do you have faith in the reason codes? If the reason codes
tell you something mild, can you exclude the possibility of compromise?
Are you going to go through the CPS and the RFCs and figure out where
you stand?
iang
Rob Stradling
> 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 Certificate Policy OIDs. https://www.securetrust.com only
> > gets the EV UI in FF3 (and other EV-capable browsers) because the
> > "SecureTrust CA" self-signed Root Certificate is enabled for EV.
>
> I can't find the SecureTrust CA request for enabling EV. It's not on the
> pending list, not on the included list, nor could I find bug for it...
> anybody know where the paper trail is for this CA?
https://bugzilla.mozilla.org/show_bug.cgi?id=409837
> > That's why Larry says "Verified by: SecureTrust Corporation", rather
> > than "Verified by: Entrust, Inc." for https://www.securetrust.com.
>
> I'm almost certain that the "Verified by" usually lists the last CA
> certificate in the chain. At least for regular SSL certs.
Ah yes, you may well be right. I was probably thinking of IE7's equivalent
behaviour.
In any case, if you compare the EV Policy OIDs mentioned in Bug #409837
(SecureTrust) and Bug #416544 (Entrust) with the EV Policy OID in the site
certificate for www.securetrust.com, you'll see that it's the "SecureTrust
CA" which gives that site the EV UI.
> > I disagree. Section 7 says that "EV Subordinate CA Certificates" may
> > exist, and it imposes some restrictions relating to Certificate Policy
> > OIDs. But it does not say that "Root CA Certificates" should not be used
> > for issuing end-entity EV Certificates. In fact, it says...
> > "The Application Software Vendor identifies Root CAs that are approved to
> > issue EV Certificates..."
> > ...which surely cannot mean "Root CAs are not approved to issue EV
> > Certificates" !
>
> Than this is another issue to suggest change. Perhaps I wanted it to
> read that EV roots which are approved to issue EV certs, but issuing
> from intermediate - as most CAs actually have done so. That includes
> Verisign (most notable) which transitioned to issuing from
> intermediate's a while ago. Mozilla doesn't enable intermediate CAs, it
> enables roots, even if only one intermediate issues EV and the root
> never does directly.
Just because VeriSign use Intermediates for EV, I don't think that means that
Mozilla should require CAs such as SecureTrust to do the same.
Eddy Nigg
>> I can't find the SecureTrust CA request for enabling EV. It's not on the
>> pending list, not on the included list, nor could I find bug for it...
>> anybody know where the paper trail is for this CA?
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=409837
It's even on my CC's list...but I used search:
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=SecureTrust
I think search is broken because it reports "Zarro Boogs found." :S
Or maybe the simple search only returns new and open bugs.
>
> Just because VeriSign use Intermediates for EV, I don't think that means that
> Mozilla should require CAs such as SecureTrust to do the same.
>
No, it's because Mozilla itself views this as the correct practice. I
would go as far and require it, simple as that. That should be really an
issue for the CAB forum however. BTW, my point wasn't *because* of
Verisign, but *even* Verisign does it ;-)
Rob Stradling
<snip>
> I would go as far and require it, simple as that.
You are entitled to your opinion.
> That should be really an issue for the CAB forum however.
So why don't you join the CA/Browser Forum and share your opinion?
> BTW, my point wasn't *because* of Verisign, but *even* Verisign does it ;-)
OK.
Eddy Nigg
>
> So why don't you join the CA/Browser Forum and share your opinion?
>
Patience is one of the ingredients for success... getting there!
Paul Hoffman
>These are word games. What is the definition of these words? If you look in the RFCs, likely (I have not, please correct me if I am wrong)
A better idea would be for all of us to read them and point out where in the document it says something.
For example, in the case of "expired", you are wrong. Nothing in RFC 5280 says that expiration (or, more formally, the end of the certificate validity period) has anything to do with the CPS.
Ian G
> At 1:52 PM +0100 1/12/09, Ian G wrote:
>> These are word games. What is the definition of these words? If you look in the RFCs, likely (I have not, please correct me if I am wrong)
>
> A better idea would be for all of us to read them and point out where in the document it says something.
OK, I did that, for revocation. See the copied snippets below, for
anyone who wants to quickly skim the bits I found.
> For example, in the case of "expired", you are wrong. Nothing in RFC 5280 says that expiration (or, more formally, the end of the certificate validity period) has anything to do with the CPS.
I guess I didn't explain myself well enough. Here's the logic:
* RFC5280 is an implementation document and doesn't do
semantics much, if at all.
* It does not define the meaning of expiry or revocation.
* By _meaning_, I mean semantics, what outsiders should take
as the message being delivered, implying some hint as to
action.
* RFC5280 does suggest that they work together.
* (I conclude that) RFC5280 suggests that:
*revocation and out-of-validation have the same meaning*.
* But we still don't know what that meaning is.
* (see especially last three paras at bottom.)
* Because the purpose of certs is to do something with them,
for end-users, and that something is intended to be turned
on or off according to expiry and revocation, then I
conclude that the meaning MUST be available to end-users.
* RFC3647, section 4.4.9 says
"Revocation checking requirement for relying parties"
which ties revocation to reliance, within the CPS
* The CA typically ties reliance to an unrevoked and
unexpired cert.
* For sake of today's discussion, let's say the meaning is:
*you MUST NOT rely*
at least as an example of what it could be.
* In PKI concepts, reliance is defined in the CPS
* In CA/secure browsing, reliance is commonly in RPAs.
* I would conclude it should be in one of those two.
* In CAcert, which I audit, there is no exact definition,
but there is sufficient discussion that the meaning is
clear, there is a full stop to the end of any sentance.
Sorry for being so wordy, but this is just yet another example of where
the end-user was totally forgotten in the discussion of secure browsing.
iang
=======================RFC5280 selected snippets
"CAs are responsible for indicating the revocation status of the
certificates that they issue."
3.3. Revocation
"When a certificate is issued, it is expected to be in use for its
entire validity period. However, various circumstances may cause a
certificate to become invalid prior to the expiration of the validity
period. Such circumstances include change of name, change of
association between subject and CA (e.g., an employee terminates
employment with an organization), and compromise or suspected
compromise of the corresponding private key. Under such
circumstances, the CA needs to revoke the certificate.
" An entry MUST NOT be removed
from the CRL until it appears on one regularly scheduled CRL issued
beyond the revoked certificate's validity period.
*this above would make one of my comments wrong, but*
" Once the CA accepts a revocation report as
authentic and valid, any query to the on-line service will correctly
reflect the certificate validation impacts of the revocation.
" (f) revocation request: An authorized person advises a CA of an
abnormal situation requiring certificate revocation.
" This may be accomplished by expiration or
revocation of all CA certificates containing the public key used to
verify the signature on the certificate and discontinuing use of the
public key used to verify the signature on the certificate as a trust
anchor.
" If the DistributionPoint omits the reasons field, the CRL MUST
include revocation information for all reasons. This profile
RECOMMENDS against segmenting CRLs by reason code.
" A complete CRL lists all unexpired certificates, within its scope,
that have been revoked for one of the revocation reasons covered by
the CRL scope. A full and complete CRL lists all unexpired
certificates issued by a CA that have been revoked for any reason.
" The CRL issuer MAY also generate delta CRLs. A delta CRL only lists
those certificates, within its scope, whose revocation status has
changed since the issuance of a referenced complete CRL.
*this above would be more the spirit of unrevokation!*
" This profile defines one private Internet CRL extension but does not
define any private CRL entry extensions.
Environments with additional or special purpose requirements may
build on this profile or may replace it.
" revokedCertificates SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber,
revocationDate Time,
crlEntryExtensions Extensions OPTIONAL
-- if present, version MUST be v2
} OPTIONAL,
crlExtensions [0] EXPLICIT Extensions OPTIONAL
-- if present, version MUST be v2
}
" ......each entry on the revoked certificate
list is defined by a sequence of user certificate serial number,
revocation date, and optional CRL entry extensions.
" The revoked certificate list is optional to support the
case where a CA has not revoked any unexpired certificates that it
has issued.
" Additional information
may be supplied in CRL entry extensions; CRL entry extensions are
discussed in Section 5.3.
" (b) If the certificate is valid and was listed on the referenced
base CRL or any subsequent CRL with reason code
certificateHold, and the reason code certificateHold is
included in the scope of the CRL, list the certificate with
the reason code removeFromCRL.
*Ah, that's what I was thinking about.....*
" (c) If the certificate is revoked for a reason outside the scope
of the CRL, but the certificate was listed on the referenced
base CRL or any subsequent CRL with a reason code included in
the scope of this CRL, list the certificate as revoked but
omit the reason code.
(d) If the certificate is revoked for a reason outside the scope
of the CRL and the certificate was neither listed on the
referenced base CRL nor any subsequent CRL with a reason code
included in the scope of this CRL, do not list the
certificate on this CRL.
The status of a certificate is considered to have changed if it is
revoked (for any revocation reason, including certificateHold), if it
is released from hold, or if its revocation reason changes.
It is appropriate to list a certificate with reason code
removeFromCRL on a delta CRL even if the certificate was not on hold
in the referenced base CRL. If the certificate was placed on hold in
any CRL issued after the base but before this delta CRL and then
released from hold, it MUST be listed on the delta CRL with
revocation reason removeFromCRL.
A CRL issuer MAY optionally list a certificate on a delta CRL with
reason code removeFromCRL if the notAfter time specified in the
certificate precedes the thisUpdate time specified in the delta CRL
and the certificate was listed on the referenced base CRL or in any
CRL issued after the base but before this delta CRL.
" The reason codes associated with a distribution point MUST be
specified in onlySomeReasons. If onlySomeReasons does not appear,
the distribution point MUST contain revocations for all reason codes.
CAs may use CRL distribution points to partition the CRL on the basis
of compromise and routine revocation. In this case, the revocations
with reason code keyCompromise (1), cACompromise (2), and
aACompromise (8) appear in one distribution point, and the
revocations with other reason codes appear in another distribution
point.
" If a CRL includes an issuingDistributionPoint extension with
onlySomeReasons present, then every certificate in the scope of the
CRL that is revoked MUST be *assigned a revocation reason* other than
unspecified. The assigned revocation reason is used to determine on
which CRL(s) to list the revoked certificate, however, *there is no
requirement to include the reasonCode CRL entry extension* in the
corresponding CRL entry.
*my emphasis*
" 5.3.1. Reason Code
The reasonCode is a non-critical CRL entry extension that identifies
the reason for the certificate revocation. CRL issuers are strongly
encouraged to include meaningful reason codes in CRL entries;
however, the reason code CRL entry extension SHOULD be absent instead
of using the unspecified (0) reasonCode value.
The removeFromCRL (8) reasonCode value may only appear in delta CRLs
and indicates that a certificate is to be removed from a CRL because
either the certificate expired or was removed from hold. All other
reason codes may appear in any CRL and indicate that the specified
certificate should be considered revoked.
id-ce-cRLReasons OBJECT IDENTIFIER ::= { id-ce 21 }
-- reasonCode ::= { CRLReason }
CRLReason ::= ENUMERATED {
unspecified (0),
keyCompromise (1),
cACompromise (2),
affiliationChanged (3),
superseded (4),
cessationOfOperation (5),
certificateHold (6),
-- value 7 is not used
removeFromCRL (8),
privilegeWithdrawn (9),
aACompromise (10) }
"5.3.2. Invalidity Date
The invalidity date is a non-critical CRL entry extension that
provides the date on which it is known or suspected that the private
key was compromised or that the certificate otherwise became invalid.
This date may be earlier than the revocation date in the CRL entry,
which is the date at which the CA processed the revocation.
" 6.1.3. Basic Certificate Processing
The basic path processing actions to be performed for certificate i
(for all i in [1..n]) are listed below.
....
(3) At the current time, the certificate is not revoked.
....
If any of steps (a), (b), (c), or (f) fails, the procedure
terminates, returning a failure indication and an appropriate reason.
" The algorithm output is the revocation status of the certificate.
" (a) reasons_mask: This variable contains the set of revocation
reasons supported by the CRLs and delta CRLs processed so
far. The legal members of the set are the possible
revocation reason values minus unspecified: keyCompromise,
cACompromise, affiliationChanged, superseded,
cessationOfOperation, certificateHold, privilegeWithdrawn,
and aACompromise. The special value all-reasons is used to
denote the set of all legal members. This variable is
initialized to the empty set.
"8. Security Considerations
" If such a compromise is detected, all
certificates issued to the compromised CA MUST be revoked, preventing
services between its users and users of other CAs
" The availability and freshness of revocation information affects the
degree of assurance that ought to be placed in a certificate. While
certificates expire naturally, events may occur during its natural
lifetime that negate the binding between the subject and public key.
If revocation information is untimely or unavailable, the assurance
associated with the binding is clearly reduced. Relying parties
might not be able to process every critical extension that can appear
in a CRL. CAs SHOULD take extra care when making revocation
information available only through CRLs that contain critical
extensions, particularly if support for those extensions is not
mandated by this profile.
" Similarly, implementations
of the certification path validation mechanism described in Section 6
that omit revocation checking provide less assurance than those that
support it.
Paul Hoffman
> * RFC5280 is an implementation document and doesn't do
> semantics much, if at all.
> * It does not define the meaning of expiry or revocation.
> * By _meaning_, I mean semantics, what outsiders should take
> as the message being delivered, implying some hint as to
> action.
So far, you are zero for three. RFC 5280 does indeed say what semantics a relying party should use with respect to things like revocation and expiration. (You did get as far as section 6, didn't you?)
> * RFC5280 does suggest that they work together.
I have no idea what this means.
> * (I conclude that) RFC5280 suggests that:
>
> *revocation and out-of-validation have the same meaning*.
Revocation is an action taken by a CA. Expiration happens when time elapses. Notice how different those are.
I'm skipping the rest because it is clear we read the same base document completely differently.
Kyle Hamilton
basically saying, "I attest to the validity of this binding until this
date, *unless something extraordinary happens in the meantime*."
They really do have the same meaning -- that the CA is not willing to
attest to the identity binding. After expiration, the CA doesn't give
one whit about the bound key -- and the entity which owned the
privatekey in question could hand that key over to someone else, and
the CA doesn't need to do anything at all because it has already
acted.
Remember, *everything* in the certificate is an action of the CA. It
is the final actor in the creation of the certificate, and it is the
final actor in the revocation of the certificate.
-Kyle H
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
Eddy Nigg
>
> Remember, *everything* in the certificate is an action of the CA. It
> is the final actor in the creation of the certificate, and it is the
> final actor in the revocation of the certificate.
>
That's correct for the CA, the UI suggests something else which Julien
and me have been discussing already. There is no consistency in the UI
then...
Ian G
> At 10:07 PM +0100 1/12/09, Ian G wrote:
>> * RFC5280 is an implementation document and doesn't do
>> semantics much, if at all.
>> * It does not define the meaning of expiry or revocation.
>> * By _meaning_, I mean semantics, what outsiders should take
>> as the message being delivered, implying some hint as to
>> action.
>
> So far, you are zero for three. RFC 5280 does indeed say what semantics a relying party should use with respect to things like revocation and expiration. (You did get as far as section 6, didn't you?)
OK, so I'm wrong. I'd invite you and anyone to read section 6 in RFC
5280 and to point out, in its words, what a relying party is supposed to
do when expiry and revocation is detected? Some notes:
* With special emphasis on the differences....
* it has to mean something to an end-user.
If you can find it, then I'll accept that I'm wrong, but even then:
* let's see these semantics?
* RFC5280 is murky beyond belief,
* cannot be relied upon for end-user semantics,
* RFC3647 clearly puts it in the CPS
That's a tough barrier to climb.
I believe I've made my case, in that
1. expiration means approx the same thing as revocation,
2. if you want to define it differently, do it in the CPS,
3. but it is pointless and distracting to do that,
4. nobody else will likely support your difference.
iang
================for completeness:
>> * RFC5280 does suggest that they work together.
>
> I have no idea what this means.
Revocation works together with expiry, in some sense. In terms of
semantic signals to the users, their functions are highly linked, so we
can assume that the meanings are close if not exact.
>> * (I conclude that) RFC5280 suggests that:
>>
>> *revocation and out-of-validation have the same meaning*.
>
> Revocation is an action taken by a CA. Expiration happens when time elapses. Notice how different those are.
I don't care what the action is that causes this meaning, I care what
the meaning is.
A flashing orange light on the right hand side of a car, and a right
hand extended out the window, both have the same semantics:
"car about to turn right"
(leaving aside some complications for the steering wheel side.)
Or another example, more about actors and meanings. Alice shoots Bob.
Bob falls under a train. These are different actions, same results.
Bob is dead, we are unhappy, and no more contracts in Bob's name.
> I'm skipping the rest because it is clear we read the same base document completely differently.
We're obviously reading at crosspurposes. What RFC5280 says is how to
get a reason code. Versus check expiry. Where does it go beyond that?
With your hint, here we go. Sentence by sentence:
=====================================
"6. Certification Path Validation
Certification path validation procedures for the Internet PKI are
based on the algorithm supplied in [X.509].
(*implementation*)
Certification path
processing verifies the binding between the subject distinguished
name and/or subject alternative name and subject public key.
(*relevant to question* but unclear semantics.)
The
binding is limited by constraints that are specified in the
certificates that comprise the path and inputs that are specified by
the relying party.
(*refers to something else*, "constraints")
The basic constraints and policy constraints
extensions allow the certification path processing logic to automate
the decision making process.
(*implementation*)
This section describes
(entire para is *implementation*)...
The selection of a trust anchor...
(interesting, admits policy)
OK, skipping ahead because we've already lost all the others:
" Therefore, the algorithm only includes checks to verify that the
certification path is valid according to X.509 and does not include
checks to verify that the certificates and CRLs conform to this
profile.
(this is an *implementation*)
" The primary goal of path validation is to verify the binding between
a subject distinguished name or a subject alternative name and
subject public key, as represented in the target certificate, based
on the public key of the trust anchor.
(ok, interesting, but silent on semantics of invalid binding.)
" If check (a), (k), (l), (n), or (o) fails, the procedure terminates,
returning a failure indication and an appropriate reason.
(*implementation*)
Paul Hoffman
>Technically, 'expiration' is also an action taken by the CA.
No, it is an action taken by time passing. When the time in the univers is the same as the time listed as "notAfter" in the cert, the cert expires. That's it.
>It's
>basically saying, "I attest to the validity of this binding until this
>date, *unless something extraordinary happens in the meantime*."
No, that's *way* too strong. The meaning of the notAfter date is quite simple: "the date on which the certificate validity period ends". (See the subject of this thread....). A revoked certificate does not expire until after the notAfter.
>They really do have the same meaning -- that the CA is not willing to
>attest to the identity binding.
No, they really don't have the same meaning. Revocation can happen even if the CA is willing to attest to the binding but knows that doing so is silly, such as if the CA knows that the public key has been destroyed. Similarly, a CA might still attest to the binding between the public key and the identity in a different certificate.
>After expiration, the CA doesn't give
>one whit about the bound key -- and the entity which owned the
>privatekey in question could hand that key over to someone else, and
>the CA doesn't need to do anything at all because it has already
>acted.
Quite right.
>Remember, *everything* in the certificate is an action of the CA. It
>is the final actor in the creation of the certificate, and it is the
>final actor in the revocation of the certificate.
An action at birth is quite different than an action at revocation.
Eddy Nigg
>
> 1. expiration means approx the same thing as revocation,
> 2. if you want to define it differently, do it in the CPS,
> 3. but it is pointless and distracting to do that,
> 4. nobody else will likely support your difference.
>
Good analysis!
Julien R Pierre - Sun Microsystems
Thanks for that link.
NSS is still trying to catch up to RFC 3280, let alone 5280.
I agree it's unfortunate that this extension didn't make it into RFC
5280 . I don't have the time to particpate in ietf-pkix discussions,
though. Is this extension defined in any other RFC perhaps ?
Note this extension is pretty much irrelevant for SSL which is a
real-time protocol, but it is relevant to S/MIME where things may be
verified at dates other than the current date. But this opens another
can of worms since RFC 3280 / 5280 don't define an algorithm that works
well for dates other than the current date. I think such an algorithm
would require the use of an extension like expiredCertsOnCRL.
Nelson B Bolyard
> At 1:42 PM -0800 1/12/09, Kyle Hamilton wrote:
>> It's basically saying, "I attest to the validity of this binding until
>> this date, *unless something extraordinary happens in the meantime*."
>
> No, that's *way* too strong. The meaning of the notAfter date is quite
> simple: "the date on which the certificate validity period ends". (See
> the subject of this thread....). A revoked certificate does not expire
> until after the notAfter.
I explain it to people this way: The notAfter date is the date after which
the CA has no further obligation to report that the cert was ever revoked.
(It actually is obliged to report revocation ONE more time after the
notAfter date, but that detail is not crucial to the understanding of
notAfter for most readers.)
Paul Hoffman
>I explain it to people this way: The notAfter date is the date after which
>the CA has no further obligation to report that the cert was ever revoked.
Yes, quite right.
>(It actually is obliged to report revocation ONE more time after the
>notAfter date, but that detail is not crucial to the understanding of
>notAfter for most readers.)
Not if you time your CRLs correctly. :-)
Nelson B Bolyard
> On 9/1/09 00:46, Ben Bucksch wrote:
>>> Certs expire for the same reason that credit cards do. Do you
>>> understand why that is?
>> No, quite frankly, I do not.
>>
>> First off, my credit cards (VISA, MasterCard) are valid until Jan 1, 2013.
>
>
> I had to think about it too ... I think it is because in the old days,
> the retailers had little pieces of paper with all the "revoked" credit
> card numbers. Shop assistants were paid a reward for spotting the bad
> credit cards. Back in the early days (I remember being trained on these
> papers, we kept them under the register) there were around 100-1000
> numbers on them.
In the mid-1960s, when I was a lad, my mother took me shopping with her.
When time came to pay for her purchases, she pulled out her shiny brand
new credit card and presented it to the cashier. The cashier looked
abjectly terrified. She called her supervisor over to help her through
the process.
They pulled a book out of a drawer below the cash register. It was about
the same size as the local phone book, and printed on the same sort of
very thin slightly gray paper as used in phone books, but it was much
thicker. She put it down and began to flip through the pages. I saw
that each page had numerous columns, all containing numbers. The top
outer corners of the pages showed the minimum and maximum number on
each page, to make it easier to find the right page to search, just as
a dictionary typically shows the alphabetically minimum and maximum
words on each page in the upper corners. She found the right page and
then scanned it in detail. When she was satisfied that the card number
was not present, she asked her supervisor to double check and confirm
it. Then they closed the book and on its cover I saw the words
"Revoked Card List" and the month and year for which is was current.
They published a new phone book like that for every participating merchant
every month. Each book had the numbers of ALL unexpired revoked cards
for the entire world (which was limited to parts of North America at
that time for that issuer).
The single most important thing that the cashier was required to check was
the expiration date on the card. Cashiers were required to mark on the
transaction slip that they had checked the expiration date. Being expired
meant that the number would NOT be present in the RCL book, even if the
card had been revoked before it expired. Expiration kept the size of that
RCL book manageable.
CRLs are the modern analog of those old RCLs, and OCSP is the analog of
those ubiquitous card-swipe devices that contact the issuer and get
approval. Despite this, many CAs still prefer to issue CRLs over using
OCSP, perhaps because the cost of publishing CRLs is so much less than
the cost of publishing those old phone-book sized documents. Also, as
Julien has pointed out, for servers doing high volumes of revocation
checking, having a full CRL locally is much more efficient than using
OCSP for every cert.
Kyle Hamilton
things which exist in time can act, and time is the process by which
cause and effect are separated.
Since nobody can hold Time to any form of standard, except that it is
agreed as a matter of policy to describe points in time in a
universally coordinated sense (made possible by the fact that Time
does not care who you are, it simply marches on at its own pace), and
since Time is essentially operating (perceptually) as a motion left in
place by intertia...
it cannot be viewed as an act taken "by time passing". Action at
birth, if it's the last action made, is still action; the idea is that
the action of binding the identity, provably committed to by the
action of signing the certificate, is an action -- the CA must choose
to make the action. Consequently, inaction on the part of the CA
during the term of the certificate's validity is also a choice. The
revocation of a certificate is another action, and the derevocation of
a certificate can be yet another action.
Thus, the CA is the only one who takes actions related to its
commitment to the binding. (Others may choose to disbelieve a given
binding, either via not accepting the CA's statements or by
specifically distrusting a specific statement; the latter can be done
via a private OCSP responder among other things.)
In any case, I don't buy your statement "action taken by time
passing". And "the time in the universe" is a policy, nothing more.
On a related subject, what precisely can be gleaned from RFC3280 (and
RFC5280)'s statements about what actions a CA under PKIX commits to
performing, over what period of time?
-Kyle H
On Mon, Jan 12, 2009 at 2:16 PM, Paul Hoffman <phof...@proper.com> wrote:
> At 1:42 PM -0800 1/12/09, Kyle Hamilton wrote:
>>Technically, 'expiration' is also an action taken by the CA.
>
> No, it is an action taken by time passing. When the time in the univers is the same as the time listed as "notAfter" in the cert, the cert expires. That's it.
>
>>It's
>>basically saying, "I attest to the validity of this binding until this
>>date, *unless something extraordinary happens in the meantime*."
>
> No, that's *way* too strong. The meaning of the notAfter date is quite simple: "the date on which the certificate validity period ends". (See the subject of this thread....). A revoked certificate does not expire until after the notAfter.
>
>>They really do have the same meaning -- that the CA is not willing to
>>attest to the identity binding.
>
> No, they really don't have the same meaning. Revocation can happen even if the CA is willing to attest to the binding but knows that doing so is silly, such as if the CA knows that the public key has been destroyed. Similarly, a CA might still attest to the binding between the public key and the identity in a different certificate.
>
>>After expiration, the CA doesn't give
>>one whit about the bound key -- and the entity which owned the
>>privatekey in question could hand that key over to someone else, and
>>the CA doesn't need to do anything at all because it has already
>>acted.
>
> Quite right.
>
>>Remember, *everything* in the certificate is an action of the CA. It
>>is the final actor in the creation of the certificate, and it is the
>>final actor in the revocation of the certificate.
>
> An action at birth is quite different than an action at revocation.
Paul Hoffman
>Thus, the CA is the only one who takes actions related to its
>commitment to the binding. (Others may choose to disbelieve a given
>binding, either via not accepting the CA's statements or by
>specifically distrusting a specific statement; the latter can be done
>via a private OCSP responder among other things.)
Fully agree.
>In any case, I don't buy your statement "action taken by time
>passing". And "the time in the universe" is a policy, nothing more.
Sure, whatever. If you want to view this only from the side of the CA, and not the side of the relying party, you can: many of us want to develop services that support both sides.
>On a related subject, what precisely can be gleaned from RFC3280 (and
>RFC5280)'s statements about what actions a CA under PKIX commits to
>performing, over what period of time?
"Precisely"? Not much.
My first cut is:
- Commits to following its own CPS
- Commits to providing revocation information in CRLs
Maybe that's all. Or maybe I am missing a lot.
This would be a great question for the PKIX WG. I bet three people will come up with three different lists, all of them right and incomplete. You could take a union. Heck, you could write a new document with a summary; it would be quite useful.
Rob Stradling
> On Friday 09 January 2009 04:32:41 Ben Bucksch wrote:
<snip>
> >
> > Can we create another extension? The signature itself is a shell around
> > the certified bits. Add the second signature around that first signature.
> >
> > There must be a way to add signatures. It's a base feature in PGP! If
> > it's entirely impossible to have two signatures, and no way to add it to
> > the spec, that's a design error. It's hard to believe that it's so
> > limited.
>
> If one wanted to have another signature, it wouldn't be as an extension,
> since, as Nelson pointed out, extensions are part of what gets signed.
> The current single signature is not an extension.
>
> Well, I guess somebody did it anyway :
> http://www.freepatentsonline.com/y2008/0270788.html
>
> sigh.
Ben, Julien,
That IBM patent application does not yet appear to have been reviewed and
either granted or rejected.
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.imc.org/ietf-pkix/mail-archive/msg01984.html
IANAL, but I think this should be sufficient prior art against the main claims
in the IBM patent application.
Ben, I agree that having multiple signatures in a certificate could be useful.
If, for example, the certificates in the wild today contained both MD5/RSA
and SHA-1/RSA signatures, Mozilla would be able to disable MD5 support
*today* without "breaking the internet", as long as the majority of relying
party software could process the additional signatures.
If the industry chose 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.
Ben Bucksch
> 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.imc.org/ietf-pkix/mail-archive/msg01984.html
>
>
> Ben, I agree that having multiple signatures in a certificate could be useful.
> If, for example, the certificates in the wild today contained both MD5/RSA
> and SHA-1/RSA signatures, Mozilla would be able to disable MD5 support
> *today* without "breaking the internet", as long as the majority of relying
> party software could process the additional signatures.
> If the industry chose 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,
I think that's an excellent suggestion. Not only because it allows more
advanced trust management, but also, as you point out, because it eases
the transition away from SHA-1 significantly, which I think will be very
important and may shorten the transition by years.
I think your proposal is nice, as it would allow to use the existing
extension mechanism, which means that it doesn't break current browsers.
Also, given that software will have to be changed anyways to support
SHA-2 or whatever, and we'll eventually use only that, I think there's -
in addition to the backwards-compatible way you propose - a chance to
introduce a new format which supports several signatures in a
straightforward way, and also other improvements which were hindered by
backwards-compatibility.
Greetings, and thanks a lot!
Ben
Rob Stradling
the idea. In 2006, the PKIX WG didn't seem interested in tackling the
problem I was trying to solve.
Paul, do you think it's worth re-raising this idea with the PKIX WG ?
> _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
--
Paul Hoffman
>Thanks Ben. Perhaps it's time to have another go at canvassing support for
>the idea. In 2006, the PKIX WG didn't seem interested in tackling the
>problem I was trying to solve.
>
>Paul, do you think it's worth re-raising this idea with the PKIX WG ?
Dunno. The WG seems willing to take on anything that will keep it alive longer. On the other hand, even if your spec is accepted by the WG, I highly doubt you will get enough implementation to make it worth your time. That is, unless almost every piece of PKIX validating software added the extension, it wouldn't really add much value.
--Paul Hoffman
Rob Stradling
I think it would be worth it if, at a minimum...
- the majority of CAs added the extension to the certificates they issue,
and...
- Mozilla implemented support for the extension in NSS.
This would allow Mozilla to disable a weak algorithm quickly, without having
to wait for the majority of certificates in the wild to stop using that
algorithm for their main certificate signature.
I think the biggest barrier to adoption would be convincing enough of the CAs
to implement it. But perhaps the Mozilla CA Certificate Policy could be
updated to require CAs to implement it?
Paul Hoffman
>Why "almost every piece of PKIX validating software" ?
>
>I think it would be worth it if, at a minimum...
> - the majority of CAs added the extension to the certificates they issue,
>and...
> - Mozilla implemented support for the extension in NSS.
>
>This would allow Mozilla to disable a weak algorithm quickly, without having
>to wait for the majority of certificates in the wild to stop using that
>algorithm for their main certificate signature.
Fair enough.
>I think the biggest barrier to adoption would be convincing enough of the CAs
>to implement it.
Really? :-)
>But perhaps the Mozilla CA Certificate Policy could be
>updated to require CAs to implement it?
That seems kind of drastic for an extension that would only help on a security issue that has never been met. That is, the extension will only be useful for hash functions for which practical pre-image attacks are discovered, or signature functions that quickly become drastically weaker than expected.
I still think it is sufficient for the policy to list the acceptable signing algorithms of the day. If the extension is standardized and is used by any CAs, and if NSS implements it and allows Firefox to be able to shut off one of multiple algorithms in the extension, that would help the CAs who used the extension.
Rob Stradling
> At 3:31 PM +0000 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 the extension to the certificates they
> > issue, and...
> > - Mozilla implemented support for the extension in NSS.
> >
> >This would allow Mozilla to disable a weak algorithm quickly, without
> > having to wait for the majority of certificates in the wild to stop using
> > that algorithm for their main certificate signature.
>
> Fair enough.
>
> >I think the biggest barrier to adoption would be convincing enough of the
> > CAs to implement it.
>
> Really? :-)
>
> >But perhaps the Mozilla CA Certificate Policy could be
> >updated to require CAs to implement it?
>
> That seems kind of drastic for an extension that would only help on a
> security issue that has never been met
True.
> That is, the extension will only be useful for hash functions for which
> practical pre-image attacks are discovered, or signature functions that
> quickly become drastically weaker than expected.
It's like an insurance policy. CAs and PKIX validating software would pay a
premium (i.e. development effort required to support the proposed certificate
extension), but would hope that they never need to "make a claim".
> I still think it is sufficient for the policy to list the acceptable signing
> algorithms of the day. If the extension is standardized and is used
> by any CAs, and if NSS implements it and allows Firefox to be able to shut
> off one of multiple algorithms in the extension, that would help the CAs
> who used the extension.
"if NSS implements it".
To the NSS developers:
If there existed a standardized certificate extension in which a CA could put
additional signatures using different algorithms, do you think you'd consider
adding support for it to NSS? If yes, might you do this before it was widely
supported by CAs, or do you think you'd wait for the majority of CAs to start
using it first?
Julien R Pierre - Sun Microsystems
Rob Stradling wrote:
> If there existed a standardized certificate extension in which a CA could put
> additional signatures using different algorithms, do you think you'd consider
> adding support for it to NSS? If yes, might you do this before it was widely
> supported by CAs, or do you think you'd wait for the majority of CAs to start
> using it first?
It's hard for us NSS developers to respond about such hypotheticals in
the future. Typically the NSS priorities are dictated by the needs of
the companies that employ most of the NSS developers, that is to say,
Sun, Red Hat and Google, and these can change over time. I am sorry I
can't be more specific.
Nelson B Bolyard
> To the NSS developers: If there existed a standardized certificate
> extension in which a CA could put additional signatures using different
> algorithms, do you think you'd consider adding support for it to NSS?
Yes, I think the NSS team would consider it, if it really was a standard,
at least an IETF RFC.
> If yes, might you do this before it was widely supported by CAs, or do
> you think you'd wait for the majority of CAs to start using it first?
I think that largely depends on who does the work.
If someone contributed a patch to NSS that implemented it, and was quite
complete (including changes to test tools and test scripts), and didn't
require much work at all to go in, I think it might go in basically as
soon as it was standard. The contribution of the Japanese Camellia cipher
was an example of a very well done contribution that went right in.
But if the NSS must develop it, or if a contributed patch is incomplete
or requires a lot of work that the contributor is unwilling or unable to
do, then prioritizing and scheduling that work involves factors such as
the priorities of the sponsors of NSS development.
Looking at the new developments in standards of the last few years, we
see a list of standardized features that are thought to be important by
various members of the crypto community, but which are not yet available
in NSS. To name just a few, there are TLS 1.2, AES GCM, OCSP stapling,
server support for SNI. Together they constitute a pretty large back log of
development waiting to be done. Another new proposal would contend
with those for resources.
Not all of the features that have been added to NSS in the last few years
have been widely adopted by the applications that use NSS. Consequently,
the sponsors are now evaluating possible future developments based on their
projections for the demand of application developers for those features.
I think that says that if they see a groundswell of demand from the
application developers for a new feature such as multiple signatures in a
certificate, they might go for it, but otherwise, it is likely to languish, IMO.
Rob Stradling
There's one big problem with this idea of a certificate extension for
additional signatures, which I hadn't thought of before (Thanks to Paul H for
spotting it!)...
For the additional signature(s) to become especially useful, the primary
signature on the certificate would need to be substantially broken (e.g. by a
pre-image attack on the hash algorithm). But if this happened, it is likely
that the CA would revoke the certificate. Once the certificate is revoked,
it's...errr...revoked. The additional signature(s) extension would simply be
ignored.
> IMO. _______________________________________________
> dev-tech-crypto mailing list
> dev-tec...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-crypto
--
Ben Bucksch
> For the additional signature(s) to become especially useful, the primary
> signature on the certificate would need to be substantially broken (e.g. by a
> pre-image attack on the hash algorithm). But if this happened, it is likely
> that the CA would revoke the certificate.
CAs have not even revoked these certs which used the bad Debian keys.
MD5 could be shut down more easily by just having apps disable it in the
software, (using an app uipdate, admitedly, but that's needed for
security purposes anyways), rather than revoking certs.