On Monday, 07/14/2014 at 11:03 EDT, Rick Troth
<[email protected]> wrote:
> On 07/14/2014 08:54 AM, Alan Altmark wrote:
> > As far as I know, the only place you'll find a URI is in the CRL
portion
> > of the certificate. When a client or server sends a certificate, the
only
> > assumption it can make is that the base CA certificate is known to and
> > trusted by the peer. All intermediate CAs, plus the base CA, must be
sent
> > to the peer during the TLS handshake.
>
> Look for the "Authority Information Access" object.
>
> There are URIs in other sections too. "They're everywhere."
I believe that the only place a URI is mandatory is in the CRL
Distribution extension. My VeriSign cert doesn't have it anywhere else.
> There must be a doc somewhere that affirms the mandate you cite about
> the intermediates. Not clear how well that is implemented in practice. I
> regularly see certificates which lack their chaining intermediates.
> Dunno if those are separated out of band. Possible.
>From RFC 2256 (TLSv1) re: the certificate_list:
This is a sequence (chain) of X.509v3 certificates. The sender's
certificate must come first in the list. Each following
certificate must directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate which specifies the
root certificate authority may optionally be omitted from the
chain, under the assumption that the remote end must already
possess it in order to validate it in any case.
> > If you just use the public CAs, then the bundles are fine, but that's
the
> > point of asking the question. Each way has its advantages, but I want
to
> > know how people deal with managing well-known public CAs, self-signed
> > certs (boo! hiss!), and private CAs in an openssl environment.
>
> _Self-signed does not equate to bad._
> It simply requires manual assertion or IT department pre-loading.
> You're frowning on the bad practice of letting end /users perform manual
> assertion/ of a self-signed cert. That /is/ bad.
> It's all about trust.
Outside of a closed environment, self-signed certs are bad. If
something-A needs a cert, then something-B will be asked to trust it.
"Trust me, you need to trust the untrustworthy." Self-signed (non-CA)
certs are effortless to obtain and therefore have no value for
authentication.
> A growing number of experts are making noise about the sad state of PKI
> on this planet.
The people who make the most noise about old mousetraps typically have a
vested interest in a new model. There's nothing wrong with the PKI model,
IMO, but there is an incredible lack of understanding about how to manage
its deployment so that it improves your overall security posture.
> Managing certs and carrying issue/sign chains makes the PKI trust model
> more like the PGP trust model. One criticism of the PGP trust model (for
> consumer use) is the need for such work.
> Ironic.
This is that lack of understanding about PKI. If the rule is "If Mom says
it's ok, then its ok," you ignore what Dad says unless it's "Go ask your
Mom." But, no, we start using certs before we have PKI baked into the
infrastructure, so the only "rule" that works is to obey Mom. And Dad.
And your siblings. Oh, and the family pet ferret. Ferrets are
trustworthy, right? (More so than siblings, perhaps.)
Outside of the mainframe, I haven't seen a centralized cert management and
TLS implementation. On Linux, for example, every application can have a
different implementation with its own cert store. Only by convention and
configuration do we manage to centralize things. No enforcement. There
are too many places where the "trusted root" begins. I should be able to
deploy a new ca root bundle once on each host and KNOW that all subsystems
that use ca root certs will be using the ones I just deployed. Application
stacks don't get to control policy - they follow it. This is why z/VM and
z/OS have System SSL. Vermin-ridden applications don't have access to
certs and keys, just as God intended.
Alan Altmark
Senior Managing z/VM and Linux Consultant
IBM System Lab Services and Training
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
[email protected]
IBM Endicott
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
