RE: PKCS#7 in PKIX-3

[Peter Williams <peter@xxxxxxxxxxxx>]

lets distinguish in the document two threat environments:

(a) internal threats to the reliability of the certification system due to 
poor message handling
(b) external threats to message communication affecting reliably auditable
release, transport and  auditable message delivery between distributed elements of
the PKIX-3 agents

(a) is countered by existing inband protection mechanism which support integrity
and possibly confidentiality-based access control.

(b) is countered by external protection mechanisms whose
use (and possible generic reliance upon) is signalled by the PKIX-3 message

This suggests that (i) PKIX-3 does not inherently change (the certification
system and flows modelled in the PKIX-3 continues to resist the threats due to
unreliable handling by end-points) as provided for by the inband protection
mechanisms (ii) PKIX-3 mesage formats have an oid field, which identifies
which external protection mechanism was used by an orignator to protect
the release, transport and delivery of the message identified by msgId.

I would expect that the PKIX-3 message would NOT be responsible
for any end-end negotiation of, or specification of required capabilities of the
external channels/controls (IPSEC would have to know how to agree algoirhtms, modes,
services etc; likewise PKCS7 profiled for PKIX-3 protection, etc) Where a PKIX-3 access
port provides for external protection models, the prevailing security policy text for the certification
system (PKIX-3) should be responsible for stating the reliance upon the particular
exernall security service, and detail how such events shall affect PKIX-3 handling

The above sugegstion would suggest a syntax change to accommodate the OID,
and specification of handling procedures for originator(s) and recipients for that
element of service.

The communication to a relying party of a cert that some std PKI policy was
in effect (using the std extension profiled in PKIX-1)  might be qualified by the fact
that the certiifcation system used, in actual fact, external
protection mechansm "foo" Such type of qualifier values are
inherently local and exist for handling by the application to instrument
reliance upon the cert based on evaulation of the id of that exernal protection
process/control-system. A std qualifier might thus be formulated to satisfy this
requirement. its qyntax might thus be only an organizationally-issued object
identifier serving to discriminate amongnst highly localised external control systems.

(one shoudl remember thath reliance upon a qualifier, to accept a policy, is
an application entity decision, not a requirement of the X.509 std cert evaluation algorithm.
Reliance policies for applications which choose to ignore the list of delivered
qualifiers, are free to do so, as always.

Peter. 


----------
From: 	Stephen Farrell
Sent: 	Monday, January 06, 1997 9:02 AM
To: 	ietf-pkix@tandem.com
Subject: 	RE: PKCS#7 in PKIX-3


Hi All,

Given that we want to get another issue of PKIX-3 produced this month, I need
to decide what to write about protection bits this week.

I propose the following:

1. We keep the current protection bits definition and add text mandating
   support for these for some specific algorithm(s). That is,
   conforming implementations must be able to handle PKI messages which 
   are protected using the specified algorithm(s) with the bits carried in 
   the protectionBits field.

2. We add text highlighting the fact that, where available, any other 
   (external) protection mechamism (e.g. S/MIME) may equally be used to 
   protect PKI messages. (Probably the current text gives the impression
   that omitting the protection bits means that there is no protection.)

In short, we mandate the ability to use the protection bits but
do not mandate that every (or indeed, any) protected PKI message use the 
protection bits.

The above allows us to produce a specificiation which supports interop (at
least at the level of message protection) between any pair of implementations 
but which also leaves open the question as to what protection mechanisms are 
suitable for a given environment.

In the absence of further discussion (optimism:-) this is what I'll 
put in the next draft.

Regards,
Stephen.

-- 
==========================================================================
Stephen FARRELL.......................................tel: +353-1-676 9089
Software and Systems Engineering Ltd..................fax: +353-1-676 7984
Fitzwilliam Court............................email: stephen.farrell@sse.ie
Leeson Close.....X.400: /c=ie/a=eirmail400/p=sse/o=sse/s=farrell/g=stephen 
Dublin 2...........................................www: http://www.sse.ie/
IRELAND................................................"A Siemens Company"
==========================================================================