[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CRL Push over S/Mime
Trevor Freeman wrote:
> I have been asked to write up a mail based distribution for pkix part
> two.
Nice for someone to inform the WG and list about the activity; comments
might
then be introduced to gain as much techncial input and concensus as
possible
before writing.
> I do not understand the reasoning behind using s/mine for
> certificate/crl distribution. The data being distributed is signed. so
>
> its integrity not in question. Its published data so why do we need
> confidentiality.
The purpose is to use S/MIME as one, conveninent, ubiquitous bearer for
the pushed
CRL protocol element (and updating the cert repositories & caches), not
to exploit its
message origination security service. As all conforming S/MIME
implementations can process
such indications, and mailboxes can process such message types
automatically, the property
now exists to automatially, efficiently propogate and cache CRL/cert
information, using X.400 and
bitnet-style distribution lists.
The X.400 elements of Microsoft Exchange should have no particular
problem
with this at the quality end of the message solution space, reliably
propogating CRLs thereby to business users, particularly. Other
MIME-transporting
messaging protocols can also bear the S/MIME message also, of course
through benefits during transport and delivery may be less than with
X.400-style UAs due to the nature of the protocols or their actual
deployments.
I suspect the above is the conventional thinking; perhaps read the PEM
specs
for other backgrounders on the theory of reliable messaging as a
security
infrastructure.
Thinking unconventionally, of course practial solutions also exist when
using S/MIME in massively available products. Just as Authenticode,
when downloading certs in MSIE, invokes a vbscript-scipted control
to actually effect transfer of info on the local UA system according to
local
permission policy , so then a S/MIME protected control/script could
effect the update of
the CRL./cert cache during delivery - the S/MIME signature being
responsible
for security control of such acts, exactly as with Authenticode
signatures currently on java/activeX components delivering personal
certs/CRLs
at enrollment time..
>
>
> If someone has some insight it would be welcome before I finish the
> work.
Hope this helps.
>
>
> Dr Trevor Freeman
> Senior Consultant
> Microsoft Consulting Services
> Microsoft Ltd ECU
> > Tel: UK(+44) 1734 270412
> Fax: UK(+44) 1734 270435
>
> > -----Original Message-----
> > From: Dwight Arthur [SMTP:dwightarthur@mindspring.com]
> > Sent: Thursday, July 03, 1997 5:53 PM
> > To: PKIX List
> > Subject: CRL Push over S/Mime
> >
> > Part Two describes CRL distribution via LDAP and FTP, and also OCSP,
>
> > presumably over HTTP. There is no description of S/Mime as a
> protocol
> > for the distribution of CRL's.
> >
> > If I understood some prior information published to this list by
> > Netscape, Communicator 4 is most effectively able to respond to
> CRL's
> > received via S/Mime, and can even handle the expiration time
> specified
> > for a CRL.
> >
> > Is an enhancement to Part Two to describe CRL distribution over
> S/Mime
> > in the offing?
> >
> > -Dwight << File: Card for Dwight Arthur >>