Re: Certificate Suspension

Mike,

	A good CA revocation policy can specify an authentication mechanism
used to verify that a revocation request is genuine.  The examples you cite
don't exhibit such a mechanism.  I hate to see this justification for the
suspension facility, but I'm beyond complaining about this CRL feature.

Steve

Monthly reminder (IETF-PKIX list)

Welcome to the ietf-pkix mailing list!

If you ever want to remove yourself from this mailing list, 
send the following command in email to "listserv <at> tandem.com"
(NOT ietf-pkix <at> tandem.com):

    unsubscribe <your e-mail-id> ietf-pkix

Here's the general information for the list you've subscribed to, in
case you don't already have it:

Welcome to the ietf-pkix list. This list is intended to discuss
matters directly related to  develop Internet standards needed to
support an X.509-based public key infrastructure (PKI). The resulting
PKI is intended to provide a framework which will support a range of
trust/hierarchy environments and a range of usage environments.

If you have any questions about this interest group, you can contact 

                Warwick Ford at wford <at> verisign.com  
                             or 
                Jean Pawluk at pawluk_jean <at> tandem.com.

If you have any questions about this list service in general, you
can contact postmaster <at> tandem.com.

Re: Comments on [MANDATORY cert discovery capabiity]

Peter Williams wrote:
> 

[snip]

> Im imagining in a Microsoft implementation of this PKIInformation exchange
> in which  the activeX enrollment control, which implements the
> more elaborate B.x profiles using RSA, would be supplied to the EE in response
> to
> PKInformation object {ms 1}. Where the CA is not a activeX
> CA (i.e. it sends an error msg), then that same browser needs to fall
> back to non-activeX mechanisms by syncing on initialization information they
> can agree on (i.e. that which the CA optionally provides) and using a
> barebones PKIX-3 minimal, default implementation with DSA cipherSuites, say.
> 
> (Take this example figuratively, only.)

Interesting thought, though.  Personally, I couldn't imagine the
circumstances under which I'd accept an ActiveX control that wanted to
help me do *anything* with a cert.  Boy, talking about opening one's
kimono . . . wanna make a copy of my private key(s) while your here? 
PKIs are all about trust and the ActiveX security model is essentially: 
"Trust me on this."  Sorry, I'm not quite there yet.  
--

-- 
/*
 *  George Capehart     email:  gwc <at> vnet.net     phone:  +1 704.866.9151
 *
 *  PGP ID:  George W. Capehart <gwc <at> vnet.net>
 */

AuthorityInfoAccess

The ASN.1 for this extension is different between the text and the ASN.1
module in Appendix A.  Which is correct?

Also note the ASN.1 in the text is not syntactically correct; it should be:

AuthorityInfoAccessSyntax  ::=  
	SEQUENCE SIZE (1..MAX) OF AccessDescription

AccessDescription  ::=  SEQUENCE {
    accessMethod          OBJECT IDENTIFIER,
    accessLocation        GeneralName  }

Regards,
Rich

Re: Last Call & idea for OCSP

> (draft-ietf-pkix-ipki2opp-03.txt) is now under consideration and I've seen
> no substantial comments on it. The FTP and HTTP portion,
> (draft-ietf-pkix-opp-ftp-http-00.txt), is also posted, and the only
> comments I've seen there are relatively minor ones re choice of MIME
> context types.  I'd like to move forward on this one as well.

And the OCSP protocol?

This may be an idea for that protocol, so the CA doesn't have
to sign each answer separately (which takes quite some time):

- The CA divides its certs in groups of say 100 or 500
- When an OCSP_query for a cert C comes in:
  * If the cert is not valid (revoked, expired, ...)
    the CA replies with an ordinary OCSP-response.
  * If the cert is valid, the CA makes a list of 
    all valid certs that are in the same group as cert C.
    The CA then signs this list together with the current
    time and sends it to the requestor. That one must look
    for his cert C in the list to assure C is valid.

If another OSCP-query for a valid cert in the same group 
as C comes in, within say a minute, the CA can simply
send the same message as for cert C without having to
sign anything.

(This ressembles a bit the CRL functionality but CRL's
may be much larger then this here.)

(It's all based on Micalli's paper on the previous 

Re: PKIX-2 http

Peter Williams wrote:
> 
> We do need to agree the mime type for returning an http resource,
> still.
> 
> I note that the introduction also allows the http mechanism to be used
> for pushing the cert/CRL to the directory. Perhaps its best
> that the objects we are pulling/pushing are indeed simply
> regarded as files. When pulling a .crt file the object
> is labelled application/octet-string. When pushing files,
> the file objects are transferred in a classical http push operation's
> multipart mime type.
> 

Most HTTP clients that I know about use the mime type to
dispatch to type-specific handling code.  Using a generic
mime type like application/octet-string precludes this.

For certificates and CRLs browsers do and will likely continue
to use MIME types that indicate both the type and often
an application-specific usage.

Examples are:

application/x-x509-user-cert
application/x-x509-ca-cert

 
--

-- 
Anil R. Gangolli

unsubscribeStatus: