[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AKI and SKI problem with RFC 3280?
David:
Banning sequential ID's and having the issuer calculate the key ID
doesn't seem to help much. If the subject CA uses method 1 (in section
4.2.1.2 of RFC 3280) and the issuer uses method 2, the key ID's won't
match. Short of requiring a SINGLE calculation method for CA key ID's,
there seems to be no substitute for communication - having the subject CA
include the key ID in the request.
If we agree that in the general case the subject CA should assign
its own key ID, how does the issuing CA find out which value that is? The
two most usual methods for the subject CA to tell the issuing CA anything
are probably CRMF and PKCS#10. In CRMF you can just put the SubjectKeyID
extension into CertTemplate's Extensions field. In PKCS#10 the same
extension goes into the PKCS#9 ExtensionRequest attribute.
Tom Gindin
"David P. Kemp" <dpkemp@xxxxxxxxxxxxxx>
Sent by: owner-ietf-pkix@xxxxxxxxxxxx
10/26/2003 11:36 AM
To: ietf-pkix@xxxxxxx
cc:
Subject: Re: AKI and SKI problem with RFC 3280?
Oops, now I understand the scenario Steve Hanna was referring to:
1. Subject CA picks it's own AKI using a computation
technique, assuming issing CAs will use the same value
for SKI (as they should).
2. Issuing CA issues a cross-cert with an SKI using a different
computation technique, blindly assuming that subject CA will
take what he has been given to use as AKI as if subject were
a child in issuer's hierarchy.
Sorry, Steve for my rant. A working system has to have a common
set of assumptions, such as SKIs flow from the top down (works only
for hierarchies), or SKIs flow from the subject CAs to the issuers
(works in any topology), or every CA uses the same SKI computation
technique (works in any topology). I didn't consider the situation
where the issuing CA and subject CA operate using different concepts
of who does what to whom. Thanks, Stefan, for pointing out that
some CAs that were designed for use only in hierarchies are being
misused to issue cross certificates.
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.
>>>
>>>
>>>
>>>
>
>