RE: AKI and SKI problem with RFC 3280?

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

I'm particularly interested in the reality check.

If an application use AKI/SKI match to discover a path and finds an
AKI/SKI match of unrelated keys. What happens?

Ignoring what applications SHOULD do (which we all know)
What is in fact the current behaviour of applications today:

Do they:
1) Not even try to validate the path since issuer/subject don't match
2) Fail validation and display error
3) Fail validation, then goes back and search for another path


The danger with the outline of RFC 3280 is that two different methods
with different characteristics is proposed, while almost everybodey use
the first (key hash based). Implementers may thus be tempted to make
development shortcuts, based on a fair assumption that AKI/SKI match
indicates use of the same key, not causing any security risks, but
leading to unneccesary errors in casae that assumption is false.

In case there would be a followup to RFC 3280 my feeling is that
increasing integers should be deprecated. 

In the ETSI cert profile under development we are currently proposing to
deprecate this option.

/Stefan



 
> -----Original Message-----
> From: Peter Hesse [mailto:pmhesse@xxxxxxxxxxxxxxxxxx]
> Sent: den 21 oktober 2003 15:45
> To: 'Peter Gutmann'; ietf-pkix@xxxxxxx; Stefan Santesson
> Cc: housley@xxxxxxxxxxxx
> Subject: RE: AKI and SKI problem with RFC 3280?
> 
> "Peter Gutmann" <pgut001@xxxxxxxxxxxxxxxxx> writes:
> 
> > My code has included a check to ignore the sKID if it's less than
> > 40 bits for some time now, because anything less than that is a
> > danger sign implying the use of an integer sequence.
> 
> The RFC 3280 certification path validation process does not include a
> check of the sKID and/or aKID; if they don't match, there is nothing
> wrong with the path.  Path building implementations should never rely
on
> them being correct.  They may be useful if they are present and
correct,
> but as was said, may lead building algorithms astray if they are
present
> and incorrect.  Therefore implementations should use them if they are
> helpful, but not rely on their existence or fail if they are
incorrect.
> 
> --Peter
> 
> +---------------------------------------------------------------+
> | Peter Hesse                    pmhesse@xxxxxxxxxxxxxxxxxx     |
> | Phone: (703)934-2031         Gemini Security Solutions, Inc.  |
> | ICQ: 1942828                     www.geminisecurity.com       |
> +---------------------------------------------------------------+
> "Pay no attention to what the critics say; there has never been
> a statue set up in honor of a critic." --Jean Sibelius
>