Denis:
Two examples are very simple: one for direct CRL Issuer and one for
Indirect CRL Issuer.
Let us make the following assumptions that Stefan was making:
1. You are directory challenged; and
2. You use AIA to develop the path; and
3. You develop the path from the end entity to trust anchor.
From what I know of MS CAPI, these are reasonable
assumptions/constraints.
Now the examples.
Example 1: Direct CRL Issuer
The certificate trust path is:
Root --> CA1 --> CA 2, old key --> Denis
The CRL trust path is:
Root --> CA1 --> CA 2, new key --> CRL
(Note: We do not do self-issued certificate since there is no simple,
secure way to check their revocation status).
Now, with AIA in CRL, finding the CA2, new key certificate is
straightforward. How would you find it if you do no deal with SIA et.
al.
Example 2: Indirect CRL Issuer
The certificate trust path is:
Root --> CA1 --> CA 2 --> Denis
(Note: Denis's certificate points to CRL DP of an indirect CRL issued
by CAI.
The CRL trust path is:
Root --> CAI --> CRL
Now, with AIA in CRL, finding the CAI certificate is straightforward.
How would you find it if you do no deal with SIA et. al.
In addition to the need cited above, please note that the extension
semantics does not change, it does not hinder any interoperability,
and it does not break any backward compatibility. So, what if I
wanted to use this extension in the CRL. It does no harm to other
relying parties.
-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Denis Pinkas
Sent: Wednesday, October 13, 2004 11:01 AM
To: Stefan Santesson
Cc: Santosh Chokhani; pkix
Subject: Re: Signer certificate discovery for CRLs
Stefan,
Denis,
I'm not sure what you mean.
For the time being, I would like that you provide an example where,
when
using the current extensions that are defined in RFC 3280, it will NOT be
possible to locate a CRL Issuer certificate.
If you are able to provide that example, then it would justify the
need for
an extension at least for one case. Then we can see what that case is.
I am awaiting that example.
Denis
I conclude that I agree with Santosh.
The debate is still open... Feel free to express your opinion.
Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
-----Original Message-----
From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
Sent: den 13 oktober 2004 16:34
To: Stefan Santesson
Cc: Santosh Chokhani; pkix
Subject: Re: Signer certificate discovery for CRLs
Stefan,
You are making a conclusion without letting me the time to respond. I
will need more time to look at the pictures (and understand them).
For the time being, I am still reluctant to accept
"yet-another-method".
We already have too many.
Santosh,
I conclude that we are in complete and total agreement.
The question is how to go about this.
Could we do this amendment to RFC 3280 in its next revision? It
would hopefully just be a minor change.
This is exactly what I feared.
We usually end-up with a "minor change" in an extension without
saying cleary how and when it shall/should be used.
I still have in mind that:
1) a certification path must first be constructed,
2) then the revocation checking of that path must be done.
This means that information about CRL issuers certificates locations
may
certainly be found in that chain. If not, I would like an example.
Denis
It would not change the definition of AIA just add that it can be
used
also as CRL extension and list eventual restrictions and guidance for
use
with CRLs.
Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
On Behalf Of Santosh Chokhani
Sent: den 13 oktober 2004 04:33
To: 'pkix'
Subject: RE: Signer certificate discovery for CRLs
Stefan:
In terms of certificate discovery, your proposal for AIA in CRL is
more
robust. The whole idea of self-issued key rollover certificates
and
then
using the new key to issue CRL is fraught with security problems.
A secure solution would be one where the new key is certified by
the parent
CA.
In
that case to obtain the new certificate, you could use AIA in CRL.
As to indirect CRL, your proposal is a good one. The CRL DP in
certificate in question points to the indirect CRL. You get that
CRL. The AIA
in
CRL
gets you started for the indirect CRL issuer certification path and
you
are
in business.
-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
On
Behalf Of Stefan Santesson
Sent: Tuesday, October 12, 2004 7:30 PM
To: David A. Cooper
Cc: pkix
Subject: RE: Signer certificate discovery for CRLs
David,
Thanks for the clarifications, they make sense.
I did misread your pictures.
So can we conclude that for a re-keyed CA in accordance with RFC
3280,
either the CRL issuer certificate itself, or the location of the
CRL issuer certificate, will be clearly identified/available for
the validating
party
in some cases, but not in others?
Can we also conclude that there is no real discovery solution for
indirect
CRLs?
Do you then agree then that it could be appropriate to allow AIA as
a
CRL
extension to facilitate discovery of CRL signer certificate?
Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
________________________________________
From: David A. Cooper [mailto:david.cooper@xxxxxxxx]
Sent: den 12 oktober 2004 21:14
To: Stefan Santesson
Cc: pkix
Subject: Re: Signer certificate discovery for CRLs
Stefan,
I believe that you are misinterpreting the figures. They really do
represent three different cases, not three different certification
paths
that have been constructed through the same PKI architecture.
In figure 1, CA 1 has generated self-issued key rollover
certificates.
The
Root CA has issued a certificate to CA 1's new key, but not its old
key
(either the Root CA never issued a certificate to CA 1's old key or
that
certificate has expired).
In figure 2, CA 2 has also generated self-issued key rollover
certificates. The Root CA has issued a certificate to CA 2's old
key, but not its
new
key.
In figure 3, when CA 3 performed key rollover, it requested a new
CA certificate from the Root CA. CA 3 did not generated
self-issued
key
rollover certificates.
Of course, another realistic scenario would be one in which a CA
generated
self-issued key rollover certificates upon key rollover and then
had
the
Root CA issue a CA certificate to its new key. In this case, as
you suggest, any of the certification paths from figures 1, 2, or 3
could be
constructed.
As for the contents of the AIA extension, here is what I have
specified
in
the "X.509 Certificate and CRL Extensions Profile for the Common
Policy":
The authorityInfoAccess extension uses URIs for two purposes. When
the
id-ad-caIssuers access method is used, the access location
specifies
where
certificates issued to the issuer of the certificate may be found.
If
LDAP
is used, the URI must include the DN of the entry containing the
relevant
certificates and specify the directory attribute in which the
certificates
are located. If the directory in which the certificates are stored
expects
the "binary" option to be specified, then the attribute type must
be followed by ";binary" in the URI. If HTTP is used, the URI must
point to
a
file that has an extension of ".p7c" that contains a certs-only CMS
message (see RFC 2633). The CMS message should include all
certificates
issued
to
the issuer of this certificate, but must at least contain all
certificates
issued to the issuer of this certificate in which the subject
public
key
may
be used to verify the signature on this certificate. .... For a
certificate issued by "Good CA", some examples of URIs that may
appear as the
access
location in an authorityInfoAccess extension when the
id-ad-caIssuers
access
method is used are:
ldap://smime2.nist.gov/cn=Good%20CA,o=Test%20Certificates,c=US?cACer
t
i
fi
ca
te
,crossCertificatePair
ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertifi
c
a
te
;b
in
ary,crossCertificatePair;binary
http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIssu
e
d
To
Go
od
CA.p7c
For both LDAP and HTTP, the URI provides the exact location where
information is to be located, so there is no requirement for the
relying
party to try to figure out where information is located.
The HTTP URI points to a certs-only CMS message that includes all
certificates issued to the CA identified in the issuer field of the
certificate.
The LDAP URI points to the cACertificate and crossCertificatePair
attributes of the directory entry of the CA identified in the
issuer field of
the
certificate. These two attributes together hold all of the
certificates
issued to the CA: the cACertificate attribute holds the CA's self-
issued
certificates and the crossCertificatePair attribute holds the
cross-certificates issued to the CA by other CAs.
Dave
Stefan Santesson wrote:
David,
Thanks for these good thoughts and very useful scenarios.
I have some comments and questions on this.
First of all we can conclude that in some scenarios (figure 1)
where
a
self
issued certificate is inserted into the path, you are likely to
find
the
CRL
issuer cert in the path. (given that the new CA have a common key
and
certificate for cert signing and CRL signing).
Figure 1, 2 and 3 describe the same case. It is just describing
different
path building strategies. An application that has access locally to
all
chaining options may however still choose path 2 for the certs and
path
1
for the CRL independent of each other (which I think figure 3 tries
to
describe)
Another comment is the structure of AIA extensions. The use I'm
familiar
with doesn't use AIA to describe a directory entry where it is left
to
the
validation application logic to be intelligent enough to find
appropriate
certificate data from the directory. The model I'm familiar with is
when
the
AIA URL explicitly identifies the exact location of the appropriate
CA
certificate file, relieving the validation software from complex
information queries. If just location of explicit certificate files
are
identified
through AIA, the presence of an AIA may not help finding the CRL
signer
cert
if this is different from the CA certificate. This is also the
problem
with
Denis proposal.
I think we share the basic conclusion that the ability to locate
the
CRL
signer certificate directly through the CRL could be very useful.
At
least
in the case of indirect CRL but it could also be proven very useful
in
CA
re-keying scenarios.
The easiest solution would probably be to allow AIA to be used in
its
current shape and structure as a CRL extension (MUST NOT be
critical).
It
would present a very clear and uncomplicated logic to certificate
validating applications in many cases.
Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
________________________________________
From: David A. Cooper [mailto:david.cooper@xxxxxxxx]
Sent: den 7 oktober 2004 18:35
To: Stefan Santesson
Cc: pkix
Subject: Re: Signer certificate discovery for CRLs
Stefan,
I think what you are proposing is a good idea. In most cases, path
discovery algorithms assume that both the trust anchor (or trust
anchors)
and the end entity certificate are provided as input. In this
case,
one
may
need to construct a certification path without a priori access to
the
end
entity certificate (the one with the subject public key
corresponding to
the
CRL signing key). Including an AIA extension (or some other
pointer) in
the
CRL would provide the relying party with a simple way to obtain the
end
entity certificate for the CRL signing key's certification path. On
the
other hand, I believe that a relying party should be able to
construct
the
certification path even without an AIA extension in the CRL, so
long
as
it
is not an indirect CRL. Attached is a drawing of the three basic
scenarios that I expect a relying party may encounter:
In each of these scenarios, the CA has performed key rollover and
is
only
signing CRLs with its new key. The diagrams would look similar,
however,
if
the CA simply choose to use different keys to sign certificates and
CRLs
for
some other reason.
If the PKI architecture resembled figure 1, then the certification
path
for
the CRL signing key would just be a subset of the certification
path
for
the
EE certificate, so no addition path discovery would be needed.
If the PKI architecture resembled figure 1, then it would be
necessary
to
obtain the new-signed-with-old self-issued certificate. In
building
the
certification path to the EE certificate, however, the relying
party
will
obtain the certificates pointed to by the AIA extension in the EE
certificate. This AIA extension will point to a location
containing
all
certificates issued to CA 2, which would include both the
certificate
issued
by the Root to CA 2 and CA 2's self-issued certificate. So, even
though
the
self-issued certificate would not be part of the certification path
to
the
EE certificate, it would be downloaded by the relying party during
the
construction of that certification path. (Yes, there are circular
dependency issues in figure 2, but that is another issue.)
A similar situation would happen if the PKI architecture resembled
figure
3. The AIA extension in the EE certificate would point to a
location
containing certificates issued to CA 3. When the relying party
downloaded
these certificates, it would obtain both of the certificates issued
by
the
Root to CA 3 and so again would have the certificate needed to
validate
the
CRL signing key.
In the case of an indirect CRL, things may not work as well. If
indirect
CRLs were used, and the PKI architecture resembled figures 2 or 3
(replacing "New Key" with a different CA), then the set of
certificates pointed
to
by
the AIA extension in the EE certificate would not include the
certificate
of
the CRL signer. One could find this certificate by building in the
reverse direction and using the SIA extension, but that may not be
the most convenient solution.
So, when indirect CRLs are being used, it seems that it would be
very
useful
to have a pointer in the CRL to the CRL signing certificate. When
the
CRL
is not indirect, the need for this pointer does not seem to be as
clear,
but
I can't see any harm in including it.
Dave
Stefan Santesson wrote:
All,
I'm interested in the opinion from members on this list about
discovery
of
CRL signer's certificate in non directory centric environments.
The problem is the following.
The relying party (RP) needs to check validity of a certificate and
finds
a
CDP extension with a URL to the CRL. The RP retrieves this CRL
which
in
this
particular case is either signed by another key of the CA (re-keyed
CA)
or
another entity (indirect CRL).
In this case the relying party needs to obtain the certificate of
the
CRL
signer which may NOT be part of the original chain. In a directory
centric
solution this is retrieved from the directory, but what if such
directory
is
not available or accessible.
The RP have thus no hint where to find the CRL issuers certificate
unless
the RP already have possession of it by some other means.
Is seems that CRLs would need an AIA extension with the option to
point
to
the location of the signers certificate in the same manner as is
possible
for certificates.
Maybe AIA should be defined as both cert and CRL extension and not
only
certificate extension as today.
Thoughts and comments?
Stefan Santesson
Microsoft Security Center of Excellence (SCOE)