At 12:10 PM -0400 8/10/07, Stephen Kent wrote:
At least in the X.509 context, we often end to use the term "verify" for signatures, and validate for certs, although we are not absolutely consistent in this usage. RFC 2828 discusses this in the section entitled "validate vs. verify" and I suggest we adopt the suggested usage guidelines from there.
Even without the RFC 2828 definitions, I think it is good to talk
about "verifying" signatures instead of "validating"
signatures.
"begin" may still be problematic, e.g., because one might argue that the beginning of the signature validation process is path discovery. Unfirtunately I don't have a good alternative suggestion right now.
Let's leave it as "begin" until we have a better word.
I think everyone understands it.
Associated data is used to define the scope of the use of the trust anchor for validating signatures. For example, associated data might limit the types of identifiers in certificates that a public key is used to validate, or the types of objects the signatures of which can be verified using a public key.
This sounds good too.
The scope section seems confusing to me:
- Supporting a single trust anchor administrator, such as in a typical
enterprise, who may be administering multiple trust anchors in her domain,
where those trust anchors can be either local or "foreign"
We have not defined "local" or "foreign" so it's hard to understand the importance of the distinction being drawn here.
The bullet works just as well without the last clause. That is,
there is no assumption in the words before it that the trust anchors
are all run by the TAA.
- Supporting multiple trust anchor administrators, such as is typical for home
users
Why do we believe it is common for a home user to need multiple TA administrators?
I would be happy if we swapped "individual" for
"home". If needed, we can add text such as "For
example, they may want their employers and their banks to act as trust
anchor administrators."
- Supporting devices with limited or no user interface that may or may not have connectivity to the Internet
a simple typo fix, but if a deliverable is a TA management protocol, then why do we worry about devices that have no Internet connectivity?
Protocols do not require Internet connectivity. End-to-end email
is a good example of that.
--Paul Hoffman, Director
--VPN Consortium
