RE: AKI and SKI problem with RFC 3280?

["Peter Hesse" <pmhesse@xxxxxxxxxxxxxxxxxx>]

Santosh,

> Based on a review of Sections 4.2.1.2 and 4.2.1.1 of 
> 3280, I draw the following conclusion: A 3280 compliant
> CA MUST ensure that AKI and SKI chain properly.  This 
> is sufficient for path construction.  Thus, I do not 
> see a particular need to change 3280 in this area.

I read this differently.  I agree that for a given CA, that CA must make
sure that for certificates it issues, the AKID and SKID must match.
However, when you add the "IssuerDN/Serial" tuple version of AKID, that
can no longer be true.  When you start interoperating across domains,
there are times at which AKID and SKID will not match, but yet it should
lead to a valid path.  Consider the following example:

+------------------+                +--------------------+
|  Allied Pilots   |                |     Boeing Root    |
| Association Root |                |                    |
|                  |                | SKID: Q            |
| SKID: A          |                |                    |
+------------------+                +--------------------+
         \                                   /
          \                                 /
           V                               V
    =================================================
    | +-------------------+   +-------------------+ |
    | | American Airlines |   | American Airlines | |
    | |                   |   |                   | |
    | | SN: 12345         |   | SN: 87654         | |
    | | SKID: Z           |   | SKID: Z           | |
    | | AKID: A           |   | AKID: Q           | |
    | +-------------------+   +-------------------+ |
    =================================================
                            |
                            |
                            V
                  +-------------------+
                  |     Joe Pilot     |
                  |                   |
                  | SKID: W           |
                  | AKID: "American   |
                  |        Airlines,  |
                  |        12345"     |
                  +-------------------+

In our example, we have the "American Airlines" entity which has two
certificates, one issued by the Allied Pilots Association (AA's union)
and the other by Boeing (one of their manufacturers).  These two
certificates have the same public key and subject public key identifier,
but different serial numbers.  "American Airlines" issues a certificate
to "Joe Pilot".  Although Joe Pilot's AKID points to the AA Root
certificate issued by the Allied Pilots Association, there is no reason
why a path to the Boeing Root should not be found equally acceptable.

The other thing at play was what Steve Hanna mentioned in an earlier
message.  Currently, there is no commonly accepted way to for a
cross-certifying CA to accept the desired SKID in a request for
cross-certification.  Therefore, many CAs  calculate their own SKID.  In
fact, look at this part of section 4.2.1.2 of RFC3280:

   For CA certificates, subject key identifiers SHOULD be 
   derived from the public key or a method that generates 
   unique values.

Here, 3280 is saying you should derive the SKID from the public key, it
says nothing about making use of any existing  key identifier that the
CA is putting as the AKID in certificates it issues.  But wait!  If you
read down a little further, you get: 

   Where a key identifier has not been previously 
   established, this specification RECOMMENDS use of one 
   of these methods for generating keyIdentifiers.  Where
   a key identifier has been previously established, the 
   CA SHOULD use the previously established identifier.

I see shoulds and recommends here, and not MUSTs.  Prior experience has
shown me that two CAs configured in different ways (or running different
software) may both derive the SKID from the public key in two different
fashions, and you can end up with the following:

+------------------+                +--------------------+
|  Allied Pilots   |                |     Boeing Root    |
| Association Root |                |                    |
|                  |                | SKID: Q            |
| SKID: A          |                |                    |
+------------------+                +--------------------+
         \                                   /
          \                                 /
           V                               V
    =================================================
    | +-------------------+   +-------------------+ |
    | | American Airlines |   | American Airlines | |
    | |                   |   |                   | |
    | | SN: 12345         |   | SN: 87654         | |
    | | SKID: Z           |   | SKID: F           | |
    | | AKID: A           |   | AKID: Q           | |
    | +-------------------+   +-------------------+ |
    =================================================
                            |
                            |
                            V
                  +-------------------+
                  |     Joe Pilot     |
                  |                   |
                  | SKID: W           |
                  | AKID: Z           |
                  +-------------------+

Although the public key has remained the same, American Airlines now has
two certificates with two different SKIDs but the same public key.
Again, there is no reason why a path from Joe Pilot to the Boeing Root
should not be valid.

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