Subject: AKI and SKI problem with RFC 3280?

From: "Stefan Santesson" <[email-masked]>
Date: Mon, 20 Oct 2003 11:12:24 +0100

I have come a cross a potential problem with RFC 3280 when working on
the new ETSI Certificate profile standard for identity certs.

RFC 3280 states:

4.2.1.1

   The value of the keyIdentifier field SHOULD be derived from the

   public key used to verify the certificate's signature or a method

   that generates unique values.  Two common methods for generating key

   identifiers from the public key, and one common method for generating

   unique values, are described in section 4.2.1.2

4.2.1.2

   One common method for generating unique values is a monotonically

   increasing sequence of integers.

This means that a CA, following the recommendation can assign key
identifier values of e.g. 1, 2, 3, 4, 5, 6,..., n

If many different CA:s would follow the "monotonically increasing
sequence of integers" procedure, multiple unrelated certificates would
end up having the same SKI and/or AKI values relating to completely
different public keys.

I'm not sure how most path building clients would handle a situation
like that, but I fear that at least some would fail.

Isn't the point that AKI:s and SKI:s should use a generation algorithm
that assigns them a globally unique value with high probability and
therefore SHOULD be derived from the public key and NOT use a
"monotonically increasing sequence of integers". At least not starting
from a small integer?

/Stefan

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 22 Oct 2003 02:26:16 +1300

Russ Housley <[email-masked]> writes:

>The only CA that I know about that did this has changed to a hash-based
>alternative.

There are European CAs that still do it AFAIK.  I have proof somewhere in the
cert menagerie :-).

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 21 Oct 2003 10:00:43 -0400

At 11:12 +0100 10/20/03, Stefan Santesson wrote:
>
>I have come a cross a potential problem with RFC 3280 when working 
>on the new ETSI Certificate profile standard for identity certs.
>
>RFC 3280 states:
>
>4.2.1.1
>
>sequence of integers" procedure, multiple unrelated certificates 
>would end up having the same SKI and/or AKI values relating to 
>completely different public keys.
>
>Isn't the point that AKI:s and SKI:s should use a generation 
>algorithm that assigns them a globally unique value with high 
>probability and therefore SHOULD be derived from the public key and 
>NOT use a "monotonically increasing sequence of integers". At least 
>not starting from a small integer?
>
>/Stefan

For path building purposes, there is no need for uniqueness in these 
values.  We have stated several times that path building is NOT 
supposed to use these values to locate certs, but rather to 
disambiguate among certs that have the right Subject name (assuming a 
bottom's up path building).

However, when the SKI appears in an EE cert, and that EE cert is used 
in S/MIME, then we are assuming uniqueness, because the receiver uses 
the SKI to locate the right token for that receiver.  This support 
for S/MIME is why we put in the SKI requirement for EE certs, where 
it otherwise would not be needed (re path building).

Steve

P.S.  Peter, your example talked about signature verification, but I 
don't think that's right, because the signature info is not per 
recipient, it is per originator, and thus would not encounter this 
problem.

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 22 Oct 2003 20:23:31 +1300

"Peter Hesse" <[email-masked]> writes:

>Path building implementations should never rely on them being correct.

What's the point of having them at all then?  If you can't rely on them then
you need to have something you can rely on, and if you've got that anyway then
the unreliable alternative is superfluous.

Peter.

---

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 22 Oct 2003 11:09:02 +0100

I agree with Peter,

I think this is asking for trouble. That is my whole point.

/Stefan

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Peter Gutmann
> Sent: den 22 oktober 2003 09:26
> To: [email-masked]; [email-masked]; [email-masked];
Stefan
> Santesson
> Cc: [email-masked]
> Subject: RE: AKI and SKI problem with RFC 3280?
> 
> 
> "Al Arsenault" <[email-masked]> writes:
> 
> >Okay, it's only a SHOULD, not a MUST, but the scenario you reference
> below
> >only comes in to play if I signed the CMS message using my CA cert,
not
> my
> >end-entity cert.
> >
> >Got an example where this is relevant if the sKID's of two different
CA
> certs
> >are the same?
> 
> My CMS example from earlier used with SCEP.
> 
> In any case something like this should never be allowed to happen as a
> matter
> of basic protocol design.  Creating a "unique" key ID and then
> specifically
> telling people they can use non-unique IDs is just asking for trouble.
> 
> Peter.

---

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 22 Oct 2003 23:27:57 +0100

Agree,

And may I also suggest limiting recommendations to key identifiers
derived from the key hash, unless there is a strong need for other
solutions not yet presented in this debate.

/Stefan

> On Behalf Of Steve Hanna
> Sent: den 22 oktober 2003 22:59
> To: Peter Hesse
> Cc: [email-masked]
> Subject: Re: AKI and SKI problem with RFC 3280?
> 
> Maybe we are close to ending this discussion. Everyone
> agrees that CAs MUST use an SKI in CA certificates that
> matches the AKI used in certificates issued by the
> subject of the certificate. Relying parties can use
> this as a hint during path construction, but they should
> not require AKI/SKI matching during path construction or
> path validation.
> 
> But RFC 3280 does not say clearly and explicitly that
> relying parties should not require AKI/SKI matching.
> Several implementors have misunderstood this. I suggest
> that the successor to RFC 3280 should be changed to
> make an explicit recommendation that relying parties
> SHOULD NOT require AKI/SKI matching.
> 
> Thanks,
> 
> Steve
> 
> Peter Hesse wrote:
> >
> > Santosh,
> >
> > Point taken.  3280 therefore requires that the keyIdentifier method
(as
> > opposed to the issuer DN/serial tuple) MUST be used.  In 4.2.1.1
(AKID)
> > it only RECOMMENDS this; but the words you quote from 4.2.1.2 (SKID)
> > make it a requirement, intentionally or not.  As you said, in the
below
> > case, at least one CA is not compliant with 3280.  Unfortunately,
I've
> > seen this happen in practice.  As you said earlier, it would be best
if
> > path building implementations could be flexible about this, but
> > certificate producers should be compliant.
> >
> > Two other things: Sharon is dead on, and the only thing I would say
is
> > that support for accepting SKIDs in certification requests seems to
work
> > well with a particular implementation, but require manual input or
is
> > not possible between different implementations.
> >
> > And Jean-Marc was also quite correct, my example was wrong.  It's
the
> > Issuer's Issuer DN and serial, I just put the Issuer's DN in my
example.
> > Shame on me.
> >
> > --Peter
> >
> > +---------------------------------------------------------------+
> > | Peter Hesse                    [email-masked]     |
> > | 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
> >
> > On Behalf Of Santosh Chokhani
> > Sent: Wednesday, October 22, 2003 2:01 PM
> > To: [email-masked]
> > Peter:
> > Section 4.2.1.2 (Subject Key Identifier) of 3280 states and I quote:
> > "The value of the subject key identifier MUST be the value placed in
the
> > key identifier field of the Authority Key Identifier extension
(section
> > 4.2.1.1) of certificates issued by the subject of this certificate."
> > Read in context, the above is stated for CA certificates.
> >
> > Thus, in cross certified environment, 3280 compliant issuing CAs
need to
> > ensure that the SKI in 3280 compliant subject CA certificate is the
> > value that the subject CA intends to use as AKI for certificates it
> > issues.
> >
> > If the AKI and SKI (even for cross certified environments) do not
chain,
> > one or more of the CAs is not compliant with 3280.
> >
> > From: Peter Hesse [mailto:[email-masked]]
> > Sent: Wednesday, October 22, 2003 12:59 PM
> > To: 'Santosh Chokhani'; [email-masked]
> > Santosh Chokhani wrote:
> > > My e-mail needs to be read in the context of the producers. The
CAs as
> >
> > > producers need to ensure that the AKI and SKI chain. If the CAs do
not
> >
> > > do that, they are not compliant with 3280.
> > > That means in order to comply with 3280 issuing CA needs to
> > > honor the SKID requested by the subject CAs.
> >
> > I think we're in violent agreement.  My main point was that although
the
> > producer needs to ensure that AKID and SKID chain, cross-PKI
> > interoperability will cause cases in which the producer must choose
> > between two (or more) equally valid AKIDs to place in a subject
> > certificate.  Either of them will chain successfully and the
producer
> > will be compliant; but as a result there will be valid paths where
the
> > AKID and SKID will not chain, through no fault of the producer.
> >
> > --Peter

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 23 Oct 2003 16:38:36 +1300

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

"Stefan Santesson" <[email-masked]> 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?= <[email-masked]> 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" <[email-masked]> 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 <[email-masked]> 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.