Question on KeyIdentifier chaining

[Yassir Elley <yassir.elley@xxxxxxx>]

I have a question about the chaining of SubjectKeyIdentifiers and AuthorityKeyIdentifiers.
Although RFC2459 and the son-of-RFC2459 both RECOMMEND application support
for the authority and subject key identifier extensions, neither document clearly specifies
under what circumstances, if any, should the application reject a certification path based on
invalid key identifier chaining.

The Basic Certificate Processing section very explicitly talks about unique identifier
chaining, but it does not mention key identifier chaining.
About unique identifier chaining, it states:

(5) [Verify that] The certificate issuer unique identifier is the
         working_issuer_UID, meaning:
            (i) working_issuer_UID is non-null and matches the value in
            the issuerUID field, or
            (ii) working_issuer_UID is null and the issuerUID field is
            not present.

I was wondering whether these same rules apply to key identifier chaining.
In other words, should we have a step like:
(6) [Verify that] The certificate authority key identifier is the
         working_AKI, meaning:
            (i) working_AKI is non-null and matches the value in
            the authorityKeyIdentifier field, or
            (ii) working_AKI is null and the authorityKeyIdentifier field is
            not present.

It is unclear to me whether the key identifiers are just meant to FACILITATE
chain building, or whether they are actually meant to be enforced in path validation.
In other words, if an application is presented the following certpath, should the application
reject the cert path because the key identifiers don't chain properly (i.e. Certificate 1
does not have a subject key identifier, but Certificate 2 does have an authority key
identifier)? Alternatively, should the application just treat the key identifiers as hints 
and accept the cert path if  everything else checks out (i.e. the signatures and everything
else, other than the key identifiers, chain properly)?

Certificate 1:
Issuer:     o=verisign,c=us
Subject:    o=sun,c=us
AKI: not present
SKI: not present

Certificate 2:
Issuer:    o=sun,c=us
Subject:  cn=yassir,o=sun,c=us
AKI: present, value=A
SKI: not present

Or what about this chain, where the key identifiers are both present but they don't match?
Should the application reject this chain even though the signatures and everything else,
other than the key identifiers, chain properly.

Certificate 3:
Issuer:     o=verisign,c=us
Subject:    o=sun,c=us
AKI: not present
SKI: present, value=A

Certificate 4:
Issuer:    o=sun,c=us
Subject:  cn=yassir,o=sun,c=us
AKI: present, value=B
SKI: not present

I do realize that Certificate 1 is not a PKIX-conformant since it is a CA certificate
which does not contain a SubjectKeyIdentifier extension, but there may be cases
where certpaths contain both conformant and non-conformant certificates.

Thanks in advance,
Yassir.