[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?
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?
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".
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.
Al Arsenault
- speaking only for myself