http://blog.gmane.org/gmane.ietf.x509 hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.x509/32470 <pre> The IESG has received a request from the Public-Key Infrastructure (X.509) WG (pkix) to consider the following document: - 'Enrollment over Secure Transport' &lt;draft-ietf-pkix-est-07.txt&gt; as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf&lt; at &gt;ietf.org mailing lists by 2013-06-24. Exceptionally, comments may be sent to iesg&lt; at &gt;ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple yet functional certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificate(s). It also supports client-</pre> The IESG 2013-06-10T14:45:18 http://comments.gmane.org/gmane.ietf.x509/32444 <pre>The following errata report has been submitted for RFC5912, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5912&amp;eid=3626 -------------------------------------- Type: Technical Reported by: Carl Wallace &lt;carl&lt; at &gt;redhoundsoftware.com&gt; Section: 14 Original Text ------------- -- CRL number extension OID and syntax ext-CRLNumber EXTENSION ::= {SYNTAX INTEGER (0..MAX) IDENTIFIED BY id-ce-cRLNumber } id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } CRLNumber ::= INTEGER (0..MAX) Corrected Text -------------- -- CRL number extension OID and syntax CRLNumber ::= INTEGER (0..MAX) ext-CRLNumber EXTENSION ::= {SYNTAX CRLNumber IDENTIFIED BY id-ce-cRLNumber } id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } Notes ----- The CRLNumber extension was not defined to use the CRLNumber type. It should use the CRLNumber type. Th</pre> RFC Errata System 2013-05-17T10:34:32 http://comments.gmane.org/gmane.ietf.x509/32443 <pre>There were some ideas about whitelisting of certificates. What is the status? Erik _______________________________________________ pkix mailing list pkix&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pkix </pre> Erik Andersen 2013-05-17T10:31:58 http://comments.gmane.org/gmane.ietf.x509/32425 <pre>The following errata report has been submitted for RFC5912, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5912&amp;eid=3623 -------------------------------------- Type: Technical Reported by: Carl Wallace &lt;carl&lt; at &gt;redhoundsoftware.com&gt; Section: 14 Original Text ------------- -- CRL number extension OID and syntax ext-CRLNumber EXTENSION ::= {SYNTAX INTEGER (0..MAX) IDENTIFIED BY id-ce-cRLNumber } id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } CRLNumber ::= INTEGER (0..MAX) Corrected Text -------------- -- CRL number extension OID and syntax CRLNumber ::= INTEGER ext-CRLNumber EXTENSION ::= {SYNTAX CRLNumber IDENTIFIED BY id-ce-cRLNumber } id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 } Notes ----- The CRLNumber extension was not defined to use the CRLNumber type. The CRLNumber type uses MAX to limit the maxi</pre> RFC Errata System 2013-05-16T11:07:51 http://comments.gmane.org/gmane.ietf.x509/32420 <pre>http://news.netcraft.com/archives/2013/05/13/how-certificate-revocation-doesnt-work-in-practice.html The Netcraft folks are well-known for their research and non-flamingness. --Paul Hoffman _______________________________________________ pkix mailing list pkix&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pkix </pre> Paul Hoffman 2013-05-13T17:08:26 http://comments.gmane.org/gmane.ietf.x509/32419 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without</pre> johnsonhammond1< at >hushmail.com 2013-04-27T17:28:58 http://comments.gmane.org/gmane.ietf.x509/32418 <pre>WARNING: contains banned part _______________________________________________ pkix mailing list pkix&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pkix </pre> Tony Rutkowski 2013-04-26T13:39:06 http://comments.gmane.org/gmane.ietf.x509/32405 <pre> Hello, Is a CA obligated to issue a certificate using the subjectName that is in a certificate signing request or can it modify, update, and change the subjectName in the CSR and issue any certificate it wants? Let's say I generate a CSR with "CN=dharkins" but the CA wants my certificate to have "CN=Daniel Harkins" or even "CN=Employee428". Is it allowed to issue such a certificate in response to my signing request or must it use what I sent in the CSR? I was unable to find an answer to this question in any RFC or any standard issued by another SDO. If anyone knows a definitive answer to this and can point to a published standard I would greatly appreciate it. thanks, Dan. _______________________________________________ pkix mailing list pkix&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pkix </pre> Dan Harkins 2013-04-22T21:59:43 http://comments.gmane.org/gmane.ietf.x509/32404 <pre>http://news.netcraft.com/archives/2013/04/22/ocsp-server-performance-in-march-2013.html _______________________________________________ pkix mailing list pkix&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pkix </pre> Paul Hoffman 2013-04-22T21:33:21 http://comments.gmane.org/gmane.ietf.x509/32402 <pre>Hi, Is EV only limited through CAB Forums? On Microsoft CA, there are many ways to implement Enterprise EV certificates. Now my question is, how do they do it if it's the only answer that the browsers acknowledges to its embedded forum members OID only? Hasan T. Emdad _______________________________________________ pkix mailing list pkix&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pkix </pre> Hasan T. Emdad 2013-04-18T15:36:40 http://comments.gmane.org/gmane.ietf.x509/32399 <pre>I'd like to discuss the following before issuing an IETF LC. There's no implied importance based on the order. And, yeah there's a lot of 'em but I think we're there. 0) s1: r/a CA and/a Certification Authority (CA) and Expand acronyms on 1st use in body as well as abstract. Somebody will complain. 1) s1 (and elsewhere): "client device" - is "device" needed? 2) s1: (pedantic alert) r/content types/media types HTTP uses the Content-type header to indicate the media type. Since you already mentioned HTTP headers maybe better to change this to media types. 3) s1: Remove the [[Editor's note ... ]]. They've all been removed except this one. 4) s2.1: OLD: The EST client can request a copy of the current EST CA certificates from the EST server. NEW: The EST client can request a copy of the current EST CA certificate(s) from the EST server. and delete this from the 2nd paragraph, it's redundant: This operation is used to obtain the EST CA certificate(s). 5) s2.6: r/MAC/Media Access </pre> Sean Turner 2013-04-18T01:24:04 http://comments.gmane.org/gmane.ietf.x509/32395 <pre>The following errata report has been submitted for RFC5273, "Certificate Management over CMS (CMC): Transport Protocols". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5273&amp;eid=3593 -------------------------------------- Type: Editorial Reported by: Sean Turner &lt;turners&lt; at &gt;ieca.com&gt; Section: s3 Original Text ------------- "CMC-Request" Corrected Text -------------- "CMC-request" Notes ----- The text before Table 1 indicate the SMIME type parameters is "CMC-Request" but the table uses "CMC-request". I marked this as editorial because I think implementers can figure this out, but I thought I'd submit it anyway Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------</pre> RFC Errata System 2013-04-16T16:34:37 http://comments.gmane.org/gmane.ietf.x509/32392 <pre>The IESG has approved the following document: - 'X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP' (draft-ietf-pkix-rfc2560bis-20.txt) as Proposed Standard This document is the product of the Public-Key Infrastructure (X.509) Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis/ Technical Summary This document specifies a protocol used by a relying party to determine the current status of a digital certificate without requiring the RP to acquire a CRL. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFC 2560 and RFC 6277, and updates RFC 5912. Working Group Summary This draft represents a long WG process that was initiated through publication of "draft-cooper-pkix-rfc2560bis-00.txt" in June 2010. This document represents a complete re-write of the OCSP document, while re</pre> The IESG 2013-04-15T18:16:17 http://comments.gmane.org/gmane.ietf.x509/32390 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP Author(s) : Stefan Santesson Michael Myers Rich Ankney Ambarish Malpani Slava Galperin Carlisle Adams Filename : draft-ietf-pkix-rfc2560bis-20.txt Pages : 44 Date : 2013-04-15 Abstract: This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFC 2560 and RFC 6277, and updates RFC 5912. The IETF datatracker status page for this draft is: https://datatracker.ietf.o</pre> internet-drafts< at >ietf.org 2013-04-15T16:30:23 http://comments.gmane.org/gmane.ietf.x509/32373 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP Author(s) : Stefan Santesson Michael Myers Rich Ankney Ambarish Malpani Slava Galperin Carlisle Adams Filename : draft-ietf-pkix-rfc2560bis-18.txt Pages : 44 Date : 2013-04-11 Abstract: This document specifies a protocol useful in determining the current status of a digital certificate without requiring CRLs. Additional mechanisms addressing PKIX operational requirements are specified in separate documents. This document obsoletes RFC 2560 and RFC 6277, and updates RFC 5912. The IETF datatracker status page for this draft is: https://datatracker.ietf.o</pre> internet-drafts< at >ietf.org 2013-04-12T04:57:11 http://comments.gmane.org/gmane.ietf.x509/32357 <pre>Hi Stefan, I noticed another typo in draft 16. On page 15 Here is the text. 3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage extension and is issued by the CA that issued the certificate in question as stated above." Please note the dangling double quote at the end of the sentence. You may want to remove it before publishing the next draft. Regards -Piyush _______________________________________________ pkix mailing list pkix&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pkix </pre> Piyush Jain 2013-04-09T01:41:40 http://comments.gmane.org/gmane.ietf.x509/32342 <pre>The following errata report has been submitted for RFC5280, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5280&amp;eid=3579 -------------------------------------- Type: Technical Reported by: Timothy J. Miller &lt;tmiller&lt; at &gt;mitre.org&gt; Section: 4.2.1.4 Original Text ------------- certificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation Corrected Text -------------- CertificatePolicies ::= SEQUENCE SIZE (1..MAX) OF PolicyInformation Notes ----- ASN.1 type references must begin with an upper case character. Schema in A.2 is correct. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. ----</pre> RFC Errata System 2013-04-03T13:02:54 http://comments.gmane.org/gmane.ietf.x509/32332 <pre>First bullet in section 1 says - Section 2.2 extends the use of the "revoked" response to allow this response status certificates that has never been issued. Change it to - Section 2.2 extends the use of the "revoked" response for certificates that have not been issued. Or - Section 2.2 extends the use of the "revoked" response for certificate serial numbers that are not associated with any issued certificates. _______________________________________________ pkix mailing list pkix&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pkix </pre> Piyush Jain 2013-04-03T02:06:53 http://comments.gmane.org/gmane.ietf.x509/32315 <pre>Folks, Version 6 of the EST doc has been published. At the Orland meeting we were told that this version would address all of the outstanding comments. So, let's begin the WGLC for EST. The comment period will end on April 17. I will be when the comment period ends so I will defer to Stefan to manage the end of the process, or he can wait until I return on 5/9 and begin sifting through 2-3K messages ... Steve _______________________________________________ pkix mailing list pkix&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pkix </pre> Stephen Kent 2013-04-02T14:19:07 http://comments.gmane.org/gmane.ietf.x509/32306 <pre>Hi list, It seems that every CA that issues an EV certificate today uses a different certificate policy OID to indicate extended validation. Is there a reason why EV OID is not standardized? Thanks -Piyush _______________________________________________ pkix mailing list pkix&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/pkix </pre> Piyush Jain 2013-03-29T23:42:47 http://comments.gmane.org/gmane.ietf.x509/32304 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF. Title : Enrollment over Secure Transport Author(s) : Max Pritikin Peter E. Yee Dan Harkins Filename : draft-ietf-pkix-est-06.txt Pages : 49 Date : 2013-03-29 Abstract: This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple yet functional certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificate(s). It also supports client-generated public/ private key pairs as well as key pairs generated by the CA. The IETF datatracker status page</pre> internet-drafts< at >ietf.org 2013-03-29T20:34:22 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.x509