Warwick,
Let us take the two questions separately. This discussion of the
issues is general in purpose, as I am not a member of the PEM WG, or of
any ANSI working group. Nor does discussion represent or refer to any
particular project, or design, I may or may not be involved in.
>>(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.
The motivation is to determine the extent of liability for the
authority which issues a CA certificate, and the proofs which are
available to determine that said authority acted in a certain manner.
Considering the threats upon the key distribution mechanism constituted
by chain processing, it is valid to ask whether an authority can
repudiate having issued a given CA certificate. (This issue is related
to determination of liability for statements or implied statements of
trust associated with a CA certificate.)
The question sought to determine whether any such service has been
standardized by the ANSI draft standard.
>>(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.
Considering both inter and intra message threats to the message
handling system, there may be significant value in adding text to
indicate that additional procedures in certificiate issuance are
required to provide protection against the subsequent repudiation of a
party having originated a given message. This include flagging the
purpose of a key issued to a named party as explicitely for repudiation
control addressing intra-message threats versus conventional
authentication of the origin of data addressing inter-message threats.
The explit introduction of the purpose bit removes the burden from
certification policies, and policies of assurance domains, of relating
the quality of key distribution to the quality and nature of the
purposes for which keys are used by users.
(*)Whilst assurance policies of authentication domains do qualify the
degree of confidence which may be held in the authentication of the
origin of data, there should be no ambiguity that these certification
assurances in any way imply that a subsequent service provided through
use a certified key has necessarily any assurance bearing on the use
made of that key to address intra-messaging threats.
Should a CA issued a certificate with the nonRepudiation bit set true,
then external assuranaces can be assumed over and above the assurance
policy(s) of the authentication domain(s) to enable the end-user to
determine whether an intra-message threats have been countered. These
external assurances may be provided by additional mechanisms in the
MHS, or additional procedures used throughout the authentication domain
which protect the key distribution mechanism from attacks on itself.
>
>>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?
>
The questions were formulated to test the conjectures I had concerning
the text. I relate the conjectures above. They will be rather heavy
going for most people, I suspect.
I find that 2 bit are adequate to distinguish the use of a key to be
used in protecting inter, and inter/intra message treats. I have
inferred from your answers that fundamentally the semantics I had
assumed are correct.
Should a service agreement be drawn up where an authority is issuing
certificates in return for payment, then such statements of the
technical meanings which define how information provided is intended to
be used might be used to limit the liability of the issuing party.
I would forsee that any standarization of such definitions by the ANSI
would assist the commercial and competitive use of the technology being
standardized. For such would eliminate the need for
technically-complex service agreements which would provide an
interpretation of the standard. A subscriber would not then be required
to compare different interpretations of the same technical material
when evaluating which CA service to subscribe to in order to obtain an
open provider-based infrastructure for commercial repudiation control.