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

Re: Signer certificate discovery for CRLs


Stefan,

Denis,

Unfortunately I fail to understand your questions, issues and requests.

The sentence below demonstrates that you understand the issue.

It would be very useful if you could explain how current mechanisms can
be used in a simple and straightforward manner to discover CRL signer
certificates in ALL the use cases discussed, mainly re-keyed CA and
indirect CRLs.

You are also reversing the question. Using your terms, my question would be:

"It would be very useful if you could explain how current mechanisms CANNOT
be used in a simple and straightforward manner to discover CRL signer
certificates in ONE or MORE the use cases discussed, mainly re-keyed CA and
indirect CRLs."

Denis

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)



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

[mailto:owner-ietf-pkix@xxxxxxxxxxxx]

On Behalf Of Denis Pinkas
Sent: den 14 oktober 2004 17:13
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Signer certificate discovery for CRLs


Santosh,


Denis:

With the three assumptions/constraints I provided, how would you

locate

the

CRL issuer certificate for the two examples using 3280 extensions

and

without putting AIA in the CRL?

As far as I understand, the three assumptions are:

1.  You are directory challenged; and
    [I do not understand what this means]
2.  You use AIA to develop the path; and
    [It does not matter]
3.  You develop the path from the end entity to trust anchor
    [Could also be the contrary].

If this is not correct, thus please correct.

Then my request is: "using ANY OF the current extensions that are

defined

in
RFC 3280", which includes SIA.

In your explanations  you said :
"if you do no deal with SIA et. al"

This last assumption is neither part of the three assumptions and does

not

conform to my request.

Denis


That is my point.

-----Original Message-----
From: Denis Pinkas [mailto:Denis.Pinkas@xxxxxxxx]
Sent: Thursday, October 14, 2004 6:22 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: Signer certificate discovery for CRLs


Santosh,

You misread my request. I said:

"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."

Maybe I would have needed to be clearer and say :

"For the time being, I would like that you provide an example where,

when

using ANY OF the current extensions that are defined in RFC 3280, it

will

NOT be possible to locate a CRL Issuer certificate."

The examples you provide below do not fulfil this request.

The assumption is that there exists a path to be tested for

revocation

checking (and that it does not matter to know which way it has been
constructed).

I am not saying that using AIA in CRL might not be useful, but I am

still

lacking the demonstration that there would be no other way.

Denis




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?cACe

r

t
i

fi




ca




te
,crossCertificatePair

ldap://129.6.20.71/cn=Good%20CA,o=Test%20Certificates,c=US?cACertif

i

c
a

te




;b




in
ary,crossCertificatePair;binary

http://fictitious.nist.gov/fictitiousCertsOnlyCMSdirectory/certsIss

u

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)