|
I will summarize in this email my comments on the draft.
I have finally been able to review the changes that were made to version
04.
Some parts of the revised text are not crystal clear to me.
I am still wondering whether the draft complies with draft-ietf-pkix-ta-mgmt-reqs-04.
On page 11, we have:
3.5. RFC 5280 Support
3.5.1. Functional Requirements
A trust anchor management protocol MUST enable management of trust
anchors that will be used to validate certification paths and CRLs in
accordance with [RFC5280] and [RFC5055]. A trust anchor format MUST
enable the representation of constraints that influence certification
path validation or otherwise establish the scope of usage of the
trust anchor public key. Examples of such constraints are name
constraints, certificate policies, and key usage. The problem is that the current format does not allow a RP or a TAS manager
to add constraints
to a self-signed certificate. This limitation should be
mentioned in the TAMP draft
(or the TAMP draft should be changed).
Since it seems that no change will be made to the draft, I believe this
limitation should be indicated.
I have provided some text below to address this concern.
=====================================================================
Stefan
said:
I think the following text is
confusing to a new reader:
?Some sequence
number generation schemes, e.g., time-based,
do not require maintenance of
state information.?
This is a general design consideration for
designing the protocol but
has nothing to do with security considerations
related to deployment of the specified protocol.
This text seems relevant
only if you provide any security related rationales why such approach
was
not selected. Else, I would simply remove this text and possibly add a
corresponding text
in some other place of the document discussing design
considerations.
In fact, using time-based sequence numbers allow to solve some issues in
case
more than one trust anchor store manager manages a given trust anchor
store.
I have provided some text at the end of this email to address the
problem.
Since parallel management is not mandated, the discussion
can be in the security
considerations section, since it really relates to
security (denial of service in this case).
1. On page 21, the text
says :
?TrustAnchorInfo is intended to
serve as a
minimalist representation of trust
anchor information for scenarios
where storage or bandwidth is
highly constrained?.
Russ,
said: ?I agree that the representation is not minimal.
That
description should be removed".
I
suggest :
?TrustAnchorInfo
does not use a structure derived from RFC 5280.
Since it does not include a
validity field, the validity period
of the trust anchor information is
unspecified. The structure
optionally includes a TrustAnchorTitle with a UTF8String syntax
and
which plays a role similar to the issuer field from a certificate
with a DN
syntax. It may include a specific
element called certPath
to control certificate path validation?.
2. Then
the text says on the same page:
?Implementations are not required
to support all three options.
The
unsupportedTrustAnchorFormat error
code should be indicated when
generating a TAMPError due to
receipt of an unsupported trust anchor
format?.
At
this place, the characteristics of use of these three structures
should be
indicated since they are not identical.
I
propose to add the following text:
?The
functionalities supported by each option are not the same.
Usually
self-signed certificates (supported through the certificate field)
can be
used for several purposes and it is up to relying parties
to decide for
which purpose(s) they should be used. However, when
the certificate choice
is being used, the TrustAnchorChoice structure
does not allow a trust anchor
store manager specifying constraints
nor the purpose (or scope) for which a
self-signed certificate may be used.
On
the contrary, the two other structures are able to support
additional
constraints which may be defined by trust anchor store managers.
When
they are used without additional specific extensions,
the purposes for
which the trust anchor info may be used to verify
certification paths needs
to be locally defined; this means that different
usages for different
trust anchors placed in the same trust anchor
store are not possible either.
One way to have different usages for different
trust anchors without using
specific extensions is to use a different trust
anchor store for every
different usage.
Note
that the Extended Key Usage extension, as defined in RFC 5280
indicates one
or more purposes for which the trust anchor itself may be used.
Thus,
it cannot be used to indicate for which purpose certificates
from paths
terminating to that trust anchor may be used?.
3. On
page 22, there is the following text:
The TAMP Status Query message MUST
be signed. For the query
message
to be valid, the trust anchor
store MUST be an intended recipient of
the query, the sequence number
checking described in Section 6 MUST
be successful when the TAMP
message signer is a trust anchor,
What
does the end of the sentence mean ? A signer is not a trust
anchor.
Please clarify and rephrase.
4. On
page 33, the text says :
« The
TrustAnchorChangeInfo structure or the TBSCertificateChangeInfo
structure is
used to provide the revised configuration of the management
or identity
trust anchor".
The
end of the sentence is unclear ?management or identity trust anchor?
?
Change proposal:
?The TrustAnchorChangeInfo structure or the
TBSCertificateChangeInfo structure
is used to provide the revised
configuration of the tbsCert and the taInfo
structures respectively. As a
consequence, the trust anchor store must make
a difference between the three
options every time one of the structures
is stored or changed?.
5. On
page 55, the text says:
?This balance is achieved by performing sequence
number checking on TAMP messages
that are validated directly using a
trust anchor, and allowing these
checks to be skipped whenever the
TAMP message originator is not
represented by a trust anchor?.
What
does the end of the sentence mean? What is the difference between
a ?TAMP
message originator? that is represented by a trust anchor and
one which is
not? TAMP message originators are trust anchor store managers
that use a
signing key to access the trust anchor store.
Some
explanations may be found, but only on the next page:
?This could be the apex trust
anchor
operational public key or a
management trust anchor public key.
In
the first case, the apex trust
anchor operational public key is used
directly to validate the TAMP
message digital signature. In
the
second case, a management trust
anchor public key is used directly to
validate the TAMP message digital
signature?.
These
explanations should be moved. However, I still have a problem
to understand
how a management trust anchor public key is defined.
A
final question remains: why can checks be skipped ?whenever
the TAMP
message originator is not represented by a trust anchor? ?
6. Then
the text states on the same page:
?Implementations MUST perform
sequence number checking on TAMP
messages that are validated
directly using a trust anchor?
but
then the text states:
?and
MAY perform sequence number checking for TAMP messages validated
using a
certification path?.
Why
is there a difference between the two cases? Please explain and
revise.
7. On
page 64, at the end of the security considerations section,
I propose to add
the following text:
?In the event of loss sequence number values by one
trust anchor store manager,
sequence number state can be restored by
inspecting the most recently
generated TAMP messages, if these messages are
logged.
As
sequence number values are used to detect replay attempts, there are
difficulties
to use concurrently several trust anchor store managers unless
a strong and
continuous synchronization between them is being maintained at
all times.
When
only one trust anchor store manager is being active at a time and in case
of
a failure, a backup trust anchor store manager must use sequence numbers
that are greater than the last ones being used. One way to avoid a
continuous
communication of the last sequence number values being used
between different
trust anchor store managers is to use sequence numbers
built using a date and
time value in the higher bits of the sequence number
values and a random number
in the lower bits. If reasonable time
synchronization is maintained between
the trust anchor store managers, after
a few seconds, the backup trust anchor
store manager should normally be able
to successfully access the trust anchor
stores initially managed by the
master trust anchor store manager?.
Denis
============================================================================
Date
: 2009-11-10, 22:54:41
Sujet
: RE: [pkix] TAMP spec
I
agree this is an unanticipated statement for the security considerations
section and will strike that sentence, which leaves the following as the draft
text:
As
sequence number values are used to detect replay attempts, trust anchor store
managers must take care to maintain their own sequence number state, i.e.,
knowledge of which sequence number to include in the next TAMP message
generated by the trust anchor store manager. Loss of sequence number
state can result in generation of TAMP messages that cannot be processed due
to seqNumFailure. In the event of loss, sequence number state can be
restored by inspecting the most recently generated TAMP message or in
collaboration with a trust anchor store manager who can successfully issue a
TAMPStatusQuery message.
From: Stefan Santesson
[mailto:stefan at aaa-sec.com]
Sent: Wednesday, November 11, 2009 6:39
AM
To: Carl Wallace; denis.pinkas at bull.net; pkix
Subject:
Re: [pkix] TAMP spec
Carl,
I
think the following text is confusing to a new reader:
?Some sequence number generation schemes, e.g.,
time-based, do not require maintenance of state
information.?
This is a general design consideration for
designing the protocol but has nothing to do with security considerations
related to deployment of the specified protocol.
This text seems
relevant only if you provide any security related rationales why such approach
was not selected.
Else, I would simply remove this text and possibly add a
corresponding text in some other place of the document discussing design
considerations.
/Stefan
On 09-11-11 3:23 AM, "Carl
Wallace" <CWallace at cygnacom.com>
wrote:
Some
draft text for security considerations is below. I don?t think we need
text on the possible future extensions. Once we agree on the text below,
I?ll submit a new draft.
As sequence number values are used to
detect replay attempts, trust anchor store managers must take care to maintain
their own sequence number state, i.e., knowledge of which sequence number to
include in the next TAMP message generated by the trust anchor store
manager. Loss of sequence number state can result in generation of TAMP
messages that cannot be processed due to seqNumFailure. In the event of
loss, sequence number state can be restored by inspecting the most recently
generated TAMP message or in collaboration with a trust anchor store manager
who can successfully issue a TAMPStatusQuery message. Some sequence
number generation schemes, e.g., time-based, do not require maintenance of
state information.
From: pkix-bounces at ietf.org [mailto:pkix-bounces at ietf.org] On
Behalf Of Denis Pinkas
Sent: Tuesday, November 10, 2009 7:49
PM
To: pkix
Subject: Re: [pkix] TAMP
spec
Steve,
I still see need
for additional changes to be made to the document.
In particular,
Carl said on october 29:
"I
will add some text to the security considerations section describing the
consequences of losing sequence number state".
The text to cover
this point is not present in version 4.
I also believe
that text to cover the missing functionnalities and possible future evolutions
should be added.
If there is an
agreement on the principle of such an addition, I can propose such a
text.
Denis
----- Message reçu
-----
De
:
pkix-bounces <mailto%20:pkix-bounces at ietf.org>
À : pkix
<mailto%20:pkix at ietf.org>
Date
:
2009-11-10, 07:56:51
Sujet
:
[pkix] TAMP spec
Folks,
The
TAMP WGLC period ended on 10/19. While there have been useful
discussions
beyond that time, it now seems appropriate to consider
this WGLC to be
over.
Based on the messages from Denis, Carl, Russ, and Santosh over
the
period from 10/8-11/3, I see no need for additional changes need to
be made to this document. Additional features and options may be
pursed in a future, extensions
document.
Steve
_______________________________________________
pkix
mailing list
pkix at ietf.org <mailto:%20pkix at ietf.org>
https://www.ietf.org/mailman/listinfo/pkix
_______________________________________________
pkix
mailing list
pkix at ietf.org
https://www.ietf.org/mailman/listinfo/pkix
|