[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Signer certificate discovery for CRLs

To: "'pkix'" <ietf-pkix@xxxxxxx>
Subject: RE: Signer certificate discovery for CRLs
From: "Santosh Chokhani" <chokhani@xxxxxxxxxxxx>
Date: Thu, 14 Oct 2004 09:10:09 -0400
Importance: Normal
In-reply-to: <>
List-archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-id: <ietf-pkix.imc.org>
List-unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
Sender: owner-ietf-pkix@xxxxxxxxxxxx
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?

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?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)
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
> 
> 
>
Follow-Ups:
- Re: Signer certificate discovery for CRLs
  - From: Denis Pinkas
References:
- Re: Signer certificate discovery for CRLs
  - From: Denis Pinkas
Prev by Date: Re: Effect of adding an attribute to CSR
Next by Date: Re: Signer certificate discovery for CRLs
Previous by thread: Re: Signer certificate discovery for CRLs
Next by thread: Re: Signer certificate discovery for CRLs
Index(es):
- Date
- Thread