Re: PKI Resources Query Protocol

Massimiliano,

>I am working on the definition of a new protocol aimed to solve the problem
>tied to the lack of informations about repositories and services offered
>by a CSP.

OK. Does that also include warranties?

>One of the problems we are facing now is how to connect different
>closed existing PKIs.

What do you mean with "connect"?  I thought that NIST and other US
government bodies already consider this solved by using bridge CAs.
(personally I believe bridges will rarely reach outside of the public
sector border as neither the implicit trust model, nor the bridge CA 
business model are particularly suited for the commercial world)

>For this purpose I think that the availability of URI about offered services
>(e.g. OCSP, SCVP, etc... ) or available data (e.g. certificate and CRLs
>repositories) would help in PKI interoperability.

How do you find the URI?  In a certificate extension or OOB?

>Therefore I am trying to work on this subject by defining a newprotocol.
>Reasons to adopt such a protocol are:
>- extensions are too static, if new services or repositories are added
>   (or dismissed) by the CSP, there is no sign of the changes into the
>   already issued certificates
>- no need to define new type of extensions for new services and/or

Re: Last Call: 'Required functions of User Interface for the Internet X.509 Public Key Infrastructure' to Informational RFC

[resend due to "only members can post" on ietf-pkix]

Re: http://www.ietf.org/internet-drafts/draft-choi-pkix-ui-03.txt

Dave Crocker wrote:
>> - 'Required functions of User Interface for the Internet X.509 Public Key
>> Infrastructure '
>> <draft-choi-pkix-ui-03.txt> as an Informational RFC
> 
> RFC document titles should not carry language that states or implies that their 
> contents mandate conformans.
> 
> Hence, the word "Required" should be removed from this document title.
> 
> The issue is only exacerbated by the fact that it is seeking non-standards 
> status.

Also, the document has received no review in Working Groups for which it is
relevant, such as TLS and PKIX (there are references to its existence in the
PKIX archives, but no discussion). It seems to have been in desperate need
of such review:

#  Compatibility shall be accomplished for using one certificate to many
#  PKI applications. Generally, PKI application such as the Internet
#  Banking or E-mail application defines the user's certificate and
#  private key location by their own way. Thereby, when using those
#  applications, users are at a loss whenever receiving a question where
#  their certificates are. Most users do not know the answer, and they
#  want to use different PKI programs with their own certificate without

Authority Key Identifier extension for a CRL issued by a subordinate CA

Hi,

Consider a subordinate CA that issues a CRL. Regarding the Authority Key
Identifer extension for the CRL in the "issuer name and serial number"
form. What is the correct name to be included, the one of the
subordinate CA or the one of the root CA?

Thanks in advance,

Miguel Rodriguez
SeguriData 
Mexico

RE: Authority Key Identifier extension for a CRL issued by a subordinate CA

Miguel,

Generally it is not a good idea to use that option for AKID.

But, the value is supposed to represent the certificate issued to the CA.
Thus, the issuer DN should be that of the parent CA that issued a
certificate to the CRL issuing CA (it could be the Root or an intermediate
CA) and the serial number should be that of the certificate issued by the
issuer DN to the CRL issuing CA.

-----Original Message-----
From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org] On
Behalf Of Miguel A Rodriguez
Sent: Tuesday, July 05, 2005 1:48 PM
To: ietf-pkix <at> imc.org
Subject: Authority Key Identifier extension for a CRL issued by a
subordinate CA

Hi,

Consider a subordinate CA that issues a CRL. Regarding the Authority Key
Identifer extension for the CRL in the "issuer name and serial number" form.
What is the correct name to be included, the one of the subordinate CA or
the one of the root CA?

Thanks in advance,

Miguel Rodriguez
SeguriData 

Re: Last Call: 'Required functions of User Interface for the Internet X.509 Public Key Infrastructure' to Informational RFC

David Hopwood wrote:

<snip>

>using a single certificate ensures that loss or compromise of one
> private key necessarily implies loss or compromise of the user's
> identity for many different applications. (This problem is not solved
>just by using multiple certificates, but at least it is not precluded
>from being solved.)

The use of the word "problem" is not entirely correct, I would rather
say that this usage *solves* a number of serious real-life problems
that will face a future PKI-enabled user.

Compromise (=theft/loss): ONE revocation and all
associated services are blocked.

Recovery of lost IT-life: ONE renewal/RA process and you are back.

Economics: To pay for having a passport-like ID seems reasonable
if you have multiple uses.  This is probably also a pre-requisite for
creating globally working CA/RA networks.

Company or national CA networks including the US PIV-program
do not address these issues.

<snip>

Sincerely

Re: Last Call: 'Required functions of User Interface for the Internet X.509 Public Key Infrastructure' to Informational RFC

Anders,

I refer you to a report by the U.S. National Research Council, 
entitled "Who Goes There? Authentication Through the Lens of 
Privacy."  The report was issued almost 2 years ago and it strongly 
recommends against the single cert per user model, for both privacy 
and security reasons.

Steve

Re: Re: Last Call: 'Required functions of User Interface for the Internet X.509 Public Key Infrastructure' to Informational RFC

3280bis: CRL validation: treatment of critical CRL entry extensions

3280bis: CRL validation: treatment of critical CRL entry extensions

RFC 3280 states on page 60 :

" 5.3  CRL Entry Extensions

   [...]

   All CRL entry extensions used in this specification are non-critical."

This is however untrue since RFC 3280 states on page 62 :

" 5.3.4  Certificate Issuer

   This CRL entry extension identifies the certificate issuer associated
   with an entry in [...] a CRL that has the indirectCRL indicator set
   in its issuing distribution point extension.

[...]

   If used by conforming CRL issuers, this extension MUST always be
   critical."

The text is unclear about what to do with a critical CRL entry extension
that is not recognized, and thus this needs to be clarified.

CRL entry extensions did not existed originally in CRL version v1 and could
be ignored when parsing a CRL. When introducing CRL entry extensions, the
idea was the following: if a given CRL entry is found to be "appropriate"
THEN and only THEN there is the need to make sure that it contains no
critical CRL entry extension that is not understood. If it does then the
CRL entry MUST be considered as invalid.

The problem is that, later on, a specific critical CRL entry extension has
been introduced: the Certificate Issuer CRL entry extension. That CRL entry
extension is very special since its presence in a CRL entry extension
earlier in the list of CRL entries modifies the meaning the CRL entry,
even if it does not contain a CRL entry extension.

This problem was however addressed by RFC 3280 since RFC 3280
states on page 59:

"The CRL issuer MUST assert the indirectCRL boolean, if the scope of
the CRL includes certificates issued by authorities other than the
CRL issuer.  The authority responsible for each entry is indicated
by the certificate issuer CRL entry extension (section 5.3.4)".

These two sentences are within the same paragraph, just one after
the other.

In the first sentence, the plural is used for "authorities" and thus
the first sentence is NOT written as follows : "The CRL issuer MUST
assert the indirectCRL boolean, if the scope of the CRL includes
certificates issued by *an authority* other than the CRL issuer".

The two sentences from page 59 from RFC 3280 would need to be
corrected in the following way:

"The CRL issuer MUST assert the indirectCRL boolean, if the scope of
the CRL includes certificates issued by *more than one certificate
issuer*. In such a case, the certificate issuer responsible for each
entry is indicated by the certificate issuer CRL entry extension
(section 5.3.4)".

These sentences indicate that, if the indirectCRL boolean is set to
TRUE, then one or more certificate issuer CRL entry extensions are
present.

This also means that if the IDP extension is not present or if the
indirectCRL boolean is set to FALSE, then no certificate issuer CRL
entry extension is present.

The indirectCRL boolean indicates the presence or absence of
certificate issuer CRL entry extensions in the CRL.

It allows to perform an efficient checking of the CRL entries :

 -    If the indirectCRL boolean is set to TRUE, then the CRL entry
      extensions from previous CRL entries MUST be checked to verify
      whether a certificate issuer CRL entry extension is present.

-     If the IDP extension is not present or if the indirectCRL boolean
      is set to FALSE, then CRL entry extensions from every CRL entry
      can ignored or skipped.

The core of the issue is about the following paragraph in section
6.3.3 on page 84 :

      (1)  If the DP includes cRLIssuer, then verify that the issuer
      field in the complete CRL matches cRLIssuer in the DP and that
      the complete CRL contains an issuing distribution point
      extension with the indrectCRL boolean asserted.  Otherwise,
      verify that the CRL issuer matches the certificate issuer.

BTW, there is a typo error where "indirectCRL" is typed
"indrectCRL".

Note that the current text in section 6.3.3 from RFC 3280 does not
handle the Certificate Issuer CRL entry extension, when present,
which may lead to incorrect results.

When the DP includes the cRLIssuer field, verifying that *one value*
from the issuer field in the complete CRL matches cRLIssuer in the
DP is both necessary and sufficient.

There is no need to have the following insertion :

                                                      " and that
         the complete CRL contains an issuing distribution point
         extension with the indirectCRL boolean asserted ".

Denis

3280bis: CRL validation: what is wrong and/or missing in section 6.3

3280bis: CRL validation: what is wrong and/or missing in section 6.3.

1. The very first sentence states:

 " This section describes the steps necessary to determine if a
   certificate is revoked or on hold status when CRLs are the revocation
   mechanism used by the certificate issuer".

a) This section should describe the steps necessary to determine
   if the revocation status of the certification path* is : REVOKED,
   NOT_REVOKED or UNKNOWN, instead of simply determine if the
   *target certificate* is REVOKED. So the sentence is incorrect.

b) The current text mentions the return of the "on hold" status.
   However since CRLreason is not mentioned as an output parameter
   of the algorithm, this may not be the case (the only algorithm
   output is currently the revocation status of the certificate).

2. The text states: " Conforming implementations that support
CRLs are not required to implement this algorithm, but they MUST
be functionally equivalent to the external behavior resulting
from this procedure".

This sentence is incorrect since the algorithm would mandate
the support of many certificate extensions, CRL extensions and
CRL entry extensions that conforming relying party applications
are NOT REQUIRED to support. The current algorithm has many errors
in it cannot be easily simplified, if less than "all options"
are supported by a relying party.

3. The text states: "This algorithm assumes that all of the needed
CRLs are available in a local cache".

This sentence is incorrect, because it may happen that the "right"
or a "current" CRL is  unavailable and thus absent; in such a case
the algorithm terminates with "UNDETERMINED" or "UNKNOWN". 

4. The text states:

"This algorithm begins by assuming the certificate is not revoked."

This sentence is incorrect, the algorithm should begin by assuming
the status of the certificate is "UNDETERMINED" or "UNKNOWN".

5. The text states, [omitting what is relevant to delta CRLs]

"(a)  Update the local CRL cache by obtaining a complete CRL [ ] :

         (1)  If the current time is after the value of the CRL next
         update field, then do one of the following :

            (i) [ ].

            (ii)  Update the local CRL cache with a current complete
            CRL, verify that the current time is before the next update
            value in the new CRL, [ ]".

This is incorrect. If the "current" CRL cannot be found, then it is
still possible to use an older CRL to demonstrate that the certificate
was REVOKED. Of course, when using an older CRL it is not possible
to demonstrate that the certificate was NOT_REVOKED.

6. The current algorithm cannot make sure that an emergency CRL (
i.e. the latest captured CRL) will be used if more than one
"valid" CRLs are found in the local cache.

7. The text states:

   (f)  Obtain and validate the certification path for the complete CRL
   issuer.  If a key usage extension is present in the CRL issuer's
   certificate, verify that the cRLSign bit is set.

   (g)  Validate the signature on the complete CRL using the public key
   validated in step (f).

The text is unclear about what is meant by :" validate the certification
path for the complete CRL issuer". In order to solve the problem of
identical CRL Issuer names or identical CA names, it is needed to say
that the certification path that has been used to validate the target
certificate MUST also be used.

8. There is no handling of the Certificate Issuer CRL entry extension,
when present, which may lead to incorrect results.

9. The above list should not be considered as exhaustive.

This demonstrates the need to revise in depth section 6.3.

Denis

RE: 3280bis: CRL validation: treatment of critical CRL entry extensions

Denis,

Regarding criticality, the text is already changed in RFC 3280bis. It
would be useful if you could comment on the proposed resolution in RFC
3280bis instead.

The following is however false as David has pointed out in previous
mail:

<snip>
> The two sentences from page 59 from RFC 3280 would need to be
> corrected in the following way:
> 
> "The CRL issuer MUST assert the indirectCRL boolean, if the scope of
> the CRL includes certificates issued by *more than one certificate
> issuer*. In such a case, the certificate issuer responsible for each
> entry is indicated by the certificate issuer CRL entry extension
> (section 5.3.4)".

Following your text proposal I would not have to set the indirectCRL
Boolean in an indirect CRL if the scope of the CRL serves certificates
from only 1 CA. An indirect CRL may however (in most cases) be setup
this way. 

The current text is correct, yours is not.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: owner-ietf-pkix <at> mail.imc.org
[mailto:owner-ietf-pkix <at> mail.imc.org]
> On Behalf Of Denis Pinkas
> Sent: den 11 juli 2005 13:33
> To: pkix
> Subject: 3280bis: CRL validation: treatment of critical CRL entry
> extensions
> 
> 
> 3280bis: CRL validation: treatment of critical CRL entry extensions
> 
> RFC 3280 states on page 60 :
> 
> " 5.3  CRL Entry Extensions
> 
>    [...]
> 
>    All CRL entry extensions used in this specification are
non-critical."
> 
> This is however untrue since RFC 3280 states on page 62 :
> 
> " 5.3.4  Certificate Issuer
> 
>    This CRL entry extension identifies the certificate issuer
associated
>    with an entry in [...] a CRL that has the indirectCRL indicator set
>    in its issuing distribution point extension.
> 
> [...]
> 
>    If used by conforming CRL issuers, this extension MUST always be
>    critical."
> 
> The text is unclear about what to do with a critical CRL entry
extension
> that is not recognized, and thus this needs to be clarified.
> 
> CRL entry extensions did not existed originally in CRL version v1 and
> could
> be ignored when parsing a CRL. When introducing CRL entry extensions,
the
> idea was the following: if a given CRL entry is found to be
"appropriate"
> THEN and only THEN there is the need to make sure that it contains no
> critical CRL entry extension that is not understood. If it does then
the
> CRL entry MUST be considered as invalid.
> 
> The problem is that, later on, a specific critical CRL entry extension
has
> been introduced: the Certificate Issuer CRL entry extension. That CRL
> entry
> extension is very special since its presence in a CRL entry extension
> earlier in the list of CRL entries modifies the meaning the CRL entry,
> even if it does not contain a CRL entry extension.
> 
> This problem was however addressed by RFC 3280 since RFC 3280
> states on page 59:
> 
> "The CRL issuer MUST assert the indirectCRL boolean, if the scope of
> the CRL includes certificates issued by authorities other than the
> CRL issuer.  The authority responsible for each entry is indicated
> by the certificate issuer CRL entry extension (section 5.3.4)".
> 
> These two sentences are within the same paragraph, just one after
> the other.
> 
> In the first sentence, the plural is used for "authorities" and thus
> the first sentence is NOT written as follows : "The CRL issuer MUST
> assert the indirectCRL boolean, if the scope of the CRL includes
> certificates issued by *an authority* other than the CRL issuer".
> 
> The two sentences from page 59 from RFC 3280 would need to be
> corrected in the following way:
> 
> "The CRL issuer MUST assert the indirectCRL boolean, if the scope of
> the CRL includes certificates issued by *more than one certificate
> issuer*. In such a case, the certificate issuer responsible for each
> entry is indicated by the certificate issuer CRL entry extension
> (section 5.3.4)".
> 
> These sentences indicate that, if the indirectCRL boolean is set to
> TRUE, then one or more certificate issuer CRL entry extensions are
> present.
> 
> This also means that if the IDP extension is not present or if the
> indirectCRL boolean is set to FALSE, then no certificate issuer CRL
> entry extension is present.
> 
> The indirectCRL boolean indicates the presence or absence of
> certificate issuer CRL entry extensions in the CRL.
> 
> It allows to perform an efficient checking of the CRL entries :
> 
>  -    If the indirectCRL boolean is set to TRUE, then the CRL entry
>       extensions from previous CRL entries MUST be checked to verify
>       whether a certificate issuer CRL entry extension is present.
> 
> -     If the IDP extension is not present or if the indirectCRL
boolean
>       is set to FALSE, then CRL entry extensions from every CRL entry
>       can ignored or skipped.
> 
> The core of the issue is about the following paragraph in section
> 6.3.3 on page 84 :
> 
>       (1)  If the DP includes cRLIssuer, then verify that the issuer
>       field in the complete CRL matches cRLIssuer in the DP and that
>       the complete CRL contains an issuing distribution point
>       extension with the indrectCRL boolean asserted.  Otherwise,
>       verify that the CRL issuer matches the certificate issuer.
> 
> BTW, there is a typo error where "indirectCRL" is typed
> "indrectCRL".
> 
> Note that the current text in section 6.3.3 from RFC 3280 does not
> handle the Certificate Issuer CRL entry extension, when present,
> which may lead to incorrect results.
> 
> When the DP includes the cRLIssuer field, verifying that *one value*
> from the issuer field in the complete CRL matches cRLIssuer in the
> DP is both necessary and sufficient.
> 
> There is no need to have the following insertion :
> 
>                                                       " and that
>          the complete CRL contains an issuing distribution point
>          extension with the indirectCRL boolean asserted ".
> 
> Denis
> 
> 
>