[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [IETF-PKIX] Key Identifiers
Andreas, Tim, John, Peter, Kevin and Paul,
Let me jump into this thread. I will use the E-mail from Andreas to
comment but will attempt to address the other E-mails as well.
Generally speaking, I do not support the idea of making the
AuthorityKeyidentifier or the keyidentifier mandatory. It might even be
better to deprecate its use. After this initial statement let us see the
details.
> Some comments on the key identifier / authority identifier issue that
> was recently discussed on this list:
>
> Let's assume I have a certificate of someone on my system that is about
> to be verified. Usually I would begin by retrieving all certificates of
> authority described by the issuer and the issuer alternative name (the
> exact process is outside the scope of this discussion). The result is a
> set of certificates.
This might be one way to proceed, but I see another way. Basically we
have not defined a way to walk *up* a path or *down* a path. We might
need to define one. You suggest to walk UP a path while I would suggest
to walk DOWN a path. You have some trust points and the question is
whether you can, from one of these trust points go DOWN to the
certificate you want to verify. In this way you may make sure that
naming is unambiguous from the trust point and you may apply naming
constraints. Otherwise, you can't do it easily.
The reality is that for discovering a path, you might have to walk up
and down, but the verification should only be done "walking down". This
means that no digital signature verification should be done before
getting one or more candidate paths down.
> Now I have to find out, which Authority Certificate was used to sign the
> User Certificate I am currently holding. I can do this by using all
> public keys in the Authority Certificates an trying to verify the User
> Certificate's signature. For any attempt that fails, I can rule out all
> Authority Certificates which contain the same public key that I have
> just tried. This process leaves me with a set of certificates which all
> contain the same public key and this key was used to sign the User
> Certificate. Key Identifiers can help me with this process so that I do
> not have to make a series of signature verifications, those a reduced to
> an octet string comparison. Question: is it worth the effort to save
> these verification steps? How many different public keys do we expect a
> CA to have? more that a handful (let's say 10)? Only if the number of
> keys held by the same CA is large the key identifier will help.
As said above, no verification of digital signature should be done
before getting a full path. This saves signature checks (as requested by
Paul Koning) without the need to overload the certificate by additional
mandatory extensions (that take memory place when the certificate is
stored in a smart card).
> Now for the Authority Identifier. Again, I am at the point where I have
> just retrieved the set of certificates. Given the issuer and serial of
> the signing authority for that CA, I can quickly identify the single
> certificate that should be used for verification. In fact, it is would
> be possible to retrieve just this single certificate and not retrieving
> the complete set.
>
> I have one problem with this approach: The verification path is not
> fixed. Let us assume a CA gets certified by a set of other CAs. Some
> users trust one of them, others some other CAs (which is why the CA
> probably got this multiple certificates). When a user certificate
> contains a reference to a single other CA, a user which does not trust a
> specific CA will fail to verify the certificate, although there might be
> a another path which would lead to a successful verification.
I support this comment. This means that placing the key identifier will
create failures in cases where successful verification could have be
done applying a different approach.
There are additional problems if we keep the keyidentifier that have not
been mentioned. The key of a CA is supposed to change, let us say every
two years. We have left undefined the strategy to adopt when the CA
changes its key. There are two possibilities: the validity period of the
CA keys overlap during let us say 6 months or there are contiguous. The
later case is not very nice if a user wants to register one week prior
the expiration of the CA key, since two certificates will have to be
provided to him during a two weeks period. For the first case, we will
have two certificates signing keys for the same CA during 6 months and
the question is to know which one to use. Some people are going to say:
use the key identifier. However there is another solution that does not
mandate the use of the key identifier. Comparing the date "not before"
of the user certificate with the date "not before" of the CA certificate
(or self-signed certificate when we end-up to a point of trust) allows
to make the difference.
Remember what 4.2.1.1 currently says about the Authority key identifier:
" This extension would be used where an issuer has multiple signing keys
(either due to multiple concurrent key pairs or due to changeover)."
> This situation can be solved, if we define that: an application may
> first try the specific certificate defined and then defaults back to the
> "try and search" algorithm.
>
> One question: Do we have an algorithm for a complete verification? There
> is one that describes how to verify an existing FC path, but do we have
> an algorithm on how to construct a path?
We currently don't and we probably should define one.
> Shouldn't the path be constructed and verified from bottom up?
I would rephrase the sentence as:
Shouldn't the candidate paths be constructed forwards and backwards and
then verified from the top to the bottom ?
Denis
--
Denis Pinkas Bull S.A. mailto:Denis.Pinkas@bull.net
Rue Jean Jaures B.P. 68 Phone : 33 - 1 30 80 34 87
78340 Les Clayes sous Bois. FRANCE Fax : 33 - 1 30 80 33 21