Re: delegating SSL certificates

[Dave Howe]

John Levine wrote:

| Presumably the value they add is that they keep browsers from popping
| up scary warning messages
Apple's Mail.app checks certs on SSL-based mail server connections.
It has the good - but also bad - feature that it *always* asks for
user approval if it gets a cert it doesn't like.


Good point -- other mail programs such as Thunderbird also pop up
the scary warnings.  I've paid the $15 protection money for the certs
on my mail servers.


I have found that just adding the cert to the local keystore had pretty 
much the same effect. There is a nice addon for Thunderbird/Firefox 
(which will apparently be a native ability in v3 of the latter) called 
"remember mismatched domains" that lets you suppress an error for a 
specific cert/domain mismatch.


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: delegating SSL certificates

[Bill Frantz]

[EMAIL PROTECTED] (Peter Gutmann) on Sunday, March 16, 2008 wrote:

>[EMAIL PROTECTED] writes:
>
>>I would think this would be rather common, and I may have heard about certs
>>that had authority to sign other certs in some circumstances...
>
>The desire to do it isn't uncommon, but it runs into problems with PKI
>religious dogma that only a CA can ever issue a certificate.

Is that a religious dogma, or a business model masquerading as a
religious dogma?

Whichever it is, it is an impediment to improving protection
against fishing attacks. Consider a large organization like Amazon
and users using tools like the Petname toolbar
. Amazon has many servers,
each of which needs a TLS signing key. In a more ideal world,
Amazon would have a CA signed public certification key, which it
would use to certify each server's TLS signing key. The Petname
toolbar would use Amazon's public certification key as the identity
matching the user's petname for Amazon. Once that petname has been
established, AKA the introduction problem, the identity would be
safe, regardless of what happens higher in the PKI hierarchy. The
higher levels of the PKI hierarchy would only be used during the
introductory contact.

Given the current situation, with the CAs having a monopoly on
issuing certificates, there are many different public keys
associated with Amazon. In addition, Amazon may chose to change the
CA it uses. To handle this situation, the Petname toolbar the DN
instead of a public key, which opens the Petname tool bar to
spoofing by any of the 100 or so CAs configured in the standard
browsers. Does anyone know what happened to Baltimore's signing key
when they went out of business?

Cheers - Bill

-
Bill Frantz| The first thing you need when  | Periwinkle
(408)356-8506  | using a perimeter defense is a | 16345 Englewood Ave
www.pwpconsult.com | perimeter. | Los Gatos, CA 95032

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: delegating SSL certificates

[Jon Callas]

On Mar 16, 2008, at 8:50 AM, John Levine wrote:


So at the company I work for, most of the internal systems have
expired SSL certs, or self-signed certs.  Obviously this is bad.


You only think this is bad because you believe CAs add some value.


Presumably the value they add is that they keep browsers from popping
up scary warning messages.  There are all sorts of reasonable
arguments to be made that the browsers are doing the wrong thing (and
the way that Microsoft prevents you from ever deleting any of their
preinstalled CA certs is among the wrongest.)


Yes, but.

If a browser handled unknown certificates similarly to the way SSH  
does -- to alert the user when it sees an unknown, unrooted  
certificate, and then only again when there is a mis-match, you would  
have an incentive to get a CA certificate (because businesses don't  
want their customers to see that scary message even once), while  
supporting ad-hoc infrastructures.


This would require only software changes, not changes in the trust  
models, CAs, procedures, etc.


A wicked person would suggest that this is because the present system  
was designed to support the business model, not the security model.  
I'm not a wicked person and would never suggest that.


Jon

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: delegating SSL certificates

[John Levine]

>| Presumably the value they add is that they keep browsers from popping
>| up scary warning messages
>Apple's Mail.app checks certs on SSL-based mail server connections.
>It has the good - but also bad - feature that it *always* asks for
>user approval if it gets a cert it doesn't like.

Good point -- other mail programs such as Thunderbird also pop up
the scary warnings.  I've paid the $15 protection money for the certs
on my mail servers.

R's,
John

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: delegating SSL certificates

[Bill Squier]

On Mar 17, 2008, at 10:06 AM, Leichter, Jerry wrote:


| >> So at the company I work for, most of the internal systems have
| >> expired SSL certs, or self-signed certs.  Obviously this is bad.
| >
| >You only think this is bad because you believe CAs add some value.
|
| Presumably the value they add is that they keep browsers from  
popping

| up scary warning messages
Apple's Mail.app checks certs on SSL-based mail server connections.
It has the good - but also bad - feature that it *always* asks for
user approval if it gets a cert it doesn't like.


Fixed in Leopard.  Certificate handling in general appears to be  
better -- although I can't be sure Tiger didn't let you fiddle with  
fine-grained entitlements as to when to trust a cert.


-wps

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: delegating SSL certificates

[Leichter, Jerry]

| >> So at the company I work for, most of the internal systems have
| >> expired SSL certs, or self-signed certs.  Obviously this is bad.
| >
| >You only think this is bad because you believe CAs add some value.
| 
| Presumably the value they add is that they keep browsers from popping
| up scary warning messages
Apple's Mail.app checks certs on SSL-based mail server connections.
It has the good - but also bad - feature that it *always* asks for
user approval if it gets a cert it doesn't like.

One ISP I've used for years (BestWeb) uses an *expired* self-signing
cert.  The "self-signed" part I could get around - it's possible to
add new CA's to Mail.app's list.  But there's no way to get it to
accept an expired cert automatically.  So ... every time Mail.app
starts up, it complains about the cert and asks me to approve it.
This stalls Mail's startup, and it fails to pick up mail - from any
server - until I tell it, OK, yes, go ahead.  The cert has now been
expired for over 2 years.  (You might well wonder why, if you're going
to use a self-signed cert, you *ever* let it expire - much less cut one,
like theirs, with a 1-year lifetime.  Since all you're getting with a
self-signed cert is "continuity of identity", expiration has no
positives, just negatives.  Perhaps they were planning to go out of
business in a year? :-) )

I've been in touch with BestWeb's support guys repeatedly.  Either
they just don't understand what I'm talking about, or I'll finally
get someone to understand, he'll ask me for details on which cert
is expired, I'll send them - and then nothing will happen.

Clueless.  Just to add to the amusement, *some* of their services - Web
mail, and through it tuning of their spam filters - are accessible
*only* through HTTP, not HTTPS.  These use the same credentials

Perhaps I should just go with the flow and use unencrypted connections.
(Or get over my inertia, stop trying to get them to fix things, and
drop my connections to them at the next renewal)

-- Jerry

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: [mm] delegating SSL certificates

[Dirk-Willem van Gulik]

On Mar 16, 2008, at 7:52 PM, Ben Laurie wrote:


Dirk-Willem van Gulik wrote:
So I'd argue that while x509, its CA's and its CRL's are a serious  
pain to deal** with, and seem add little value if you assume avery  
diligent and experienced operational team -- they do provide a  
useful 'procedural' framework and workflow-guide which is in itself  
very valuable, relatively robust and are a little bit  
organisationally "inherently fail-safe". The latter as you are  
forced to think about expiry of the assertions, what to do when a  
CRL is too old and so on.


I think there's a large gulf between the use case where the relying  
party and the CA are the same entity, and where they do not even  
have a contractual arrangement.


I think you are hitting a key point here. In a way - a CA (or some sub- 
CA) is less of an authority and more of a, ideally, somewhat  
consistent organizational realm.


CAs within a corporate environment may well be a good idea in some  
cases, indeed. As you know, we've been pushing on this idea at the  
Apache Software Foundation for some time now, hindered only by our  
laziness :-)


And at the same time we need to learn to, or be weaned away from, the  
hardened shell perimeter ideas, that of a single super reliable root -  
and start to see a CA as something like one of the Kerberos KDC's we  
trust, just a NIS+ server we like, etc.


Dw

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: [mm] delegating SSL certificates

[Ben Laurie]

Dirk-Willem van Gulik wrote:
So I'd argue that while x509, its CA's and its CRL's are a serious pain 
to deal** with, and seem add little value if you assume avery diligent 
and experienced operational team -- they do provide a useful 
'procedural' framework and workflow-guide which is in itself very 
valuable, relatively robust and are a little bit organisationally 
"inherently fail-safe". The latter as you are forced to think about 
expiry of the assertions, what to do when a CRL is too old and so on.


I think there's a large gulf between the use case where the relying 
party and the CA are the same entity, and where they do not even have a 
contractual arrangement.


CAs within a corporate environment may well be a good idea in some 
cases, indeed. As you know, we've been pushing on this idea at the 
Apache Software Foundation for some time now, hindered only by our 
laziness :-)


--
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: delegating SSL certificates

[Dirk-Willem van Gulik]

On Mar 16, 2008, at 12:32 PM, Ben Laurie wrote:


[EMAIL PROTECTED] wrote:

So at the company I work for, most of the internal systems have
expired SSL certs, or self-signed certs.  Obviously this is bad.


You only think this is bad because you believe CAs add some value.

SSH keys aren't signed and don't expire. Is that bad?


Agred - that (signing) in itself not important  - however in a (large)  
corporate environment overall plain keys does force one to re-invent  
the same kind of CA and/or CRL wheel with respect to the expiring and  
the lack of a managed authority.


I recently came across two installations where ssh public keys where  
used to great avail (combined with a command="" construct which would  
launch various curses/IBM tn3270 user interfaces), in one case  
combined with a commercial product where a x509 on a chipcard would  
login and 'unlock' a users windows home directory/registry. This  
system had been going on for many, many years and had seen several OS  
migrations.


With the advent of faster moving windows/laptops - a lot keys had been  
'lost'. Some due to real loosing of a laptop; most due to automated  
upgrades wiping the users transients home-directory/registry.


After a bit of scripting it seemed that for every key which had been  
used in the last few weeks; a little over 8 keys where 'dormant'. A  
manual quick sample confirmed that most of those where associated with  
lost/retired equipment (hire/fire was a well controlled HR process).  
Looking at an  authorized keys file revealed little - as few, if any,  
comments where filled out.


Couple of things suprized me, and/or where a serious of an eye opener  
to me:


A   Even very experienced sysadmins can make the conceptual
error that an old 'public key' is not 'dangerous' _because_
it is public. Therefore you do not need to keep careful
track of them or be 'super diligent' when managing your
key files.

B   The very nature of the ssh public key (esp. when generated
in an environment where the comment field is not easily
attributed to a specific user; e.g. on windows some tools
just put the text 'Generated by SShKey.exe' in that field)
is very hard to manage - and really assumes a 1:1 mapping
of a unix account to a real person.

C   The lack of expiry _combined_ with the lack of easily
'documenting' an ssh key (i.e. the full key or even the
fingerprint or bubblebabble of the ssh pub key is a bit
painful when you need to cross a cut-and-paste barrier)
easily creates and environment where the keys start to
lag behind or where the pain combined with false security
due to the 'A' misconception starts to conspire
against you.

And as an aside - as one of the organisations already had a PKI rolled  
out into every nook and cranny - so using the Roumen Petrof patches  
which add x509 to openssh* - has helped solve some of the worse  
excesses virtually overnight.


So I'd argue that while x509, its CA's and its CRL's are a serious  
pain to deal** with, and seem add little value if you assume avery  
diligent and experienced operational team -- they do provide a useful  
'procedural' framework and workflow-guide which is in itself very  
valuable, relatively robust and are a little bit organisationally  
"inherently fail-safe". The latter as you are forced to think about  
expiry of the assertions, what to do when a CRL is too old and so on.


Or perhaps we're comparing apples and oranges; ssh is just a pure pub/ 
priv key pair -- whereas x509 is a management framework in which you  
happen to also have embedded and manage a pub/priv key pair along with  
a whole lot of other things.


However - as firewalls and hardening of the far-outer perimeter is  
increasingly becoming ineffective, as you increasingly look at fine  
grained controls close to the user and (end) applications -- we do  
need to come to grips (much) better with the distributed management  
tools which let us map those controls to the desired social/ 
organisational model they are functioning within.


Thanks,

Dw.

*: http://www.roumenpetrov.info/openssh/ (and I'd love those in  
openssh itself, and in solaris please :)
**: not in the least as they force you to tackle nasty organisational  
questions such as who is really responsible for what; rather than let  
it fester it into some ops-team 'we always did it like that' fudge.


-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: delegating SSL certificates

[John Levine]

>> So at the company I work for, most of the internal systems have
>> expired SSL certs, or self-signed certs.  Obviously this is bad.
>
>You only think this is bad because you believe CAs add some value.

Presumably the value they add is that they keep browsers from popping
up scary warning messages.  There are all sorts of reasonable
arguments to be made that the browsers are doing the wrong thing (and
the way that Microsoft prevents you from ever deleting any of their
preinstalled CA certs is among the wrongest.)

Nonetheless, unless we can persuade all the users in question to
adjust their browsers, which is always a losing battle, it's easier
just to pay the $15 protection money and get a CA signature.

Regards,
John Levine, [EMAIL PROTECTED], Primary Perpetrator of "The Internet for 
Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: delegating SSL certificates

[Ben Laurie]

[EMAIL PROTECTED] wrote:

So at the company I work for, most of the internal systems have
expired SSL certs, or self-signed certs.  Obviously this is bad.


You only think this is bad because you believe CAs add some value.

SSH keys aren't signed and don't expire. Is that bad?

--
http://www.apache-ssl.org/ben.html   http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: delegating SSL certificates

[Peter Gutmann]

[EMAIL PROTECTED] writes:

>I would think this would be rather common, and I may have heard about certs
>that had authority to sign other certs in some circumstances...

The desire to do it isn't uncommon, but it runs into problems with PKI
religious dogma that only a CA can ever issue a certificate.  For example I
proposed this on the PKIX working group nearly a decade ago, specifically the
ability for end entities with signing certs to issue their own encryption
certs, since there's absolutely no need to involve a CA in this.  I've still
got the draft online at
http://www.cs.auckland.ac.nz/~pgut001/pubs/autonomous.txt.  The WG chair's
response was "we don't want to turn X.509 into PGP", and that was the end of
it.  The grid computing folks eventually got something through in the form of
proxy certificates for the Globus GSI, but that probably isn't what you're
looking for.

Peter.

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: delegating SSL certificates

[Dave Howe]

[EMAIL PROTECTED] wrote:

So at the company I work for, most of the internal systems have
expired SSL certs, or self-signed certs.  Obviously this is bad.


Sorta. TLS gets along with self signed just fine though, and obviously 
you can choose to accept a root or unsigned cert on a per-client basis.



I know that if we had IT put our root cert in the browsers, that we
could then generate our own SSL certs.


sure. for IE its just a registry key, trivial to push out using login 
scripts etc.



Are there any options that don't involve adding a new root CA?


buying a intermediate cert from an existing CA? buying a "wildcard" cert 
 for your domain, and using the same wildcard cert on all nodes?



I would think this would be rather common, and I may have heard about
certs that had authority to sign other certs in some circumstances...


at one point, you could use *any* cert to sign another cert; IE didn't 
bother checking. I believe they have fixed that now.



-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Re: delegating SSL certificates

[John Levine]

>Are there any options that don't involve adding a new root CA?

Assuming your sites all use subdomains of your company domain,
a wildcard cert for *.whatever might do the trick.  It's relatively
expensive, but you can use the same cert in all your servers.

>I would think this would be rather common, and I may have heard about
>certs that had authority to sign other certs in some circumstances...

They do exist, Comodo has sold certs signed that way, but I wouldn't
recommend it since the depth of chaining the browsers recognize varies
considerably.  My copy of Firefox doesn't accept many of Microsoft's
certs because the chaining is too deep.

Another possibility is just to pay to have your certs signed by one of
the public signers.  At the current going rate of $15, you can get a
lot of signatures for the cost of doing anything else.

R's,
John

-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

delegating SSL certificates

[travis+ml-cryptography]

So at the company I work for, most of the internal systems have
expired SSL certs, or self-signed certs.  Obviously this is bad.

I know that if we had IT put our root cert in the browsers, that we
could then generate our own SSL certs.

Are there any options that don't involve adding a new root CA?

I would think this would be rather common, and I may have heard about
certs that had authority to sign other certs in some circumstances...
-- 
https://www.subspacefield.org/~travis/> Who Would Jesus Bomb?
For a good time on my email blacklist, email [EMAIL PROTECTED]


pgp62b6zjh4z9.pgp
Description: PGP signature