[DNSOP] Re: [Ext] Re: Question about draft-ietf-dnsop-must-not-sha1-09

On 8/3/2025 14:18, Paul Hoffman wrote: Please note that this draft is already in the RFC Editor's queue, after having gone through WG Last Call, IETF Last Call, and IESG review. Making changes after it has been approved would likely bring the document back to (at least) the WG for review, whic

[DNSOP] Re: Question about draft-ietf-dnsop-must-not-sha1-09

On 8/3/2025 15:12, Paul Wouters wrote: On Aug 3, 2025, at 12:38, Michael StJohns wrote:  Hi - apologies, I wasn't paying attention as I thought this would have been a simple and clean document. Mukund's note made me take a quick look a this.  I think the document is inc

[DNSOP] Re: Question about draft-ietf-dnsop-must-not-sha1-09

Hi - apologies, I wasn't paying attention as I thought this would have been a simple and clean document. Mukund's note made me take a quick look a this.  I think the document is incomplete or ambiguous. Please add a reference to RFC 4035. Please add a sentence or two that says something like

Re: X-Wing KEM

FYI - The IETF is still mucking around with this.  I *think* the consensus in the LAMPS session in Madrid has happened, but you may want to wait a small amount of time before going too much further. Mike On 7/23/2025 11:52, Wei-Jun Wang wrote: On Jul 23, 2025, at 11:41, Sebastian Stenzel

[rfc-i] Re: Call for comments: (RFC Editor Model (Version 3))

Hi - - Just getting this in under the wire. Section 3.1.1.3 - Reads poorly. Instead "The RSWG has two chairs, one appointed by the IAB and one by the IESG.  Both chairs serve staggered 2-year terms, with the IAB-appointed chair's term beginning (and ending) at the end of the First IETF meeting

[Rswg] Re: [rfc-i] Call for comments: (RFC Editor Model (Version 3))

Hi - - Just getting this in under the wire. Section 3.1.1.3 - Reads poorly. Instead "The RSWG has two chairs, one appointed by the IAB and one by the IESG.  Both chairs serve staggered 2-year terms, with the IAB-appointed chair's term beginning (and ending) at the end of the First IETF meeting

[rfc-i] Re: Can we add ORCIDs to the XML vocabulary?

Hi John - AFAICT from the ORCID website, one use of ORCIDs is to mask personal identity information.   That suggests some policy is needed. I think adding the field is fine. And I'm staying out of the bikeshedding discussions about exactly how that field is formatted.  What I would like in a

[TLS] Re: Errata 4800

maller). TLS is full of this sort of thing. The point being that the maximum values exist to define the size of the length field, not the practical limits. In this particular case, the suggested ticket formulation simply doesn't work if the ClientIdentity is too large. Good thing too, becau

[TLS] Errata 4800

https://www.rfc-editor.org/errata/eid4800 RFC 5077 , "Transport Layer Security (TLS) Session Resumption without Server-Side State", January 2008 I'm working through the list of errata and came across this one. This mechanism is obsol

[IPsec] Errata - Eid 5507 IPSec

https://www.rfc-editor.org/errata/eid5507 RFC 4868 , "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", May 2007 Recommend: HDFU In the test data section, the key pattern for AUTH256-4 and AUTH512-4 (and given other patternin

[Ace] Re: IoT certificate profile vs TLS SNI and subjectAltName

Working off of https://www.ieee802.org/secmail/msg00396.html EUI-MAC-OtherNames-2025 { iso(1) identified-organization(3) dod(6) internet(1) security(5)     mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-eui-mac-othername-00 (tbd0)} DEFINITIONS BEGIN IMPORTS OTHER-NAME FROM PKIX1Implicit-2009 {

Re: Cannot wrap an EC key?

Hmm... looking at the PKCS11 soft token nss code  (from hg.mozilla.org/projects/nss) - ANY failure to unwrap a private key gets returned as a CKR_INCOMPLETE_TEMPLATE. The NSS code for sftk_unwrapPrivateKey is weird.  It starts out with a CKR_ code in a number of places, and if that code is not

Re: RFR: 8189441: Define algorithm names for keys derived from KeyAgreement [v2]

I ran into a few problems related to a similar approach in my own code.  Basically, PKCS12 requires some sort of OID/Algorithm identifier to map to/from the algorithm name.    Anything that you allow for here ideally needs to be supported by KeyStore there. It doesn't help that PKCS11 has CKK_G

Re: Expose native error codes and strings on private Exceptions?

Sorry - missed this before. On 12/5/2024 4:50 PM, Sean Mullan wrote: ... clipped On 11/30/24 8:11 PM, Michael StJohns wrote: I'm wondering if it would make sense to create a public interface that these closed off implementation or factory classes could implement that would allow fo

[rfc-i] Re: [saag] Re: RFCs vs Standards

On 12/11/2024 7:56 AM, Eliot Lear wrote: Eric, On 11.12.2024 13:26, Eric Rescorla wrote: On Tue, Dec 10, 2024 at 12:47 PM Eliot Lear wrote: And this is where we run into problems, because the moment you change that boiler plate, you will devalue the RFC series and create support

Expose native error codes and strings on private Exceptions?

Hi - As Java has become more modularized and locked down, I've lost some easy access to critical information in two places - PCSC and PKCS11.  I haven't gone back to dealing with JDBC recently, but I think I might have the same problem there. To give you an example, java.smartcardio.CardExce

[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.

On 8/29/2024 9:14 PM, Warren Kumari wrote: Yes, I might *personally* decide to use the IANA TA after the validUntil if they haven't published a new one. If I did, that would be entirely my own (bad) decision, and I'm clearly doing something unsupported… just like if I happen to eat a can of bea

[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.

On 8/29/2024 4:24 PM, Paul Hoffman wrote: On Aug 27, 2024, at 16:46, Warren Kumari wrote: Thank you very much for your comments. We've had some discussions, and the authors will be publishing a new version in the next few days addressing these. As you can see, we have turned in -05. We think

[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.

Hi Warren - Inline - On 8/21/2024 6:12 PM, Warren Kumari wrote: On Wed, Aug 21, 2024 at 10:28 AM, Edward Lewis wrote: On Aug 20, 2024, at 20:42, Michael StJohns mailto:m...@nthpermutation.com>> wrote: ... trimmed ... But this document is not a pure protocol-de

[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.

Hi Ed - Thanks for a thoughtful reply.  Notes in line. On 8/21/2024 10:28 AM, Edward Lewis wrote: On Aug 20, 2024, at 20:42, Michael StJohns wrote: Hi Paul - I'm confused from your responses below - is this a WG document where the WG gets to decide, or is this an IANA document (lik

[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.

ion." /msj/ On 8/20/2024 6:20 PM, Paul Hoffman wrote: This is an omnibus reply to the messages on this thread. I believe that the -04 draft is complete, but responses to the replies below may change that. The draft is currently in Warren's hands, so he gets to decide whether a n

[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.

s that chain to this TA that are otherwise valid, as valid regardless of the validFrom date". e.g. We're not requiring a DNS implementation to track date/times outside of the DNSSEC protocol. Trimming... On 8/15/2024 4:58 AM, Petr Špaček wrote: On 10. 08. 24 17:21, Michael StJohns wr

[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.

Hi Peter - continues below. On 8/15/2024 5:41 AM, Peter Thomassen wrote: Hi Mike, On 8/10/24 17:21, Michael StJohns wrote: Paul - this is related directly to the newly specified inclusion of the public key material in this draft (sect 3.2 last para):     A KeyDigest element can contain

[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.

Hi Paul - Inline On 8/9/2024 5:09 PM, Paul Hoffman wrote: On Aug 9, 2024, at 12:16, Michael StJohns wrote: Two comments - one major and one very minor. Major: I'm sorry for the late comment, but I didn't realize you were planning on starting to provide prospective DS's

[DNSOP] Re: [Ext] Request: Review changes - draft-ietf-dnsop-rfc7958bis-03 → 04.

Two comments - one major and one very minor. Major:  I'm sorry for the late comment, but I didn't realize you were planning on starting to provide prospective DS's for unpublished keys.  Telling people there's a new trust anchor, and that the live key matches this file is one thing - easy enou

Re: [DNSOP] [Ext] Notification Call for Adoption: draft-bash-rfc7958bis

After reading the thread, I'm confused as to why there's any question as to adoption.  This is an independent submission replacing an independent submission, and is directive only on ICANN and explanatory for everyone else. Section 5 has "This document describes how DNSSEC trust anchors for th

Re: [DNSOP] should all ccTLD be on the Public Suffix list?

On 7/18/2023 8:42 PM, George Michaelson wrote: I know, I could submit these to the PSL website directly. I am asking a meta question: do we think that operationally, if a PSL exists, that all ccTLD and TLD should be on it? The following ccTLD are in ISO3166 but not in the PSL: bd bl bq

Re: RFR: 8303832: Use enhanced-for cycle instead of Enumeration in JceKeyStore

On 3/8/2023 2:19 PM, Andrey Turbanov wrote: java.util.Enumeration is a legacy interface from java 1.0. There is couple of places with cycles which use it to iterate over collections. We can replace this manual cycle with enchanced-for, which is shorter and easier to read. - Commit

Re: RFR: 8296546: Add @spec tags to API [v3]

Hi - I need to repeat again.  Please avoid using www.ietf.org as the URL base for referencing RFCs.  The appropriate location is www.rfc-editor.org and is going to be more stable in the long run than any reference to an RFC that runs through the IETF's website.  These two websites have differ

Re: RFR: 8296546: Add @spec tags to API [v3]

Hi - I need to repeat again.  Please avoid using www.ietf.org as the URL base for referencing RFCs.  The appropriate location is www.rfc-editor.org and is going to be more stable in the long run than any reference to an RFC that runs through the IETF's website.  These two websites have differ

Re: RFR: 8296546: Add @spec tags to API [v3]

Hi - I need to repeat again.  Please avoid using www.ietf.org as the URL base for referencing RFCs.  The appropriate location is www.rfc-editor.org and is going to be more stable in the long run than any reference to an RFC that runs through the IETF's website.  These two websites have differ

Re: RFR: 8296546: Add @spec tags to API [v3]

Hi - I need to repeat again.  Please avoid using www.ietf.org as the URL base for referencing RFCs.  The appropriate location is www.rfc-editor.org and is going to be more stable in the long run than any reference to an RFC that runs through the IETF's website.  These two websites have differ

Re: RFR: 8296408: Make the PCSCException public accessible

openjdk.org/jeps/403 On 11/23/22 12:21 PM, Michael StJohns wrote: On 11/22/2022 10:24 PM, Xue-Lei Andrew Fan wrote: On Wed, 23 Nov 2022 02:59:47 GMT, Michael StJohns wrote: … CardException doesn't always pass through the details in a comprehensible way from the underlying cause, … Does

Re: RFR: 8296408: Make the PCSCException public accessible

On 11/22/2022 10:24 PM, Xue-Lei Andrew Fan wrote: On Wed, 23 Nov 2022 02:59:47 GMT, Michael StJohns wrote: … CardException doesn't always pass through the details in a comprehensible way from the underlying cause, … Does it sound like a cause that the public APIs are not suffi

Re: RFR: 8296408: Make the PCSCException public accessible

On 11/17/2022 10:27 PM, Xue-Lei Andrew Fan wrote: On Thu, 17 Nov 2022 23:07:46 GMT, Johannes Waigel wrote: Checking the instance is fundamental to find out the real cause. Please don't do that in a serious application. The exception stack is belong to implementation details, and may change

Re: RFR: JDK-8296547: Add @spec tags to API

Daniel et al - Please avoid using ietf.org as the cite location for RFCs The preferred cite for RFCs is generally via www.rfc-editor.org/info/rfc - that will get you to the info page, but with links to pdf, html, and a clean .txt. Cf https://www.rfc-editor.org/info/rfc4180 - "Cite this RFC" 

Re: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA?

about is that our users should also be able to use these algorithms portably. Are you saying portability is no longer a consideration? I have no idea where you got that idea. Regards, David On 21/8/22 02:23, Michael StJohns wrote: Hi David/John - I would submit that you're trying

Re: Is there a KEM (Key Encapsulation Mechanism) architecture being proposed for the JCA?

Hi David/John - I would submit that you're trying too hard to make your life simple! :-) Cipher.wrap/unwrap are the correct methods. For example: Cipher  kem = Cipher.getInstance ("ECIES/GCM-128-64/KDF-SP800-108-COUNTER-SHA256"); kem.init (Cipher.WRAP_MODE, pubkey); byte[] opaqueEncapsulated

Re: [DNSOP] [Ext] draft-ietf-dnsop-alt-tld-16: please review

On 8/19/2022 3:30 PM, Paul Hoffman wrote: DNS resolvers that serve the DNS protocol and non-DNS protocols at the same time MUST resolve .alt names using the non-DNS protocols. It was written the current way as a way to alert developers who are using the Locally-Served DNS Zones registry t

[DNSOP] Authorship - was: Re: [internet-dra...@ietf.org] New Version Notification for draft-hardaker-dnsop-must-not-sha1-00.txt

On 8/15/2022 12:17 PM, Wes Hardaker wrote: Paul Wouters writes: This is why I also think 8624bis is better than a stand-alone document, as it takes into account security effects, market deployment, and trying to push the deployments to where we want it to go, instead of just issuing a document

Re: Case-sensitive Keystore for PKCS#12

vider? *From:* Ravi Patel8 *Sent:* Thursday, July 14, 2022 6:26 PM *To:* Xuelei Fan ; Michael StJohns *Cc:* security-dev@openjdk.org *Subject:* Re: [EXTERNAL] Re: Case-sensitive Keystore for PKCS#12 Thank you for the suggested solutions with an added attribute and a

Re: Case-sensitive Keystore for PKCS#12

On 7/13/2022 3:26 PM, Xuelei Fan wrote: Is it possible make it in the application layer? For example, mapping case-sensitive name to case-in-sensitive name before calling into the standard KeyStore APIs. It may be not good to break the standards for corner cases? Xuelei Hi Xuelei - It wou

Re: Case-sensitive Keystore for PKCS#12

On 7/13/2022 7:38 AM, Ravi Patel8 wrote: We have a customer who is having a security requirement. He wants to know, Is it possible to have case-sensitive support for PKCS#12? We referred the RFCs for PKCS#12. We found that PKCS#12 uses a case in-sensitive alias and the alias Name is mapped with

Re: [DNSOP] Call for Adoption: Negative Caching of DNS Resolution Failures

Disregard this - it was targeted for a different adoption call. Thanks to Paul H for noticing. Mike On 7/12/2022 12:51 PM, Michael StJohns wrote: On 7/12/2022 9:54 AM, Tim Wicinski wrote: This starts a Call for Adoption for Negative Caching of DNS Resolution Failures The draft is

Re: [DNSOP] Call for Adoption: Survey of Domain Verification Techniques using DNS

Let's try and attach the comment to the right call... *sigh*.  See below. On 7/12/2022 9:29 AM, Tim Wicinski wrote: This starts a Call for Adoption for Survey of Domain Verification Techniques using DNS The draft is available here: https://datatracker.ietf.org/doc/draft-sahib-domain-verific

Re: [DNSOP] Call for Adoption: Negative Caching of DNS Resolution Failures

On 7/12/2022 9:54 AM, Tim Wicinski wrote: This starts a Call for Adoption for Negative Caching of DNS Resolution Failures The draft is available here: https://datatracker.ietf.org/doc/draft-dwmtwc-dnsop-caching-resolution-failures/ Please review this draft to see if you think it is suitab

Re: [DNSOP] Fwd: Working Group Last Call for draft-ietf-dnsop-rfc5933-bis

On 7/10/2022 12:30 PM, Dmitry Belyavsky wrote: Section 10: " Sorry, didn't get :( I hope this helps - Mike Oops.  My fault, and I never went back to expand on the omission. Basically, section 10 has TBA1 and TBA2 for two code points, but you use actual values for your examples

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-06.txt

sages in that paragraph are poorly constructed. Later, Mike On 7/8/2022 8:49 AM, Bob Harold wrote: On Thu, Jul 7, 2022 at 6:21 PM Michael StJohns wrote: On 7/7/2022 5:32 AM, Willem Toorop wrote: Dear dnsop, This draft describes a mechanism for automatic provisioning of zones

Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-catalog-zones-06.txt

On 7/7/2022 5:32 AM, Willem Toorop wrote: Dear dnsop, This draft describes a mechanism for automatic provisioning of zones among authoritative name servers by way of distributing a catalog of those zones encoded in a regular DNS zone. The version's focus was finalizing for Working Group Last Ca

Re: [DNSOP] [Ext] DNSOP Document Adoption Poll (June 2022)

Hi Benno - On 7/7/2022 3:12 PM, Benno Overeinder wrote: Hi Mike, On 07/07/2022 20:26, Michael StJohns wrote: On 7/7/2022 12:28 PM, Benno Overeinder wrote: Conducting a survey (2 times now) has worked well over the past 1.5 years to prioritise finishing existing work and starting new work

Re: [DNSOP] [Ext] DNSOP Document Adoption Poll (June 2022)

Hi Benno - On 7/7/2022 12:28 PM, Benno Overeinder wrote: Hi Mike, On 07/07/2022 17:21, Michael StJohns wrote: On 7/7/2022 11:10 AM, Benno Overeinder wrote: It helps us and the WG itself to prioritise WG activities and start a regular WG call for adoption of a number of documents.  We will

Re: [DNSOP] [Ext] DNSOP Document Adoption Poll (June 2022)

Hi Benno - On 7/7/2022 11:10 AM, Benno Overeinder wrote: Hi Paul, On 07/07/2022 16:58, Paul Hoffman wrote: On Jul 7, 2022, at 6:49 AM, Benno Overeinder wrote: Gentle reminder, the poll runs until July 9. Can you say how the poll will be used? There was pretty strong push-back after the or

Re: [DNSOP] punctuation follies, I-D Action: draft-ietf-dnsop-alt-tld-15.txt

On 6/27/2022 4:31 PM, John Levine wrote: It appears that Michael StJohns said: I suggest that reserving "_*" names is redundant as (I *think* - I didn't go looking for the reference?) strings beginning with an underscore can only be used in left-most components of a DNS name.

Re: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-15.txt

Folks - It's either time to put a stake through the heart of this DNS vampire that rises from the grave every 6 months, or to push it for publication.  Given that in 8 years it has yet to gain enough traction for publication, perhaps we de-adopt the draft back into the caring hands of its aut

Re: [DNSOP] punctuation follies, I-D Action: draft-ietf-dnsop-alt-tld-15.txt

On 6/27/2022 4:05 PM, John Levine wrote: It appears that Peter Thomassen said: I am proposing to reserve all top-level underscore labels (_*) for special use. Why? While I don't think that reserving underscore names will break anything that is not already broken, I also don't see what proble

Re: [DNSOP] DNSOP Document Adoption Poll (June 2022)

On 6/27/2022 11:29 AM, Ted Lemon wrote: I think your instinct is correct, Tim. It’s not an optimization to bypass discussion as part of a call for adoption. By asking us to consider six drafts at once, and discuss none of them, you create a strong likelihood of insufficient review. +1 - the s

Re: [DNSOP] draft-hsyu-message-fragments replacement status updated by Cindy Morgan

In line: On 5/1/2022 1:41 PM, John Levine wrote: It appears that Mukund Sivaraman said: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. By way of this, by removing the names of authors, isn't the copyright notice attributed to the

CVE-2022-21449: Psychic Signatures in Java

Hi - FYI - This is currently getting some play time on the Crypto Forum Research Group (related to the IETF): https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/ The thread starts here: https://mailarchive.ietf.org/arch/msg/cfrg/wlIuVws-pmccvbGbBrIBVBhN2GQ/ It's probably covered

Re: RFR: 8285404: RSA signature verification should follow RFC 8017 8.2.2 Step 4

On 4/22/2022 1:21 PM, Weijun Wang wrote: Compare encoded instead of decoded digest in RSA signature verification. - Commit messages: - RFC 8017 8.2.2 Step 4 Changes:https://git.openjdk.java.net/jdk/pull/8365/files Webrev:https://webrevs.openjdk.java.net/?repo=jdk&pr=8365&range=

Re: [DNSOP] [Ext] Fwd: Working Group Last Call for draft-ietf-dnsop-rfc5933-bis

On 4/14/2022 5:09 PM, Paul Hoffman wrote: On Feb 1, 2022, at 12:35 PM, Tim Wicinski wrote: We were reviewing the Working Group Last Call for this, and we received no comments. We know there was interest in at least moving this forward, but even Warren concurred we can't send this to the IESG

Re: RFR: 8284553: Deprecate the DEFAULT static field of OAEPParameterSpec

On 4/11/2022 9:34 PM, Valerie Peng wrote: This trivial change is to deprecate the DEFAULT static field of OAEPParameterSpec class. Wordings are mostly the same as the previous PSSParameterSpec deprecation change. Rest are just minor code re-factoring. The CSR will be filed once review is somew

Re: [Internet]Re: "Pluggable" key serialization in JCE/JCA

in of this request. It seems that nobody representing JDK crypto is involved in COSE/JOSE. Thanx, Anders On 2022-03-25 18:23, Michael StJohns wrote: On 3/25/2022 12:33 PM, Anders Rundgren wrote: On 2022-03-25 17:12, Anthony Scarpino wrote: When you say "construct and EC key", do y

Re: "Pluggable" key serialization in JCE/JCA

t creating keys from parameter data supplied by for example JOSE:   {     "kty": "EC",     "crv": "P-256",     "x": "6BKxpty8cI-exDzCkh-goU6dXq3MbcY0cd1LaAxiNrU",     "y": "mCbcvUzm44j3Lt2b5BPyQloQ91tf2D2V-gzeUxWaUdg"

Re: "Pluggable" key serialization in JCE/JCA

On 3/25/2022 12:07 PM, Michael StJohns wrote: AFAIK, there is still no support for using named curves to construct an EC key. Names curves are MANDATORY in JOSE/CODE. Use AlgorithmParameterGenerator with ECGenParameterSpec.  Works like a charm. Sorry - Got that slightly wrong.  Use this

Re: "Pluggable" key serialization in JCE/JCA

amatically through things like Java PKCS11 or C PKCS11. Later, Mike Regards, Anders On 2022-03-25 3:12, Michael StJohns wrote: On 3/24/2022 12:28 PM, Anders Rundgren wrote: On 2022-03-24 16:59, Michael StJohns wrote: On 3/24/2022 2:46 AM, Anders Rundgren wrote: Hi List, I find it a bit s

Re: "Pluggable" key serialization in JCE/JCA

On 3/24/2022 12:28 PM, Anders Rundgren wrote: On 2022-03-24 16:59, Michael StJohns wrote: On 3/24/2022 2:46 AM, Anders Rundgren wrote: Hi List, I find it a bit strange that every user of crypto either have to write or install specific software for converting JOSE/COSE/PEM keys back-and-forth

Re: "Pluggable" key serialization in JCE/JCA

On 3/24/2022 2:46 AM, Anders Rundgren wrote: Hi List, I find it a bit strange that every user of crypto either have to write or install specific software for converting JOSE/COSE/PEM keys back-and-forth to Java's internal representation. This reduces the value of the abstract types as well.

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v8]

from Michael StJohns... I'll use your exception message on not a `[0]`. For dealing with the error while the parsing of `nameValue`, we've discussed it and my last comment is at https://github.com/openjdk/jdk/pull/7167#discussion_r81016. I'd rather not fail. -

Re: RFR: 8277976: Break up SEQUENCE in X509Certificate::getSubjectAlternativeNames and X509Certificate::getIssuerAlternativeNames in otherName [v5]

OtherName.java @93,97 PR:https://git.openjdk.java.net/jdk/pull/7167     if (derValue1.isContextSpecific((byte) 0) && derValue1.isConstructed()) {     nameValue = derValue1.data.toByteArray();     } else {     throw new IOException("value is not [0]");     } That ex

Re: [DNSOP] Fwd: Working Group Last Call for draft-ietf-dnsop-rfc5933-bis

On 2/1/2022 3:35 PM, Tim Wicinski wrote: All We were reviewing the Working Group Last Call for this, and we received no comments.  We know there was interest in at least moving this forward, but even Warren concurred we can't send this to the IESG unless there are folks saying they feel it is

Re: RFR: 8255739: x509Certificate returns � for invalid subjectAlternativeNames [v2]

On 1/24/2022 2:23 PM, Weijun Wang wrote: On Fri, 14 Jan 2022 11:18:23 GMT, Masanori Yano wrote: Could you please review the JDK-8255739 bug fix? I think sun.security.x509.SubjectAlternativeNameExtension() should throw an exception for incorrect SubjectAlternativeNames instead of returning th

Re: RFR: 8255739: x509Certificate returns � for invalid subjectAlternativeNames

On 1/24/2022 9:51 AM, Sean Mullan wrote: On Sat, 22 Jan 2022 22:48:29 GMT, Michael StJohns wrote: I originally started using the BC certificate factory because the SUN factory didn't understand RSA-OAEP as a key type in SubjectKeyInfo and I was getting a few of those from a group of

Re: RFR: 8255739: x509Certificate returns � for invalid subjectAlternativeNames [v2]

returns � for invalid subjectAlternativeNames _Mailing list message from [Michael StJohns](mailto:mstjo...@comcast.net) on [security-dev](mailto:security-...@mail.openjdk.java.net):_ On 1/18/2022 4:10 PM, Sean Mullan wrote: Hi - Bouncycastle started enforcing properly encoded? INTEGERs a while back

Re: RFR: 8255739: x509Certificate returns � for invalid subjectAlternativeNames

On 1/18/2022 4:10 PM, Sean Mullan wrote: On Thu, 6 Jan 2022 20:28:22 GMT, Sean Mullan wrote: Could you please review the JDK-8255739 bug fix? I think sun.security.x509.SubjectAlternativeNameExtension() should throw an exception for incorrect SubjectAlternativeNames instead of returning the

Re: RFR: 8279066: Still see private key entries without certificates in a PKCS12 keystore

On 12/21/2021 1:26 PM, Sean Mullan wrote: On Tue, 21 Dec 2021 16:31:57 GMT, Weijun Wang wrote: Before password-less PKCS12 keystores are supported, certificates in a PKCS12 file are always encrypted. Therefore if one loads the keystore with a null pass, it contains `PrivateKeyEntry`s without

Re: RFR: 8225181: KeyStore should have a getAttributes method [v5]

it assigns an "unfriendlyName" as an alias if "friendlyName" is missing - basically "0", "1", etc. Thanks - Mike Thanks, Max On Nov 30, 2021, at 10:01 PM, Michael StJohns wrote: Hi - Generically, PKCS12 doesn't require an alias (friendlyName)

Re: RFR: 8225181: KeyStore should have a getAttributes method [v5]

Hi - Generically, PKCS12 doesn't require an alias (friendlyName) for a particular Bag, but does permit it. Which means that getAttributes(String alias) could fail on a legal PKCS12.  It may be worthwhile to add a Set KeyStore::getAttributes(int bagNumber) method. Mike On 11/30/2021 8:15 PM

Re: RFR: 8277246: No need to check about KeyUsage when validating a TSA certificate [v2]

On 11/16/2021 7:46 PM, Weijun Wang wrote: On Tue, 16 Nov 2021 21:00:12 GMT, Weijun Wang wrote: There is no need to check for the KeyUsage extension when validating a TSA certificate. A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit. Weijun Wang has up

Re: RFR: 8277246: No need to check about KeyUsage when validating a TSA certificate [v2]

On 11/16/2021 6:37 PM, Weijun Wang wrote: On Tue, 16 Nov 2021 21:00:12 GMT, Weijun Wang wrote: There is no need to check for the KeyUsage extension when validating a TSA certificate. A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit. Weijun Wang has up

Re: RFR: 8277246: No need to check about KeyUsage when validating a TSA certificate [v2]

On 11/16/2021 5:58 PM, Michael StJohns wrote: On 11/16/2021 4:05 PM, Weijun Wang wrote: On Tue, 16 Nov 2021 21:00:12 GMT, Weijun Wang wrote: There is no need to check for the KeyUsage extension when validating a TSA certificate. A test is modified where a TSA cert has a KeyUsage but

Re: RFR: 8277246: No need to check about KeyUsage when validating a TSA certificate [v2]

On 11/16/2021 4:05 PM, Weijun Wang wrote: On Tue, 16 Nov 2021 21:00:12 GMT, Weijun Wang wrote: There is no need to check for the KeyUsage extension when validating a TSA certificate. A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit. Weijun Wang has up

Re: RFR: 8277246: No need to check about KeyUsage when validating a TSA certificate

On 11/16/2021 2:43 PM, Weijun Wang wrote: There is no need to check for the KeyUsage extension when validating a TSA certificate. A test is modified where a TSA cert has a KeyUsage but without the DigitalSignature bit. - Commit messages: - 8277246: No need to check about KeyUsa

Re: RFR: 8273977: Reduce unnecessary BadPaddingExceptions in RSAPadding

On 11/4/2021 9:13 PM, Michael StJohns wrote: On 11/3/2021 3:03 PM, Lari Hotari wrote: On Mon, 20 Sep 2021 09:35:57 GMT, Lari Hotari wrote: ### Motivation When profiling an application that uses JWT token authentication, it was noticed that a high number of

Re: RFR: 8273977: Reduce unnecessary BadPaddingExceptions in RSAPadding

On 11/3/2021 3:03 PM, Lari Hotari wrote: On Mon, 20 Sep 2021 09:35:57 GMT, Lari Hotari wrote: ### Motivation When profiling an application that uses JWT token authentication, it was noticed that a high number of `javax.crypto.BadPaddingException`s were created. When investigating the code i

Re: [DNSOP] SVCB/HTTPS weasel words are dangerous.

On 11/1/2021 11:58 AM, Eric Orth wrote: The important part for preserving compatibility with potential future changes is the "recipients MUST ignore any SvcParams that are present" part. I don't understand what would be different if the record sender SHOULD became a MUST.  Recipients wouldn

Re: [DNSOP] SVCB/HTTPS weasel words are dangerous.

On 11/1/2021 11:58 AM, Eric Orth wrote: The important part for preserving compatibility with potential future changes is the "recipients MUST ignore any SvcParams that are present" part. I don't understand what would be different if the record sender SHOULD became a MUST.  Recipients wouldn

Re: [DNSOP] Question on interpretation of DO and CD

Hi EKR  - Your table looks correct and hope. You may want to take a look at section 5.9 of RFC 6840, as well as appendix B as there's some implementation guidance with respect to the setting of the CD bit. Mike On 10/6/2021 7:47 PM, Eric Rescorla wrote: Hi folks, We've been trying to tak

Re: [DNSOP] DNSOPMoving forward on draft-ietf-dnsop-private-tld

wrote: On Sun, Aug 1, 2021 at 6:04 PM Michael StJohns <mailto:m...@nthpermutation.com>> wrote: Actually, maybe there should be a general document "DNS Squatting Considered Harmful"? I think that we (well, mainly ICANN) already have a large amount that says things

Re: [DNSOP] DNSOPMoving forward on draft-ietf-dnsop-private-tld

Actually, maybe there should be a general document "DNS Squatting Considered Harmful"?   I personally don't see any real difference between squatting on "onion" vs squatting on "zz" except that we ended up with a ex post facto approval of .onion.   And that AIRC was a near thing. So maybe: 1

Re: [TLS] WGLC for draft-ietf-tls-cross-sni-resumption

On 7/19/2021 10:16 AM, Salz, Rich wrote: I support publication. https://datatracker.ietf.org/doc/draft-ietf-tls-cross-sni-resumption/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls Nit - which also applies to draf

Re: [TLS] WGLC for draft-ietf-tls-flags

On 7/16/2021 7:55 PM, Christopher Wood wrote: This is the second working group last call for the "A Flags Extension for TLS 1.3" draft, available here: https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ Please review this document and send your comments to the list by July 30, 202

Re: [DNSOP] IETF meeting prep and what

d up, and that mostly doesn't describe the IOT side of things. Later, Mike On 1 Jul 2021, at 05:26, Michael StJohns wrote: Peter et al - It might be useful to review RFC 4986 - https://www.rfc-editor.org/rfc/rfc4986.html - Requirements Related to DNS Security Trust Anchor Rollover

Re: [DNSOP] IETF meeting prep and what

Peter et al - It might be useful to review RFC 4986 - https://www.rfc-editor.org/rfc/rfc4986.html - Requirements Related to DNS Security Trust Anchor Rollover - to understand what the problem requirements were/are before resurrecting this discussion again.   If the requirements have changed,

Re: [DNSOP] Review of draft-ietf-dnsop-rfc5011-security-considerations-13, was Re: [Ext] IETF meeting prep and what

On 6/18/2021 7:11 PM, Paul Wouters wrote: Section 6.1.7 confuses me a bit as it defines a numResolvers variable, and uses that to calculate an acceptable new timing period. To me it feels that number of resolvers should not matter, as we should stick to the formal time where all resolvers are eit

Re: [DNSOP] [Ext] IETF meeting prep and what

On 6/18/2021 6:32 PM, Paul Hoffman wrote: On Jun 18, 2021, at 2:21 PM, Wes Hardaker wrote: Peter van Dijk writes: I propose replacing rfc5011-security-considerations I keep meaning to republish it with Olafur's suggested reduced title (since it's really describing just one problem). But it

Re: RFR: 8248268: Support KWP in addition to KW [v7]

Some more general comments - related to the restructuring. In AESKeyWrap at 152-155 - that check probably should be moved to W().   KWP should do the formatting prior to passing the data to W().  Also at 185-187 - move that to W_INV(). AESKeyWrap at 158 - shouldn't you be returning the cipher

Re: RFR: 8248268: Support KWP in addition to KW [v7]

from [Michael StJohns](mailto:mstjo...@comcast.net) on [security-dev](mailto:security-...@mail.openjdk.java.net):_ src/java.base/share/classes/com/sun/crypto/provider/AESParameters.java line 50: 48: 49: public AESParameters() { 50: core = new BlockCipherParamsCore

Re: RFR: 8248268: Support KWP in addition to KW [v7]

In line On 5/21/2021 5:01 PM, Xue-Lei Andrew Fan wrote: On Fri, 14 May 2021 00:33:12 GMT, Valerie Peng wrote: This change updates SunJCE provider as below: - updated existing AESWrap support with AES/KW/NoPadding cipher transformation. - added support for AES/KWP/NoPadding and AES/KW/PKCS5Pad

Re: Tentative suggestion: Make X509Key.getKey() non-protected

Hi Tim - Pardon the top posting, and I'm only speaking for myself, but your suggestion is unlikely to get any traction. First and most importantly, sun.security.x509 et al are non-public classes (e.g. not part of the JDK API, rather than a reference to their java tagging), and generally alig

Re: RFR: 8248268: Support KWP in addition to KW [v4]

*sigh* Minor correction in line. On 4/7/2021 2:49 PM, Michael StJohns wrote: On 4/7/2021 1:28 PM, Greg Rubin wrote: Mike, Yes, this was in response to your comment. I'm aware that the IV really serves more as an integrity check and mode signalling mechanism than anything else. My conce

  1   2   3   4   5   6   7   8   >