This was the first answer from Microsoft. Perhaps my description was not
really perfect.
Michael
-------- Original Message --------
Subject: RE: RFC 3280 and smartcardlogin
Date: Mon, 2 Dec 2002 08:55:13 -0800
From: David Cross <[EMAIL PROTECTED]>
To: Glenn Pittaway <[EMAIL PROTECTED]>, Michael Bell
<[EMAIL PROTECTED]>, Laudon Williams
<[EMAIL PROTECTED]>
I am slightly confused on the problem you are encountering. The AKI
matches the SKI in the issuer certificate and we validate that on our
clients and servers. There is no standard way (only recommendations) on
how to generate theat value - the only requirement is that they match.
You should never be re-calculating the AKI and SKI values - you should
always perform a binary comparison. If we changed our current
algorithm, this could break hundreds of millions of clients. Relevant
abstract:
4.2.1.1 Authority Key Identifier
The authority key identifier extension provides a means of
identifying the public key corresponding to the private key used to
sign a certificate. This extension is used where an issuer has
multiple signing keys (either due to multiple concurrent key pairs or
due to changeover). The identification MAY be based on either the
key identifier (the subject key identifier in the issuer's
certificate) or on the issuer name and serial number.
The keyIdentifier field of the authorityKeyIdentifier extension MUST
be included in all certificates generated by conforming CAs to
facilitate certification path construction. There is one exception;
where a CA distributes its public key in the form of a "self-signed"
certificate, the authority key identifier MAY be omitted. The
signature on a self-signed certificate is generated with the private
key associated with the certificate's subject public key. (This
proves that the issuer possesses both the public and private keys.)
In this case, the subject and authority key identifiers would be
identical, but only the subject key identifier is needed for
certification path building.
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. 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.
This profile RECOMMENDS support for the key identifier method by all
certificate users.
This extension MUST NOT be marked critical.
id-ce-authorityKeyIdentifier OBJECT IDENTIFIER ::= { id-ce 35 }
AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNames OPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }
KeyIdentifier ::= OCTET STRING
David B. Cross
Program Manager
Windows Security
-----Original Message-----
From: Glenn Pittaway
Sent: Monday, December 02, 2002 8:25 AM
To: Michael Bell; Laudon Williams; David Cross
Subject: RE: RFC 3280 and smartcardlogin
Laudon/David,
Can either of you comment?
Glenn
-----Original Message-----
From: Michael Bell [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 29, 2002 3:29 AM
To: Glenn Pittaway
Subject: RFC 3280 and smartcardlogin
Dear Mr. Pittaway,
we tested the Microsoft smartcard login successfully with a Citrix
Metaframe Server. This is also possible with a third party CA. The
problems starts if we use a CA-hierarchy. The software tries to validate
the complete certificate chain what is really good.
We afraid that there is a problem in the extension interpretation of the
validation code. It expects in the authorityKeyIdentifier in the field
authorityCertIssuer (see RFC 3280) at every time the issuer of the
certificate but this is only correct for selfsigned CA-certificates. If
you use a hierarchy which is higher than one then the
authorityCertIssuer is the issuer of the CA-cert and not the subject of
the CA-cert.
The problem is that PKIX and some laws in Europe require the use of this
extension and Microsoft is the only vendor who interprets RFC 3280 in
this way. So we cannot simply remove the extension from the
certificates. The result is that we cannot create hierarchies with
Microsft smartcardlogin or we have to build only flat hierarchies (means
there is no hierarchy).
My question is now who can I contact at Microsoft to get a statement
about this problem and does Microsoft see the problem as a bug or as is
because a patch would break too many clients?
Best regards
Michael Bell
--
-------------------------------------------------------------------
Michael Bell Email (private): [EMAIL PROTECTED]
Rechenzentrum - Datacenter Email: [EMAIL PROTECTED]
Humboldt-University of Berlin Tel.: +49 (0)30-2093 2482
Unter den Linden 6 Fax: +49 (0)30-2093 2959
10099 Berlin
Germany
--
-------------------------------------------------------------------
Michael Bell Email (private): [EMAIL PROTECTED]
Rechenzentrum - Datacenter Email: [EMAIL PROTECTED]
Humboldt-University of Berlin Tel.: +49 (0)30-2093 2482
Unter den Linden 6 Fax: +49 (0)30-2093 2959
10099 Berlin
Germany http://www.openca.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
- [Fwd: RE: RFC 3280 and smartcardlogin] Michael Bell
- Michael Bell
