Peter:
In relation to the proposed certificate, procedures for trust evaluation,
and authentication framework specified in ANSI X9.xx-1994, I would
ask two questions:-
(a) given that chain processing controls have been specified, along
with procedures, to allow wholly automated validation of the meaning
of CA certificates, what security service is provided when a digital
signature mechanism on such a CA certificate is positively validated?
Not sure I follow the motivation behind asking this question. The whole
chain-validation procedure is part of the process of gaining an appropriate
level of assurance that an end-user public key belongs to a given subject.
From
the users' perspectives, the security service being provided is, for example,
confidentiality, data origin authentication, or nonrepudiation.
Chain-validation is part of the key-management part of the overall mechanism
which provides that service.
(b) given that confidence in data origin authentication service provided
to a certificate user, upon validating a digital signature attached
to a end-entity certificate, may be a subjective measure by that user of
Subject Attributes, can an end-entity certificate userAuthentication key be use
to support a non-repudiation of origin security service for messages, as
defined in the X.400 Security Model?
Good question. What I think you are pointing out is the absence of a clear
distinction between the meanings of the userAuthentication and nonRepudiation
key usage bits, and you are furthermore suggesting that definition of a clear
distinction may not be an easy task.
I would comment that greater explanation of the semantics of UserKeyUsage
is required, explaining the role and general procedures assumed for userAuthent
and nonRepudiation Key Usages. I would comment that a differentiation is requir
between authenticating the origin of a key (set), and proving (possibly) with
non-repudiation, the origin of a message or other protocol element through
the use of that key in authentication or secure messaging procedures.
Agreed, better explanations of the semantics are needed. What would you
suggest? Are two bits adequate, should there just be one, or are more values
needed? What definitions would you suggest for each?
I would comment finally, that the authentication framework introduced by
this ANSI draft might not be compatible with PEM in a fundamental respect:
for PEM, the compatibility with X.509 1988 is assured, whilst also
binding the communication semantics of all digital signatures used in the
PEM system to provide for non-repudiation of origin security service for
the protected element of service.
I don't follow your suggestion of PEM incompatibility. If PEM were to migrate
to v3 certificates, I think it would be up to the PEM specification to state
whether, for the non-repudiation of origin service, signature key pairs needed
to be flagged for userAuthentication or nonRepudiation or "either is
acceptable".
Regards,
Warwick