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”.
[CW]
I do not agree with Russ that this is not a minimal representation. I agree it
need not be minimal since it can contain various information. In any case, I
prefer the existing text, which is historically accurate – the structure
was in fact designed to enable _expression_ representations as minimal as key and
name.
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.
[CW] The differences between these structures are discussed in
TAF.
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.
[CW] There is text in TAF that highlights the fact that no
additional constraints can be associate with the certificate option but can be with
TBSCert and TAI.
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”.
[CW] I don’t see any reason note this in TAMP.
It’s more would be a good fit for an EKU constraints draft, were one to
be written.
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.
[CW] See section 6 for a clarification. As you
observe below, sequence number processing is not required when a TAMP message
is validated using a certificate instead of a trust anchor.
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” ?
[CW] These terms are defined earlier in the draft.
The point here is that apex TAs cannot be changed with this structure.
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” ?
[CW] See the first paragraph of section 6. The primary
reason is that it’s easier to know when to delete sequence number values
for TAs, since they are resident in the store. It’s harder for
certificate holders since expiration or deletion may occur independent of the
store.
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.
[CW] See above.
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.
[CW] OK. I will add “if these messages are logged”
to the previous proposed text.
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.
[CW] As noted in previous messages, this is not true. The only
case where this would be true is where the two TA managers are sharing a
private key and there is no need to support this scenario.
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”.
[CW] No
synchronization is required if they use different private keys.
Denis
============================================================================