On Tue, Mar 18, 2008 at 5:01 PM, Michael Sierchio <[EMAIL PROTECTED]> wrote:
> Kyle Hamilton wrote:
>
> > Certificate issuance is a statement of identity binding for a given
> > key at a given assurance. No more, no less.
>
> No, it isn't. It's often more.
Such as...?
> > A CA does not and cannot specify the value of the data which can be
> > encrypted or protected by any given key.
>
> Irrelevant to the discussion.
No, it's not. Since the CA doesn't know it, the CA can't apply its
policy appropriately. Thus, the only party which CAN apply a policy
appropriately is the person with the private key.
I'd suggest you stop trying to frame the discussion into one that you
can 'win', and instead try to understand that people would not
complain about this if they didn't perceive or run into a failing that
having this addtional information would help them deal with.
> > ... It specifies things that
>
> > third parties can know and rely on. Only the principal itself can
> > know what it's actually going to use the key for.
"I'm going to use this key to encrypt my financial paperwork."
"I'm going to use this key to encrypt my invention notes."
"I'm going to use this key to authenticate to an online community."
"I'm going to use this key to authenticate to my bank."
"I'm going to use this key to sign bank paperwork."
"I'm going to use this key to sign approved access requests for
contractors to a secure colocation facility."
Various people will want to use keys for specific periods of time, and
will have reasons to use different periods of time with each context
they're used in.
> No, key usage restrictions are certainly within the realm of what
> a CA will bake into a cert. And relying parties may choose not
> to accept a cert for a given purpose if that purpose is not
> included in key usage extensions, for example.
They are baked into a certificate. They're not baked into the key.
In addition, relying parties may choose not to accept a cert for a
given purpose even if that purpose is included in key usage
extensions.
In addition, relying parties may choose to accept a cert for a given
purpose even if that purpose is not included in key usage extensions.
In all cases, they're consciously choosing not to follow the CA's
policy (or are completely unaware of the CA's policy). This means
that they are not "relying parties" according to that policy (i.e.,
they're not following the rules describing what 'relying parties' must
do to avail themselves of the warranties that the CA makes). However,
since most CAs don't offer any warranties to relying parties anyway,
the risk to the RP is the same.
> For example, you certainly can use a key to produce a digital
> signature, even if the certificate that binds the public key
> to that entity says otherwise. But no one should accept the
> signature as valid. In fact, the signing may be grounds for
> revoking the certificate.
...within the context of the CA and the CA's relying parties, that
might be an appropriate threat.
But, that's only if anyone gives a hoot about the CA's policy at that point.
> > Remember, the CA (and X.509 certificate chains) are only a relatively
> > efficient means of transferring trust via policy. It is NOT the only
> > way to transfer trust.
>
> Irrelevant to the discussion -- I was arguing against adding time of
> generation data to the private key format. I don't know of any serious
> cryptographer or security expert who advocates this, and I certainly
> don't.
I don't understand why this is irrelevant.
We're running into an instance of the Gödel Incompleteness Theorems --
you seem to be unable to comprehend any usage of public/private keys
outside the X.509 framework. I'm trying to tell you that these
situations exist (primarily because I'm working with several of them),
and these situations could very easily use this additional metadata.
In addition, these keys are keys. They are keys whether they are in a
properly-specified X.509 structure or not. They can be taken out of
X.509-using contexts, and put into X.509-using contexts, without
regard for how long a key has in actuality been in use.
(I could, for example, take my 2048-bit RSA public key that I've been
using with WASTE for the past 4 years, wrap it in a CSR, submit it to
a CA, and they wouldn't have any record of my using it before -- even
though it's been in use long enough that, had it been in X.509 all
along, wouldn't allow for any kind of renewal.)
> > Please remember that there are uses for keys outside the PKI. This is
> > why private key storage formats should have a timestamp-of-generation
>
> Irrelevant, and fallacious. PKI is not a "use" for keys, it provides
> mechanisms of finding appropriate identity/key associations and
> validating these.
I'm sorry. I should have been more specific.
Please remember that there are places where keys are used and managed
outside of any PKI. The PKI defines how the /public/ keys are
managed, but it does not define how the /private/ keys are managed.
> There are good arguments for NOT adding ad hoc changes to a standard --
> especially when they are based on a paucity of understanding.
I agree, there are good arguments for not adding ad hoc changes to a
standard. Unfortunately, the standard is deeply flawed, in ways that
cannot be seen by the kind of inflexible and rigid adherence to "the
sacred text of the standard" that you so righteously hold to.
This is why X.509 -- and those who have propounded it for so long --
hasn't made it into everyday usage.
What is the use-case for X.509 in the world, hmm? "Feel secure about
transmitting your credit card information across the internet, by
knowing who you're giving it to!" Uh, we don't have to do that now,
we can just look at our bank statements and credit card statements and
look for unauthorized charges and have them removed. (VISA and
MasterCard have a $0 liability policy, even though US law says they
can enforce a $50 liability policy.)
By definition, the "web of trust" (the OpenPGP concept) is also a PKI.
It's one that doesn't have all the restrictions that X.509 has. It
wouldn't have existed but for the failings of X.509... and even
X.509's cross-certificates are a means of applying a "web of trust"
retrofitting in an ad hoc manner. (Which there are good reasons for
not doing.)
-Kyle H
:��I"Ϯ��r�m����
(����Z+�K �+����1���x ��h����[�z�(����Z+� ��f�y������ �f���h��)z{,���
