Subject: OCSP Current Status - msg#00062

List: ietf.x509

Date: Prev Next Index Thread: Prev Next Index

All,

You should be hearing from IETF soon of an update to the OCSP draft. It
takes into account comments in D.C. regarding extensibility, both in the
request and in the response. Several other tweaks have been made, such as a
more formal BNF specification of request and response syntax. Many thanks
to Rich Ankey of Certco for his contributions to this draft.

Interested parties should review the draft for responsiveness to
requirements and technical completeness in anticipation of a formal Last
Call going in to L.A.

Mike

Was this page helpful?

Thread at a glance:

Previous Message by Date: click to view message preview

Re: Defining Terms w.r.t. Cross Cert...

snip > >However, the point I was trying to make (in the discussion, if not the >text) is that PKIX should use the term "cross-certificate" rather than >"CA-certificate" in its documents precisely to try and diminish/remove >possible confusion (i.e., so that people would be more inclined to put >the result in the cross-certificate attribute than in the cACertificate >attribute). The argument I was making (which I believe we're in violent >agreement on) is that it would not make sense for PKIX to call it a >"CA-certificate" and then encourage people *not* to put it in the >cACertificate attribute. Life seems less error-prone if we simply call >it a cross-certificate and then encourage people to put it in the >cross-certificate attribute... You are right, I do agree with you. Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Attachment converted: Lutefisk:smime.p7s 63 (????/----) (0001EACA)

Next Message by Date: click to view message preview

Re: Defining Terms w.r.t. Cross Cert...

-----Original Message----- From: Trevor Freeman <trevorf@xxxxxxxxxxxxx> To: IETF-PKIX@xxxxxxxxxxxxxxxx <IETF-PKIX@xxxxxxxxxxxxxxxx> Date: Tuesday, 17 February 1998 10:51 Subject: Re: [IETF-PKIX] Defining Terms w.r.t. Cross Cert... >Hi Carlisle, >When I am walking the chain, I do not know the nature of the superior CA >therefore if you logic is followed, I must be prepared to search the >Cross-certificates attribute, then the CA-certificate attribute resulting in >two directory hits in some instances as well as additional complexity of >code. Is it not simpler to just search one attribute of an object with the >certainty of all certificate will be in that attribute, so it would make >sense to select the name of attribute would contains all CA certificates in >which case this would imply using the CA-certificate attribute. Certpath processing depends on the certificate policy, i.e the rules that must be followed. So if I start at the user certificate, I know it will be signed by a CAcertificate, I get this from the Ca Certificate attribute Now I look at the cert policy and know the rules to apply to the path processing. A policy may decied that only hiearchical ( i.e subordination rules will apply, in which case I would look in the CA attribute to find the path ( Xcerts would not apply even if they exist as this is against the policy ) . Now in other cases my policy may allow for Xcerts in which case I look for the cross certificate pair as my policy may require a bialateral arrangement i.e that there exists a forward and reverse certificates or just one way it very difficult to do this with just a CAcertificate) as cross implies direction ( I will agree not impossible, but not something I would not willingly do when their are simpler ways). So I use the symantics and the syntax associated with cross certificate pairs to good use ( that why they exist). I may use CA CACertificate attribute to do certpath navigation, but not to find cross certs or cross cert pairs. What rules I follow are determined by the certificate policy, which is contained within each certificate. So in summary, I dont make arbitary decisions, I follow the certificate policy rules, and I use the available mechanims to help simplify the path processing. I have sent a couple of simple cross certificate defintions to the list with no one disagreeing, but still see this CACertificate line. My last thought was to just to not bother, as a) I realy dont need a on-line cross certificate request mechanism ( numerious peole have outlined why, but then if this is useful I dont disagree with the mechanism being available), b) the market will determine what policies will be acceptable and what solutions meet those policies. We will make use of available mechanisms to meet the different types of policy requirements. The one thing we have learned and it is also evident in this list is that there is no single right way, but some are easier than others. PKIX had an opportunity to assist with clarification of the above issues value add ), but I just see a value subtract and increased confusion. The over loading of the terms CAcertificate ( and all the minor variations cACertificate etc) and now cross certificate are not helpful to anyone, who wants to build and deploy PKIs. We also need to be careful, 12mths ago people thought that self signed root certificates were the basis of any PKI; experience has shown this not to be so. Due to a number of issues cross certificates are seen to be the answer, experience will show that these mechamisms all have their place, but none alone are the universal answer to PKI deployment, scaleability or Trust issues. >We only have two types of entity, CA and End entity. Can we not reflect this >in the directory by CA's using CA-Certificate attribute and end entities use >the user-certificates attribute? >Trevor Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Attachment converted: Lutefisk:smime.p7s 67 (????/----) (0001EACE)

Previous Message by Thread: click to view message preview

PKIX WG Charter Amendment Text

<html><HTML> Hi all, in the December meeting that took place in DC we took a straw pole that resulted in an action item to add timestamping and non-repudiation technologies into the breadth of the PKIX WG charter. To that end Robert Zuccherato and I have come up with this charter that we would like to submit for your approval and commentary - We would like to get some discussion and potentially approval of the additions so that further work on time and timestamping standards can be done within the WG. Here then for your review in the charter text update: ----- BEGINING OF CHARTER TEXT ---- Public-Key Infrastructure (X.509) (PKIX) --------------------------------------------------    Charter  Last Modified: February 13, 1998    Current Status: Active Working Group    Chair(s):      Stephen Kent <kent@xxxxxxx>      Warwick Ford <wford@xxxxxxxxxxxx>    Security Area Director(s):      Jeffrey Schiller  <jis@xxxxxxx>    Security Area Advisor:      Jeffrey Schiller  <jis@xxxxxxx>    Mailing Lists:      General Discussion Email:  ietf-pkix@xxxxxxxxxx      Archive:                           <A HREF="ftp://ftp.tandem.com/pub/ietf-pkix.current">ftp://ftp.tandem.com/pub/ietf-pkix.current</A>      To Subscribe:                    listserv@xxxxxxxxxx          In Body of email                 subscribe <email address> ietf-pkix   Description of Working Group: Many Internet protocols and applications which use the Internet employ public-key technology for security purposes and require a public-key infrastructure (PKI) to securely manage public keys for widely-distributed users or systems.  The X.509 standard constitutes a widely-accepted basis for such an infrastructure, defining data formats and procedures related to distribution of public keys via certificates digitally signed by certification authorities (CAs). For example, RFC 1422 specified the basis of an X.509-based PKI, targeted primarily at satisfying the needs of Internet Privacy Enhanced Mail (PEM).  Since RFC 1422 was issued, application requirements for an Internet PKI have broadened tremendously, and the capabilities of X.509 have advanced with the development of standards defining the X.509 version 3 certificate and version 2 certificate revocation list (CRL). Charter of the Working Group: The charter of the working group will be to develop Internet standards needed to support the use of an X.509-based PKI.  The goal of this Working Group (WG) will be to further facilitate the use of X.509 certificates in applications that make use of the Internet and to promote interoperability between different implementations choosing to make use of X.509 certificates. The resulting PKI is intended to provide a framework, which will support a range of trust/hierarchy environments and a range of usage environments (RFC1422 is an example of one such model). Candidate applications to be served by this PKI include, but are not limited to, PEM, MOSS, GSS-API mechanisms (e.g., SPKM), ipsec protocols, Internet payment protocols, timestamping, and www protocols. This project will not preclude use of non-infrastructural public-key distribution techniques nor of non-X.509 PKIs by such applications.  Efforts will be made to coordinate with the IETF White Pages (X.500/WHOIS++) project. The group will focus on tailoring and profiling the features available in the v3 X.509 certificate to best match the requirements and characteristics of the Internet environment. Other topics to be addressed potentially include: <UL>* Alternatives for CA-to-CA certification links and structures, including guidelines for constraints * Revocation alternatives, including profiling of X.509 v2 CRL extensions * Certificate and CRL distribution options (X.500-based,  non-X.500-based) * Guidelines for policy definition and registration * Administrative protocols and procedures, including certificate generation, revocation notification, cross-certification, and  key-pair updating * Naming and name forms (how entities are identified, e.g., email address, URN, DN, misc.) * Generation of client key pairs by the PKI * Services that support non-repudiation.  This can include sources of credible time data and/or certificate path validation services.</UL> ----- END OF CHARTER TEXT ---- Thanks for your consideration - Todd Glassey (Coastek) and Robert Zuccherato (Entrust)    </HTML> </html>Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Todd S. Glassey Content-Disposition: attachment; filename="vcard.vcf" Attachment converted: Lutefisk:vcard.vcf 15 (TEXT/R*ch) (0001EAC5) Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Attachment converted: Lutefisk:smime.p7s 61 (????/----) (0001EAC6)

Next Message by Thread: click to view message preview

Re: OCSP Current Status

Michael Myers wrote: > > All, > > You should be hearing from IETF soon of an update to the OCSP draft. It > takes into account comments in D.C. regarding extensibility, both in the > request and in the response. Several other tweaks have been made, such as a > more formal BNF specification of request and response syntax. Many thanks > to Rich Ankey of Certco for his contributions to this draft. > > Interested parties should review the draft for responsiveness to > requirements and technical completeness in anticipation of a formal Last > Call going in to L.A. > > Mike The German Digital Signature Law needs an OCSP-like service (provided by a trusted directory service) that allows clients to ask for the validity status of certificates. This status can be inquired at any point in time about any previous point in time, like "what was the status of the certificate at 10:13 on 1/13/97". The additional information -- the time -- can easily added in the OCSP extension field. What is missing to support this feature is an additonal method of identifying a certificate. OCSP uses either a hash over the DN an serial number or the complete certificate. Since certificates contain privacy relevant data, persons can choose not to publish the certificate at all (only providing it with any message they send). A status protocol should thus support "hash of the certificate DER encoding" to allow the access to revocation information only to entities that are having the certificate in question available. Neither issuer and serial (anyone can construct such a hash) nor sending the complete certificate (breaching privacy laws) are acceptable. Any ideas on this? While the hash could be included in the extensions, I feel that it is not a proper place to do so. I would rather like to see this as yet another method for certificate identification. Andreas -- Wissen haelt nicht laenger als Fisch. -- Alfred North Whitehead, Logiker und Philosoph 1861-1947 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Attachment converted: Lutefisk:smime.p7s (????/----) (0001EB7F)

Loading Comments...