Re: Comments on [MANDATORY cert discovery capabiity]

["Peter Williams" <peter@xxxxxxxxxxxx>]

-----Original Message-----
From: Arsenault, Al W. <awarsen@missi.ncsc.mil>
To: Arsenault, Al W. <awarsen@missi.ncsc.mil>; Peter Williams
<peter@verisign.com>
Cc: Carlisle Adams <carlisle.adams@entrust.com>; 'Charles Moore'
<cmoore@signet.org.au>; 'ietf-pkix@tandem.com' <ietf-pkix@tandem.com>
Date: Friday, September 19, 1997 1:13 PM
Subject: Re: Comments on


>
>Peter Williams wrote:
>
>>We should be clear that PKIX-CMP is not a scheme for managing certificate
>>or CRL distribution. This is the function of part II wherein operational
>>requirements are considered; different solutions are part of
>>the concept of part II, precisly as operational enviornments are
>>so different even on the public internet.
>
>>We have already discussed CRL push a few times. Many parties
>>are working on models/systems for CRL push over microsoft and marimba
>>channels. One expects these underlying transports to become true (versus
>>simulated)  push over time...
>
>>One can imagine IETF standardizing in part II a set of message formats
>>for CRL push which are transport independent, and perhaps profile
>>for transport over modern channel-distribution technologies, much
>>as PKIX-3 specifies information objects, and a number of
>>transport technologies.
>
>
>Then would you ban from PKIX-CMP ALL:
>
>          cert announcement messages
>          revocation announcement messages
>          CRL announcement messages
>          CA Key Update announcement messages
>
>or just unsolicited ones?

I would do as we agreed - operational protocols concerning status go into
PKIX-II, and management (mainly certification) protocols go into PKIX-III
(CMP,
and other bits of a multi-part document). Management of predicatable,
periodic
management operations for CA certs, and even notice concerning a user's
own about-to-expire cert, is reasonable for PKIX-III. This alert/notice
concerning
predictable future-status is reasonable use of "management channels".

I would personally remove from PKIX-III the "alternative directory protocol"
and
certificate/CRL distribution service it evidently forces on the world,
where said messeging is not for the above purposes.

At least make it non-mandatory. One can allow "PKIX-3's online-directory" to
be overloaded on the definition of a "CA" (making
such entities rather more like an permanently online Key management Center,
than
a largely offline X.509 CA)  only where highly centralised admin needs
happen
to prevail in the intended operational environment.


"  4 Certificate/CRL discovery operations: some PKI management
operations result in the publication of certificates or CRLs:
  4.1 certificate publication: Having gone to the trouble of producing
a certificate some means for publishing it is needed.  The "means"
defined in PKIX may involve the messages specified in Sections
3.3.13 - 3.3.16, or may involve other methods (LDAP, for example) as
described in the "Operational Protocols" part of this series (see
[PKIX-OP]).
  4.2 CRL publication: As for certificate publication. "

But thankyou - I had never previously understood the relevance of
these messages to internet clients other than for simple notice/alert of
future status. I had never realised the capability
could be diverted for use to administering centralised access control
(and uses therefore) to keys at remote EEs via its management of compromise
status, and its mandatory status.

>
>If you want them all banned, then how does that affect the functionality of
>PKIX-CMP?  Would PKIX-CMP by itself still be sufficient for its purposes,
or
>would you require PKIX-CMP plus some (sub)set of PKIX-2?

Your labelling of the issue as "banning" clearly deserves a comment about
the
legitimate purpose and scope of PKIX-III - which is
defined to be a cert management service and accompanying protocol
framework. It is surely not a key management service, nor a key recovery
service per se; though it can clearly work in conjunction with such services
particularly when, sometimes, the issued certs are addressing
confidentiality
and data flow control problems. Such problems are not the only problem set,
however; many
CAs in the Internet PKI are quite likely to serve authentication needs only.


We clearly cannot make a cert mgt service which suits every operational
need, those
with rigorous requirements for unifed key/cert management are one group, and
those which
are using persona-fun certificates are another, for example. Nor, from the
style
of the comments received on the issue of previously-mandatory centralised
key generation
support, would the WG seems to favour a general direction to FORCE a link
and mandatory deployed capability between cert management and other related
key-management functions, including online CA-based revocation/comrpomised
alerting.

Certificates and their management service need to roam free to serve purely
authentication-only
purposes, and their CA may well be accessed only via offline transports.

>
>If you just want unsolicited announcements banned (i.e., these messages
>would still be supported for use in specific circumstances during the
>certificate management process), how can that be efficient?  You would be
>duplicating functionality by having the same things - cert announcements,
>CRL announcements, etc. - implemented twice just to support some notion of
>"protocol purity".

Lets deal with this language, and consider internet standards goals.

We have to recall that standards evolve and some parts are used in
one environment and other parts in other enviornments. Its a
toolkit. We are not designing here a national PKI/KMI/KRI. Rather
we are setting standards for an "internet-management-cultured" PK
infrastructure
whose precise use and enviornment is rather unknown. Interworking
is the goal, not uniformity of acess, or some particular quality(s) of
service;
this will evolve over time as residential/organizational/personal/ ...
usage patterns are determined. Many EEs will also use
propiretary or USgovt specified KM I or KRI protocols, also.

We have to recall that we are fundamentally a X.509 group. The model of that
standard
is directory-centric, with offline CAs. One performs certificate management
at the outset
of a relationship with a CA, then one uses a directory to manage
the certs thereafter. This model is built into the semantics; they
are wholly cert-centric servifng to distribute authentication
keys; not key-centric to control key usage by application protocols.

In PKIX architcture, this comes down to a separtion of function -
part III for initialization/registration/certification, and use of Part II
to embrace various kinds of directories (ldap, http, and "real-time"
so far). If one is renewing ones encryption cert, sure the CA should
be able to alert you that your signature key expires next week. (Many
CA-linked directories may well do the same as part of their competitive
value-add.)


yes - it seems that the 3.3.13 - 3.3.16 are attempting to
force PKIX-3 conforming implementations to adopt a
capability for users to use a non-directory mechanism for
certificate and CRL distribution.

I argue  hat this must be optional, for reasons along
many of the same lines that centralised key gen was made
optional. Such interaction with a common cert discovery/alert
services  more naturally happens at layer protocols - e.g. SKIP, S/MIME, SSL
 etc if these implementations do not use directories for the same. SKIPs
interface to a notice databased maintained by the CA concerning
status of CA-cert foo, should happen in the natural SKIP way,
protected via IPSEC. Similarly SSL, etc.

>
>Personally, I'd rather let those who want to support these announcements
>using PKIX-CMP do so, if it simplifies their software architecture.  Then
>use the appropriate PKIX-2 delivery mechanism to distribute these
>announcements.

I am not in major disagreement; however certificate discovery support
should be removed from mandatory requirements. Those entities
which maintain constant online contact with a CA, can use that CA's
PKIX-3 object discovery/announcement sub-protocol to determine (pending)
status of certs and CRLs.

An offline news reader program checking
signature on mails should not be forced to implement such
capability, however, for nothing; a CA which only offers weekly certs
again should not be forced to provide the communications port
for this online element of service. Many CAs will be wholly offline, and
based
on email or floppy transport only for the interaction with the CA.

This is good discussion - we can now seemingly remove another mandatory
service element
designed for an atypical environment, though allow it to be optional.

Anyone disagree with a motion to remove mandatory status from cert discovery
service elements current required for conformance to PKIX-3?

>
>
>               Al Arsenault
>
>     - speaking only for myself
>
>
>

Peter.

Attachment converted: Lutefisk:Peter Williams.vcf (TEXT/R*ch) (0001BEDC)