http://blog.gmane.org/gmane.ietf.keyprov hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.ietf.keyprov/1021 <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 any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. _______________________________________________ KEYPROV mailing list KEYPROV&lt; at &gt;ietf.org https://www.ietf.org/mailman/listinfo/keyprov </pre> johnsonhammond1-revL73yDgGBWk0Htik3J/w< at >public.gmane.org 2013-04-27T17:45:16 http://comments.gmane.org/gmane.ietf.keyprov/1020 <pre>Hi all, in 2011 we published the TOTP with RFC 6238 http://tools.ietf.org/html/rfc6238 TOTP normatively references HOTP (RFC 4226, see http://www.ietf.org/rfc/rfc4226.txt). It turns out that HOTP has a few errata pending (see http://www.rfc-editor.org/errata_search.php?rfc=4226&amp;rec_status=2&amp;presentation=records). Is anyone in this group interested to discuss these errata issues with me? It would also be interesting to hear what people had implemented. Please drop me a mail. Ciao Hannes </pre> Hannes Tschofenig 2013-03-16T15:25:37 http://comments.gmane.org/gmane.ietf.keyprov/1019 <pre>http://webpki.org/papers/PKI/certenroll-features.pdf It is currently in beta state for Android. The specs are here: http://webpki.org/auth-token-4-the-cloud.html Anders </pre> Anders Rundgren 2013-01-02T20:24:02 http://comments.gmane.org/gmane.ietf.keyprov/1014 <pre> The following errata report has been submitted for RFC6030, "Portable Symmetric Key Container (PSKC)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6030&amp;eid=3418 -------------------------------------- Type: Technical Reported by: Simon Josefsson &lt;simon-RTwAkxXyIg6Ei8DpZVb4nw&lt; at &gt;public.gmane.org&gt; Section: 7 and 11 Original Text ------------- Section 7: &lt;Signature&gt; Section 11: &lt;xs:element name="Signature" type="ds:SignatureType" minOccurs="0"/&gt; Corrected Text -------------- Section 7: &lt;ds:Signature&gt; Section 11: &lt;xs:element ref="ds:Signature" minOccurs="0"/&gt; Notes ----- It seems the Signature element is in the wrong namespace, making PSKC incompatible with the XMLDsig specification. There is a thread on this on the XMLSec mailing list: http://thread.gmane.org/gmane.text.xml.xmlsec/4178 Both Aleksey Sanin (author of the XMLSec library) and G. Ken Holman (XML expert) appear to believe this is an error in the XML schema for PSKC: http://thread.gmane.org/gmane.text.xml.xmlsec/4178/focus=4181 http://thread.gmane.org/gmane.text.xml.xmlsec/4178/focus=4185 This was brought up on the keyprov mailing list: http://thread.gmane.org/gmane.ietf.keyprov/1011 /Simon 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. -------------------------------------- RFC6030 (draft-ietf-keyprov-pskc-09) -------------------------------------- Title : Portable Symmetric Key Container (PSKC) Publication Date : October 2010 Author(s) : P. Hoyer, M. Pei, S. Machani Category : PROPOSED STANDARD Source : Provisioning of Symmetric Keys Area : Security Stream : IETF Verifying Party : IESG </pre> RFC Errata System 2012-11-27T04:41:25 http://comments.gmane.org/gmane.ietf.keyprov/1011 <pre>All, I have implemented support for XMLDsig protected PSKC and ran into an issue with the XML Schema for PSKC. It seems the Signature element is in the wrong namespace, making it incompatible with the XMLDsig specification. There is a thread on this on the XMLSec mailing list: http://thread.gmane.org/gmane.text.xml.xmlsec/4178 Both Aleksey Sanin (author of the XMLSec library) and G. Ken Holman (XML expert) appear to believe this is an error in the schema: http://thread.gmane.org/gmane.text.xml.xmlsec/4178/focus=4181 http://thread.gmane.org/gmane.text.xml.xmlsec/4178/focus=4185 The fix appears to be simple, but before filing an RFC errata for this I'd thought I should bring this up in case anyone wants to comment. Section 7: OLD: &lt;Signature&gt; NEW: &lt;ds:Signature&gt; OLD: &lt;/Signature&gt; NEW: &lt;/ds:Signature&gt; Section 11: OLD: &lt;xs:element name="Signature" type="ds:SignatureType" minOccurs="0"/&gt; NEW: &lt;xs:element ref="ds:Signature" minOccurs="0"&gt; /Simon </pre> Simon Josefsson 2012-10-16T08:07:14 http://comments.gmane.org/gmane.ietf.keyprov/1010 <pre>Hi all, I wanted to let you know that I have just released a (partial) PSKC implementation as free software in OATH Toolkit: http://www.nongnu.org/oath-toolkit/ The tutorial is a good introduction to the functionality: http://www.nongnu.org/oath-toolkit/libpskc-api/pskc-tutorial-pskctool.html http://www.nongnu.org/oath-toolkit/libpskc-api/pskc-tutorial-quickstart.html If anyone is interested in interop testing, please talk to me offlist. /Simon </pre> Simon Josefsson 2012-10-11T18:22:29 http://comments.gmane.org/gmane.ietf.keyprov/1009 <pre> The following errata report has been submitted for RFC6030, "Portable Symmetric Key Container (PSKC)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6030&amp;eid=3369 -------------------------------------- Type: Technical Reported by: Simon Josefsson &lt;simon-RTwAkxXyIg6Ei8DpZVb4nw&lt; at &gt;public.gmane.org&gt; Section: 4.3.1 Original Text ------------- &lt;Manufacturer&gt;: This element indicates the manufacturer of the device. Values for the &lt;Manufacturer&gt; element MUST be taken from either [OATHMAN] prefixes (i.e., the left column) or from the IANA Private Enterprise Number Registry [IANAPENREG], using the Organization value. When the value is taken from [OATHMAN], "oath." MUST be prepended to the value (e.g., "oath.&lt;prefix value from [OATHMAN]&gt;"). When the value is taken from [IANAPENREG], "iana." MUST be prepended to the value (e.g., "iana.&lt;Organization value from [IANAPENREG]&gt;"). Corrected Text -------------- &lt;Manufacturer&gt;: This element indicates the manufacturer of the device. Values for the &lt;Manufacturer&gt; element MAY be taken from either [OATHMAN] prefixes (i.e., the left column) or from the IANA Private Enterprise Number Registry [IANAPENREG], using the Organization value. When the value is taken from [OATHMAN], "oath." MUST be prepended to the value (e.g., "oath.&lt;prefix value from [OATHMAN]&gt;"). When the value is taken from [IANAPENREG], "iana." MUST be prepended to the value (e.g., "iana.&lt;Organization value from [IANAPENREG]&gt;"). Notes ----- The only thing changed is relaxing MUST to MAY. The requirement that manufacturer strings begin with "oath." and "iana." is often ignored by implementations/deployments. Further, none of the examples throughout the document conform to the syntax. While we could regard these as implementation/deployment and editorial document bugs, I would argue that we could just as well relax the technical requirement because there appears to be no harm in allowing free-form text. This is what people appear to be using out there already. Examples of non-conforming &lt;Manufacturer&gt; fields out there: http://tools.ietf.org/html/draft-hoyer-keyprov-pskc-algorithm-profiles-01 http://download.gooze.eu/otp/seeds/20120919-test001-4282.xml 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. -------------------------------------- RFC6030 (draft-ietf-keyprov-pskc-09) -------------------------------------- Title : Portable Symmetric Key Container (PSKC) Publication Date : October 2010 Author(s) : P. Hoyer, M. Pei, S. Machani Category : PROPOSED STANDARD Source : Provisioning of Symmetric Keys Area : Security Stream : IETF Verifying Party : IESG </pre> RFC Errata System 2012-10-03T07:47:27 http://comments.gmane.org/gmane.ietf.keyprov/1008 <pre> The following errata report has been submitted for RFC6030, "Portable Symmetric Key Container (PSKC)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6030&amp;eid=3364 -------------------------------------- Type: Editorial Reported by: Simon Josefsson &lt;simon-RTwAkxXyIg6Ei8DpZVb4nw&lt; at &gt;public.gmane.org&gt; Section: 3 Original Text ------------- ---------------- ---------------- | KeyPackage | 0..1| DeviceInfo | |--------------|--------|--------------| | |-- | SerialNumber | ---------------- | | Manufacturer | | | | .... | | | ---------------- Corrected Text -------------- ---------------- ---------------- | KeyPackage | 0..1| DeviceInfo | |--------------|--------|--------------| | |-- | SerialNo | ---------------- | | Manufacturer | | | | .... | | | ---------------- Notes ----- Figure 1 mentions a DeviceInfo field called "SerialNumber" however it should be "SerialNo". 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. -------------------------------------- RFC6030 (draft-ietf-keyprov-pskc-09) -------------------------------------- Title : Portable Symmetric Key Container (PSKC) Publication Date : October 2010 Author(s) : P. Hoyer, M. Pei, S. Machani Category : PROPOSED STANDARD Source : Provisioning of Symmetric Keys Area : Security Stream : IETF Verifying Party : IESG </pre> RFC Errata System 2012-09-25T22:55:23 http://comments.gmane.org/gmane.ietf.keyprov/1001 <pre> The following errata report has been submitted for RFC6063, "Dynamic Symmetric Key Provisioning Protocol (DSKPP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6063&amp;eid=2999 -------------------------------------- Type: Editorial Reported by: Gareth Richards &lt;gareth.richards-1ip3tSrymgM&lt; at &gt;public.gmane.org&gt; Section: 4.2.4 Original Text ------------- DSKPP Client DSKPP Server ------------ ------------ E(K,R_C), AD ---&gt; Corrected Text -------------- DSKPP Client DSKPP Server ------------ ------------ E(K,R_C), [AD] ---&gt; Notes ----- The AD is carried in the &lt;KeyProvClientHello&gt; if sent as a result of a trigger and so is optional in the &lt;ekyProvClientNonce&gt;. 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. -------------------------------------- RFC6063 (draft-ietf-keyprov-dskpp-14) -------------------------------------- Title : Dynamic Symmetric Key Provisioning Protocol (DSKPP) Publication Date : December 2010 Author(s) : A. Doherty, M. Pei, S. Machani, M. Nystrom Category : PROPOSED STANDARD Source : Provisioning of Symmetric Keys Area : Security Stream : IETF Verifying Party : IESG </pre> RFC Errata System 2011-10-17T16:39:26 http://comments.gmane.org/gmane.ietf.keyprov/1000 <pre>http://webpki.org/papers/keygen2/sks-keygen2-exec-level-presentation.pdf Unlike the original KEYPROV effort this scheme is NOT a protocol, it is a complete architecture. This is how Apple would do it: create all the software AND hardware needed for a pleasant "end user experience". </pre> Anders Rundgren 2011-10-08T09:28:37 http://comments.gmane.org/gmane.ietf.keyprov/999 <pre> The following errata report has been submitted for RFC6063, "Dynamic Symmetric Key Provisioning Protocol (DSKPP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6063&amp;eid=2948 -------------------------------------- Type: Technical Reported by: Sean Turner &lt;turners-52zIA6KkH5U&lt; at &gt;public.gmane.org&gt; Section: 12.2 Original Text ------------- URI: urn:ietf:params:xml:ns:keyprov:dskpp Corrected Text -------------- URI: urn:ietf:params:xml:schema:keyprov:dskpp Notes ----- Section 12.2 is the registration for the schema not the namespace, which is in Section 12.1. The URI for the schema ought to point to :schema: and not :ns:. It's in the IANA registry it just needs to be updated here. 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. -------------------------------------- RFC6063 (draft-ietf-keyprov-dskpp-14) -------------------------------------- Title : Dynamic Symmetric Key Provisioning Protocol (DSKPP) Publication Date : December 2010 Author(s) : A. Doherty, M. Pei, S. Machani, M. Nystrom Category : PROPOSED STANDARD Source : Provisioning of Symmetric Keys Area : Security Stream : IETF Verifying Party : IESG </pre> RFC Errata System 2011-08-28T15:25:59 http://comments.gmane.org/gmane.ietf.keyprov/998 <pre>There were some discussions off-list regarding continuations of this WG. After researching this space thoroughly, I believe it is fair to say that this topic doesn't lend itself to standardization because vendor representatives are not allowed to suggest features without going through the legal department which makes the process much too slow. However, the biggest problem is the zero buy-in from the token vendors who basically are against all attempts to commoditize tokens. Even if you have the most recent Windows server and clients, you can't provision tokens without also buying a $25 000 Forefront Identity Manager system as well as hiring really pricey consultants. Apple will be the party that finally get the provisioning ball running! Particularly in phones. Anders </pre> Anders Rundgren 2011-08-10T22:19:32 http://comments.gmane.org/gmane.ietf.keyprov/997 <pre>F.Y.I. As some of you know I'm since way back working with a "TPMish" token and associated provisioning protocol that is intended to support mass-markets like: http://www.google.com/wallet There are strong motives for innovation in this space since the state of credential provisioning is technically at least 10 years behind the rest of mobile/PC ecosystem: http://webpki.org/papers/keygen2/KG-vs-KG2.pdf Anyway, the starting point was addressing the high-value market where strong authentication is already in use and where privacy aspects (w.r.t. to device identity NB), are secondary. In fact, the original E2ES (End-to-End Security) scheme tries to emulate the methods used for card issuance while moving the "production" out on the web. Since the most important thing of all for a standard-to-be, namely adoption, could be hampered by a scheme leaking device identity (during provisioning), I have recently upgraded the system to support a fully anonymous provisioning mode. Because anonymous relations probably do not constitute of high-value, elaborate methods like DAA (Direct Anonymous Attestation), were (after careful consideration), rejected as they could stifle acceptance in spite of their merits. It seems that anonymity has more applications in three-party relations like payments and "I'm over 18" scenarios. In the revised scheme the issuer requests a specific mode and it is the user that in the case of E2ES mode will have to decide if he/she wants to share device identity with the issuer. Somewhat surprising the PEP (Privacy Enabled Provisioning) mode affected less than 1% of the code in the token as well as in the protocol. - Anders http://webpki.org/auth-token-4-the-cloud.html </pre> Anders Rundgren 2011-06-02T08:06:16 http://comments.gmane.org/gmane.ietf.keyprov/996 <pre> The following errata report has been submitted for RFC6031, "Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6031&amp;eid=2760 -------------------------------------- Type: Technical Reported by: Sean Turner &lt;turners-52zIA6KkH5U&lt; at &gt;public.gmane.org&gt; Section: 3.2.7 &amp; A.2 Original Text ------------- PSKCAlgorithmParameters ::= CHOICE { suite UTF8String, challengeFormat [0] ChallengeFormat, responseFormat [1] ResponseFormat, ... } Corrected Text -------------- PSKCAlgorithmParameters ::= SEQUENCE { suite UTF8String, challengeFormat [0] ChallengeFormat, responseFormat [1] ResponseFormat, ... } Notes ----- This aligns with the errata on RFC 6030, which is where the syntax for this attribute comes from. The errata can be found here http://www.rfc-editor.org/errata_search.php?rfc=6030&amp;eid=2759 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. -------------------------------------- RFC6031 (draft-ietf-keyprov-symmetrickeyformat-11) -------------------------------------- Title : Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type Publication Date : December 2010 Author(s) : S. Turner, R. Housley Category : PROPOSED STANDARD Source : Provisioning of Symmetric Keys Area : Security Stream : IETF Verifying Party : IESG </pre> RFC Errata System 2011-03-31T14:31:02 http://comments.gmane.org/gmane.ietf.keyprov/995 <pre> The following errata report has been submitted for RFC6030, "Portable Symmetric Key Container (PSKC)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6030&amp;eid=2759 -------------------------------------- Type: Technical Reported by: Philip Hoyer &lt;phoyer-AGozWa3SCxNa+Cujyj6rOQC/G2K4zDHf&lt; at &gt;public.gmane.org&gt; Section: 11 Original Text ------------- &lt;xs:complexType name="AlgorithmParametersType"&gt; &lt;xs:choice&gt; Hoyer, et al. Standards Track [Page 42] RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 &lt;xs:element name="Suite" type="xs:string" minOccurs="0"/&gt; &lt;xs:element name="ChallengeFormat" minOccurs="0"&gt; &lt;xs:complexType&gt; &lt;xs:attribute name="Encoding" type="pskc:ValueFormatType" use="required"/&gt; &lt;xs:attribute name="Min" type="xs:unsignedInt" use="required"/&gt; &lt;xs:attribute name="Max" type="xs:unsignedInt" use="required"/&gt; &lt;xs:attribute name="CheckDigits" type="xs:boolean" default="false"/&gt; &lt;/xs:complexType&gt; &lt;/xs:element&gt; &lt;xs:element name="ResponseFormat" minOccurs="0"&gt; &lt;xs:complexType&gt; &lt;xs:attribute name="Encoding" type="pskc:ValueFormatType" use="required"/&gt; &lt;xs:attribute name="Length" type="xs:unsignedInt" use="required"/&gt; &lt;xs:attribute name="CheckDigits" type="xs:boolean" default="false"/&gt; &lt;/xs:complexType&gt; &lt;/xs:element&gt; &lt;xs:element name="Extensions" type="pskc:ExtensionsType" minOccurs="0" maxOccurs="unbounded"/&gt; &lt;/xs:choice&gt; &lt;/xs:complexType&gt; Corrected Text -------------- &lt;xs:complexType name="AlgorithmParametersType"&gt; &lt;xs:sequence&gt; Hoyer, et al. Standards Track [Page 42] RFC 6030 Portable Symmetric Key Container (PSKC) October 2010 &lt;xs:element name="Suite" type="xs:string" minOccurs="0"/&gt; &lt;xs:element name="ChallengeFormat" minOccurs="0"&gt; &lt;xs:complexType&gt; &lt;xs:attribute name="Encoding" type="pskc:ValueFormatType" use="required"/&gt; &lt;xs:attribute name="Min" type="xs:unsignedInt" use="required"/&gt; &lt;xs:attribute name="Max" type="xs:unsignedInt" use="required"/&gt; &lt;xs:attribute name="CheckDigits" type="xs:boolean" default="false"/&gt; &lt;/xs:complexType&gt; &lt;/xs:element&gt; &lt;xs:element name="ResponseFormat" minOccurs="0"&gt; &lt;xs:complexType&gt; &lt;xs:attribute name="Encoding" type="pskc:ValueFormatType" use="required"/&gt; &lt;xs:attribute name="Length" type="xs:unsignedInt" use="required"/&gt; &lt;xs:attribute name="CheckDigits" type="xs:boolean" default="false"/&gt; &lt;/xs:complexType&gt; &lt;/xs:element&gt; &lt;xs:element name="Extensions" type="pskc:ExtensionsType" minOccurs="0" maxOccurs="unbounded"/&gt; &lt;/xs:sequence&gt; &lt;/xs:complexType&gt; Notes ----- The AlgorithmParameter should have a sequqnce of subelements not a choice as for Challenge/Response algorithms it MUST be possible to define both the ChallengeFormat and the Response Format at the same time. Currently the schema uses &lt;xs:choice&gt; which allows either &lt;ChallengeFormat&gt; or &lt;ResponseFormat&gt; but not both. This correction will bring it in line with intended description in Section 4.3.4 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. -------------------------------------- RFC6030 (draft-ietf-keyprov-pskc-09) -------------------------------------- Title : Portable Symmetric Key Container (PSKC) Publication Date : October 2010 Author(s) : P. Hoyer, M. Pei, S. Machani Category : PROPOSED STANDARD Source : Provisioning of Symmetric Keys Area : Security Stream : IETF Verifying Party : IESG </pre> RFC Errata System 2011-03-30T13:17:16 http://comments.gmane.org/gmane.ietf.keyprov/994 <pre> -----Original Message----- From: Internet-Draft-EgrivxUAwEY&lt; at &gt;public.gmane.org [mailto:Internet-Draft-EgrivxUAwEY&lt; at &gt;public.gmane.org] Sent: Thursday, February 24, 2011 6:00 PM To: smachani-+/OggRDFqlVt1OO0OYaSVA&lt; at &gt;public.gmane.org; Pei, Mingliang; johan.rydell-fOKtku6JJ0RWk0Htik3J/w&lt; at &gt;public.gmane.org; draft-mraihi-totp-timebased-nZLwadvX8BDR74oF6e/6QQ&lt; at &gt;public.gmane.org; Hannes.Tschofenig-hi6Y0CQ0nG0&lt; at &gt;public.gmane.org; turners-52zIA6KkH5U&lt; at &gt;public.gmane.org; dromasca-gc/exJtvodwAvxtiuMwx3w&lt; at &gt;public.gmane.org; alexey.melnikov-XZk+60lJk0kAvxtiuMwx3w&lt; at &gt;public.gmane.org Subject: New Version Notification - draft-mraihi-totp-timebased-08.txt New version (-08) has been submitted for draft-mraihi-totp-timebased-08.txt. http://www.ietf.org/internet-drafts/draft-mraihi-totp-timebased-08.txt Sub state has been changed to AD Follow up from New Id Needed Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-mraihi-totp-timebased-08 IETF Secretariat. </pre> Pei, Mingliang 2011-02-25T18:20:52 http://comments.gmane.org/gmane.ietf.keyprov/993 <pre> I am out of the office until 02/11/2011. Note: This is an automated response to your message "KEYPROV Digest, Vol 47, Issue 1" sent on 2/7/11 9:39:16. This is the only notification you will receive while this person is away.</pre> Ron Williams 2011-02-07T17:04:53 http://comments.gmane.org/gmane.ietf.keyprov/992 <pre> The following errata report has been submitted for RFC6063, "Dynamic Symmetric Key Provisioning Protocol (DSKPP)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6063&amp;eid=2725 -------------------------------------- Type: Editorial Reported by: Nikolai Malykh &lt;nmalykh-/fzFv00SCG3ILq5++fvS8w&lt; at &gt;public.gmane.org&gt; Section: 7.2.2 Original Text ------------- To handle content negotiation, HTTP requests MAY include an HTTP Accept header field. This header field SHOULD should be identified using the MIME type specified in Section 7.2.1. The Accept header MAY include additional content types defined by future versions of this protocol. Corrected Text -------------- To handle content negotiation, HTTP requests MAY include an HTTP Accept header field. This header field SHOULD be identified using the MIME type specified in Section 7.2.1. The Accept header MAY include additional content types defined by future versions of this protocol. Notes ----- Double "should" 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. -------------------------------------- RFC6063 (draft-ietf-keyprov-dskpp-14) -------------------------------------- Title : Dynamic Symmetric Key Provisioning Protocol (DSKPP) Publication Date : December 2010 Author(s) : A. Doherty, M. Pei, S. Machani, M. Nystrom Category : PROPOSED STANDARD Source : Provisioning of Symmetric Keys Area : Security Stream : IETF Verifying Party : IESG </pre> RFC Errata System 2011-02-18T14:16:46 http://comments.gmane.org/gmane.ietf.keyprov/991 <pre> </pre> Hannes Tschofenig 2011-02-18T11:14:29 http://comments.gmane.org/gmane.ietf.keyprov/990 <pre>http://www.nist.gov/nstic/video.html What this esteemed bunch of people may have overlooked, is that in a world hooked on on-line, the majority of actual uses-cases also presume on-line provisioned credentials directly to the end-user. However, there is no such system available today for the USB tokens and smart cards referred to in this video; you typically need a proprietary card management system. My personal take on this particular subject is that it doesn't make sense trying to make a variant and often NDA-protected technology like smart cards perform tricks that it was never designed for; it is much easier defining a "Web Token" which of course would be completely open and only require a single device driver. Anders </pre> Anders Rundgren 2011-02-07T16:37:11 http://comments.gmane.org/gmane.ietf.keyprov/989 <pre>http://www.nist.gov/nstic/video.html What this esteemed bunch of people may have overlooked, is that in a world hooked on on-line, the majority of actual uses-cases also presume on-line provisioned credentials directly to the end-user. However, there is no such system available today for the USB tokens and smart cards referred to in this video; you typically need a proprietary card management system. My personal take on this particular subject is that it doesn't make sense trying to make a variant and often NDA-protected technology like smart cards perform tricks that it was never designed for; it is much easier defining a "Web Token" which of course would be completely open and only require a single device driver. Anders </pre> Anders Rundgren 2011-02-07T16:39:16 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.keyprov