[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AKI and SKI problem with RFC 3280?



A decent MUA would understand that there may be more
than one cert with the same SKI. AKI/SKI is just a
hint. As such, it's nice (maybe leading to better
performance) if there's one and only one cert with
a particular SKI. But it's not required.

In fact, if you use one of the key hash methods for
calculating the AKI/SKI and there are several certificates
with the same subject public key (as with multiple
cross-certificates for a single CA), these certificates
will probably all have the same SKI.

Note also that AKI/SKI chaining SHOULD NOT be checked
during path validation. To be more explicit, it's
NOT true that the SKI of a CA certificate must match
the AKI of a certificate signed by that CA. Why?
Because the CA certificate may have been issued by
a CA that uses a different AKI/SKI computation technique
than the CA who's the subject of the CA certificate.

Thanks,

Steve

Peter Gutmann wrote:
> 
> "Al Arsenault" <aarsenau@xxxxxxx> writes:
> 
> >Why does an AKI/SKI have to be globally unique?
> >
> >It strikes me that the AKI/SKI extensions are simply "search aids".  That is,
> >they merely help the application (RP) determine which of a set of possible
> >certificates to use is the correct one. While it would be kind of cool if an
> >SKI/AKI would be globally unique (it would make searching a repository a
> >little easier/quicker IN SOME CASES), it doesn't strike me as a huge deal.
> 
>   You send me a CMS signed message (say) with the key identified by sKID = 0.
>   My MUA finds a cert with sKID = 0 and tries to verify the signature.  The
>   verification fails, and I get a warning saying that the forces of darkness
>   are tampering with my communications, I could be under attack, and the world
>   is about to end.
> 
>   You send me a CMS signed message (say) with the key identified by sKID =
>   aildhfsdfsjklhgdfjghkf.  My MUA can't find a cert with that sKID and
>   displays an informational message saying that it couldn't find a signing
>   key, and perhaps I should contact the sender for more information.
> 
> There's a big difference in terms of usability.
> 
> Peter.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature