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

Re: AKI and SKI problem with RFC 3280?


Hi Stefan,

Someone (sorry, I looked back through this thread but couldn't find it) said "we all know what's right; the question is what do real products do about it?" In this instance, doing it the way real products do it is not useful, and a standard has no choice but to stand up for what's right.

Saying "this CA behavior works for hierarchies but not for meshes" is equivalent to saying "the AKI/SKI extensions work for hierarchies but not for meshes". It is theoretically impossible for AKI/SKI to work reliably (i.e. 100% of the time instead of 1/N of the time) unless all CAs that issue CA certs implement chaining.

For the first subject CA cert there are two timing options: either the subject CA first picks its own AKI and issues some certs and then the issuing CA imports subject's SKI, or the issuing CA picks SKI first and then subject CA uses it for AKI. But for all remaining subject CA certs (cross-certs) there is only one useful option - use the subject's existing AKI as SKI. The cross-certifying CAs must either use subject's AKI or they must issue the cross-cert without an SKI extension; the third option of picking an SKI using some computation technique other than the one already used for the subject CA is a worthless and misleading waste of bits - it can cause RPs to discard valid paths (potentially the only valid path for that RP) during path construction.

I vote for keeping 3280 the way it is. But if it is changed, it should say conforming CAs MUST NOT populate SKI unless they do it as specified in 4.2.1.2. Fixing every CA is surely easier than "fixing" every application to do path construction by checking signatures, including even paths with the wrong SKIs.

Dave



Stefan Santesson wrote: 
The problem is that RFC 3280 in practice require a CA, issuing a CA
certs, to ask the subordinate CA for its preferred SKI rather than
generating it.

To my knowledge there is no CA software that has implemented that
behavior. If I'm not wrong they are all counting on that subordinate CAs
will adopt the SKI generated by the parent CA, as the AKI placed in
issued certs.

This works for strict hierarchical structures but not for generic cross
certification (such as Bridge CA) unless CAs use the same SKI generation
algorithm.

/Stefan



-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx

[mailto:owner-ietf-pkix@xxxxxxxxxxxx]

On Behalf Of David P. Kemp
Sent: den 25 oktober 2003 00:54
To: ietf-pkix@xxxxxxx
Subject: Re: AKI and SKI problem with RFC 3280?


Santosh,

I agree that Section 4.2.1.2 of 3280 unambiguously states
that an "issuing CA" that does not populate SKI with the value
of AKI used by the "subject CA" is not compliant.

It appeared that Steve Hanna was referring to non-3280-compliant
CAs, where
  "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."

A compliant "subject CA" may have an AKI computation technique,
but a compliant "issuing CA" must not have an SKI computation
technique for CA certs - it must import the subject CA's AKI.

Outside the realm of 3280 compliance, where the situation
of N different SKIs might occur and AKI/SKI don't necessarily
chain, the chaining problem occurs when two issuing CAs use
two different computation techniques to assign SKIs to the
subject, *not* when the issuing CA uses a different technique
than the subject CA.  The subject CA's techniques for choosing
an AKI for itself and SKIs to go in its issued certs is
completely irrelevant.

Dave


Santosh Chokhani wrote:

David:

Some of us are interpreting 3280 (specifically Section

4.2.1.2,Subject

Key

Identifier) to state that all N SKI should be the same and match the

AKI

used by the subject CA in the certificates it issues. If not, the

CAs

that

do not populate the
SKI, may not be RFC 3280 compliant.

Thus, your suggestion of the subject CA using one of the SKI is a

more

liberal interpretation of 3280 and is covered by our interpretation

of

3280.

At the risk of being redundant, if all CAs are 3280 compliant all N

SKI

in N

certificates issued to a CA for the same SPKI X == AKI in all

certificates

signed by the CA, where the signature can be verified using X

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx

[mailto:owner-ietf-pkix@xxxxxxxxxxxx]

On

Behalf Of David P. Kemp
Sent: Friday, October 24, 2003 12:19 PM
To: ietf-pkix@xxxxxxx
Subject: Re: AKI and SKI problem with RFC 3280?



Isn't the raison d'etre of AKI/SKI to allow a verifier
to select the correct CA cert when multiple certs of the
same issuer with different public keys are available
(i.e. during rollover)?

A CA may use any computation technique to populate the
SKI of certs that it issues, but it MUST chain its own
SKI into the AKI of certs that it issues.  Otherwise
what's the point of populating AKI at all?

The reason AKI/SKI chaining MUST NOT be enforced during
path validation is because one CA could have one
signing public key identified by N different SKIs
in N different certs. (That's a bad thang, and cross-certificates

should

follow precedent rather than using a different SKI for the same

public

key.)

But the CA MUST choose one of it's N SKIs to use as AKI, not make up

some

different N+1th value. If it picks one of the N, then AKI is helpful

1/Nth

of the time. If it picks something else, then AKI can never be

helpful.

Dave


Steve Hanna wrote:



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.