[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: WG Last Call: Son-of-2459
Tim,
> Folks,
>
> The current version of Part1 is ready for Working Group Last Call; Last
> Call will close on or after February 28, 2001.
>
> The draft is named draft-ietf-pkix-new-part1-04.txt. The text has been
> posted and is available from the usual repositories, including:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-04.txt
>
> The name constraints issue has been addressed satisfactorily. (See earlier
> message with subject "Resolution of name constraints issue").
... but, in section 6, there is nearly no text on name constraints.
> I am aware of one open issue that needs to be discussed by this group. The
> basic constraints text (4.2.1.10, page 37) and path validation algorithm
> wrap-up procedure (6.1.5, page 73) contained in this specification does not
> consider the path length constraint for an end certificate.
... and neither name constraints.
> This may be
> considered a change from RFC 2459, and ...
>
> *it was not discussed on the list*.
>
I have found some time to take a look at section 6 from the long awaited
Son-of-2459, and I am disappointed. We spent quite an hour sitting
together with you during the Pittsburgh meeting to add the name constraints
to section 6.2 and I can't find that text. :-(
So let us go one by one at the changes that are required, and a few more
that we did not discuss. This makes 14 change proposals altogether:
1. Page 13. Current text:
A CRL is a time stamped list
identifying revoked certificates which is signed by a CA and made
freely available in a public repository.
Proposed change:
A CRL includes a list identifying revoked certificates and a date
of issue for that list, which is signed by a CA (or an entity
designated by the CA) and made freely available in a public
repository.
Rational: This sentence could be misleading by using the wording "time
stamped". Also the signature is usually not done with the CA issuing key.
2. Page 58. Current text:
The
binding is limited by constraints which are specified in the
certificates which comprise the path and the initial state variables
which are specified by the relying party.
Proposed change:
The binding is limited both by constraints which are specified in
the certificates which comprise the path and the initial state
variables which are specified by the relying party, such as
certificate policy and name constraints.
Rational: name constraints were missing.
3. Page 58. Current text:
The algorithm
requires the public key of the CA, the CA's name, and any constraints
upon the set of paths which may be validated using this key.
Proposed change:
The algorithm requires the public key of the CA, the CA's name,
and any constraints upon the set of paths (i.e. using name
constraints) which may be validated using this key, and optionally
the validity period of this set of parameters (which may be
contained in a self-signed certificate).
Rational: A CA self-signed certificate, when used, contains a validity
period which allows a nice key rollover using CMP.
4. Page 58. Current text:
Section 6.3 describes the steps necessary to determine if a
certificate is (…) on hold status when CRLs are the revocation
mechanism used by the certificate issuer.
and 6.3 CRL Validation
This section describes the steps necessary to determine if a
certificate is (…) on hold status
but in practice the case of on hold is not addressed in section 6.3 ! There
should be a story saying that if the certificate is on hold, then there is
still a chance, later on, to know that the certificate is no more revoked.
The text should be amended by the editor to address that case.
5. Page 59. Current text:
The primary goal of path validation is to verify the binding between
a subject distinguished name or subject alternative name and subject
public key, as represented in the end entity certificate, based on
the public key of the trust anchor.
Proposed change:
The primary goal of path validation is to verify for a given time
the binding between a subject distinguished name or subject
alternative name and subject public key, as represented in the
end entity certificate, based on the public key of the trust
anchor.
Rational: This is only valid at a given time, and thus necessary to say it.
6. Page 60. Current text:
However, a CA may issue a
certificate to itself to support key rollover or changes in
certificate policies.
Proposed change:
However, a CA may issue a certificate to itself to support either
public key rollover, both public key rollover and changes in
certificate policies and/or name constraints.
Rational: name constraints were missing.
7. Page 61. Current text:
6.1.1 Inputs
This algorithm assumes the following seven inputs are provided to the
path processing logic:
Proposed change:
This algorithm assumes the following nine inputs are provided to the
path processing logic:
Rational: see below that two additional parameters need to be initialized.
7 + 2 = 9
8. Page 61. Current text:
(b) the time, T, for which the validity of the path should be
determined. This may be the current date/time, or some point in
the past.
Proposed change:
(b) the time, T, for which the validity of the path should be
determined. This may be the current date/time, or some point in
the past (see the security considerations section about the
limitations of that algorithm in the case of some time in
the past).
Rational: some additional text has been provided in the security
consideration section to warn the user in the case of past validation. Note
that that has strong incidences on our current discussion on past validation
along DPV.
9. Page 62. Current text:
(d) trust anchor information, describing a CA that serves as a
trust anchor for the certification path.
Proposed change:
(d) trust anchor information, valid at the time T, describing a
CA that serves as a trust anchor for the certification path.
Rational: This is only valid at a given time, and thus necessary to say it.
then add:
(5) optionally, the validity period of the trusted public key
(which may be part of a CA self-signed certificate or be defined
independently).
Rational: A CA self-signed certificate, when used, contains a validity
period which allows a nice key rollover using CMP. The equivalent when
self-signed certificates are not used, should allow be permitted.
10. Page 62. Add the following
(h) initial permitted_subtrees, which indicates a name space
within which all subject names in subsequent certificates in a
certification path shall be located. Restrictions may apply to the
subject distinguished name or subject alternative names only when the
specified name form is present. This parameter is either initialized
using the name constraints contained in a CA self-signed certificate
or defined as an independent parameter.
(i) initial excluded_subtrees, which indicates a name space within
which all subject names in subsequent certificates in a certification
path shall not be located. Restrictions may apply to the subject
distinguished name or subject alternative names only when the
specified name form is present. This parameter is either initialized
using the name constraints contained in a CA self-signed certificate
or defined as an independent parameter.
Rational: These variables are used later on, but need to be initialized.
11. Page 75. Current text:
For example, a trusted CA may only be trusted for a particular certificate
policy.
Change proposal:
For example, a trusted CA may only be trusted for a particular certificate
policy or/and for some name space within which all subject names in
subsequent certificates in a certification path shall or shall not be
located.
Rational: name constraints were missing.
12. Page 77. 6.3.3 CRL Processing
As said previously, there should be a story saying that if the certificate
is on hold, then there is still a chance, later on, to know that the
certificate is no more revoked. The text should be amended by the editor to
address that case.
13. Page 81. Section 9. Security Considerations
Current text:
In addition, where a key compromise or CA failure occurs for a
trusted CA, the user will need to modify the information provided to
the path validation routine.
Rational: The case of a key compromission for any key used in the path
validation should be addressed here. Add before that text:
When performing path validation for a time in the past, because
CAs do not publish revocation information beyond the expiration
of a certificate, the path validation algorithm described in this
document (section 6) is only safe as long as the current time is
still within the certificate validity period of any certificate
used in the path validation.
When a path validation succeeds for a current time, and when there
might be a need to verify later on the validity of that path, it is
recommended to time stamp the certification path, the CRLs and/or
the OCSP responses as soon as an initial verification is done.
This will prove that the certificates, CRLs or OCSP responses were
issued before the compromise of the key and will allow for a later
path verification to provide the same result (i.e. pass), otherwise
path validation would provide a different result (i.e. fail).
In order to avoid multiple and successive time stamps, a single
time stamp over the certification path and its associated
revocation information is recommended.
This technique works as long as the key of the TSA is not itself
compromised. Should that case happen, then two time stamps would
provide a protection. Should the key of a TSA likely to be soon
discovered (because of improvements in the cracking of a key or
an algorithm), an additional time stamp over the previous time
stamp obtained before this discovery would still provide a
protection.
14. Page 81. Section 9. Security Considerations
Current text:
If the compromise is
detected, all certificates issued to the CA shall be revoked,
preventing services between its users and users of other CAs.
Rebuilding after such a compromise will be problematic, so CAs are
advised to implement a combination of strong technical measures
(e.g., tamper-resistant cryptographic modules) and appropriate
management procedures (e.g., separation of duties) to avoid such an
incident.
Proposed text:
[If the compromise is
detected, all certificates issued to the CA shall be revoked,
preventing services between its users and users of other CAs.]
In any case, it is advisable to implement a combination of
strong technical measures (e.g., tamper-resistant cryptographic
modules) and appropriate management procedures (e.g., separation
of duties) to avoid such an incident. Should such an incident
nevertheless happen, then two options are possible depending upon
the context of the application:
a) When certificates are used for current time validation,
then the issuing key of the compromised CA shall be changed
and new cross certificates shall be issued to the CA.
b) When certificates are both used for current time and past
time validations, then the former measure still applies,
but in addition time stamping allows to continue to make use
of the already issued (and compromised) certificates, CRLs or
OCSP responses but only from the start of the original
validity period of the corresponding certificate used to verify
the signature of the certificates, CRLs or OCSP responses and
until revocation time of that certificate.
Rational: A rebuilding is not problematic. It is possible to describe how to
recover from such a situation. The additional text describes one way to do
it.
Regards,
Denis