RE: AKI and SKI problem with RFC 3280?

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

I'll reply briefly to several messages at once here to keep the message count
down...

"Stefan Santesson" <stefans@xxxxxxxxxxxxx> writes:

>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:

I match first on DNs and only if that fails do I fall back to keyIDs (provided
the keyID is > 40 bits, i.e. not a non-unique small integer).  I'm not aware
of the match on DNs ever having failed.  It's one of these things that users
just know about (sort of like "Don't user Master Documents in MS Word" or
"Don't change the monitor frequency settings in XF86Config"), you can either
play it safe and know it'll work or live dangerously but have to expect things
to break.  If you expect things to break anyway then presumably you're
prepared to do the necessary manual tweaking to sort things out.  An easier
option for most people is just to make sure that you never put yourself in a
situation where things can break.

=?ISO-8859-1?Q?Michael_Str=F6der?= <michael@xxxxxxxxxxxx> writes:

>Or is it just YAPEB [1]?
>
>[1] yet another PKIX extension bloat

In my earlier message I originally had a tongue-in-cheek comment that the
purpose of the keyIDs was for the CA to communicate to a RP that it didn't
consider the certificate bloated enough, but I removed it before I sent the
message.

"Al Arsenault" <aarsenau@xxxxxxx> writes:

>So, your assertion is that a bastardized hybrid of a widely-used but non-
>standard protocol (SCEP)

I was waiting for someone to bring that up :-).  I'd considered just putting
in a blank space in place of the term "SCEP" in my post in reference to the
PKIX NIH effect blanking it out.

>with an updated wrapping mechanism (CMS) will cause problems for some types
>of signature validation software, and this is a reason why one option
>permitted by PKIX is a fundamental flaw?

You asked for an example, that's a quick example (the reason SCEP uses PKCS #7
is because that's what Cisco had lying around when they created it.  I'm sure
any even vaguely recent SCEP implementation will be built with a CMS toolkit).
In any case it was just a top-of-my-head example (I'm not going to search
through every case of CMS use to see how many would be affected by this, it's
used in all sorts of weird and wonderful places), the point is that if the
spec allows this behaviour then it's broken.

Jean-Marc Desperrier <jmdesp@xxxxxxx> writes:

>Do cross-certifying CA discards all extensions inside the request so that
>it's not possible to specify the SKID by including it as an extension inside
>the request ?

My code copies all extensions across (although the CA app is free to delete
any that it doesn't like).  Feedback from users was that if they didn't want
it in the request they wouldn't be specifying it, and conversely if they did
specify it then they didn't want the CA arbitrarily stripping it out.

All manner of people wrote:

>[ Six angels! / Four angels! / Eight angels! / No angels! / A dachshund! ]

The general response to this issue has been some variation of "Users will get
it right" (= push it onto the users) / "It's a policy issue" (= push it onto
the users) / "It's a local configuration issue" (= push it onto the users).
If the PKI experts can't even agree on how to interpret/handle this, how on
earth can non-technical users be expected to get it right?

I'll conclude with a wonderful quote from someone else (who probably doesn't
want his name mentioned :-).  It's in reference to the UK comedy "Father Ted":

  Ted says that whenever he gets asked a religious question he doesn't
  understand he always responds with "Ah, that must be an ecumenical matter"
  which univerally produces nods of admiration at the profound wisdom of the
  statement. It seems that that the PKIX list equivalent is "Ah that must be a
  policy matter".

Peter.