In message <[EMAIL PROTECTED]> on Fri, 1 Nov 2002 00:51:24 +0100 (MET), "Frédéric Giudicelli via RT" <[EMAIL PROTECTED]> said:
rt> Well Microsoft support tells me it's openssl's fault, and you tell rt> me it's microsoft's? I'm basing what I say, not only on the way it's implemented, but also on what's written in RFC3280 (the new version of what was RFC2459) and in various books. I've explained how it should work according to those and why OpenSSL is doing the right thing, have Microsoft done some kind of explanation of their behavior or were they just in a blame game (I suspect the latter, but I'd love to be pleasantly surprised). I'd love to hear how they think things should work. rt> It's dead end, what am I supposed to tell my clients ? rt> Well... altough PKIX recommends the use of the authorityKeyId, and that the rt> French Government says you must to have this extension, to be certified, rt> I'll have to remove this extension ? Or stop using software that can't handle security properly, OR find out if there's something else that Microsoft wants to see in their certkey store. Are the root CA and intermediate CA certificates in there (I'm fumbling in the dark with my guesses, I know)? rt> To make everybody happy let's read the RFC rt> rt> http://www.ietf.org/rfc/rfc2459.txt rt> rt> 4.2.1.1 Authority Key Identifier rt> rt> ...The identification may be based on either the rt> key identifier (the subject key identifier in the issuer's rt> certificate) or on the issuer name and serial number. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ That says it all. Just think of what the combination of issuer and serial number is used for. But you're right, it would be clearer if there was the following parenthesis added on: (the issuer and serial number in the issuer's certificate) Think about it like this: if the authorityKeyID was to have the issuer and serial number of the certificate it's in, what use would it have, since it would just duplicate parts of that same certificate (the issuer and serial number fields on the constant part of the certificate). It simply doesn't make sense to have the redundancy, and certainly doesn't help finding the specific CA certificate that was used to sign this certificate. rt> 4.2.1.2 Subject Key Identifier rt> rt> ...The value of the subject key identifier MUST be the value rt> placed in the key identifier field of the Authority Key Identifier rt> extension (see sec. 4.2.1.1) of certificates issued by the subject of rt> this certificate. rt> rt> Well the least that we could say, it is crystal clear :). rt> it's incomprehensible. I disagree with you, but I've worked with this long enough to have a rather fine-tuned understanding of how this works. It took me some time to get here. rt> I'm writting to the authors to see what they say about it, becaus rt> MS has another comprehension than yours. I'd love to hear what answers you get, from all parties. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See <http://www.stacken.kth.se/~levitte/mail/> for more info. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
