we are currently working on bringing
XMSS signatures into our products. The software generating the signatures and certificates will be using BouncyCastle, whereas our clients that need to parse certificates and verify the signatures will be using Botan.
During interoperability tests we found that BouncyCastle and Botan are incompatible in different places. One aspect is OIDs of course, both using their own PENs. RFC draft https://tools.ietf.org/html/draft-vangeest-x509-hash-sigs-03 defines OIDs for official use, but it is still in draft state. We contacted the authors about it, unfortunately, it seems it will not be adapted soon. The IETF working group was concerned about the lack of experience in securely maintaining state and that IETF standardization of these OIDs could lead implementors to believe these algorithms were safe to use in more cases than they should be. I have already talked to Jack, the maintainer of Botan (I CC'd him on this thread), about it. Our proposal would be to follow the RFC draft as close as possible ib both libraries, with exception of the OIDs. Botan could be extended to support BouncyCastle's OID for parsing public keys and certificates instead.
from the OID mismatch, we found the following situation with the two implementations:
Regarding public key encoding, this was already partly addressed in https://github.com/bcgit/bc-java/pull/513, but the SubjectPublicKeyInfo encoding was not updated with it and still encodes in the RFC 8391 draft format and not the final RFC 8391 format.
Certificates would need the public key encoding fix and the PARAMS field to be absent. Both can probably be done together.
Although we don't require the private key encoding to be compatible in our current plans on adopting XMSS, we still think it would be useful in general if both major implementations would be interoperable here. Our proposal would be to add support for deserializing Bouncy Castle's format to Botan and eventually, after some releases, switch over to BouncyCastle's format for serializing in Botan, too.
Is this a way to go for you?
Team Coordinator Shared Components
C++ Shared Components & DevOps
Rohde & Schwarz Cybersecurity GmbH
Lise-Meitner-Allee 4 | D-44801 Bochum
Phone: + 49 89 4129 208163
Email: [hidden email]
Executive Board: Dr. Falk Herrmann (CEO)
Company's Place of Business: Munich
Commercial Register No.: HRB 160333, VAT Identification No.: DE 295078969
WEEE Register Nr.: DE 138 891 79
As there's quite a bit here this might be better taken off list until it's sorted.
I'd suggest we start with syncing up properly on the public keys.
I note with some despair that the draft has now expired. I don't think there isn't going to be any improvement in the level of experience people have with these algorithms if there isn't a defined way of using them. WOTS based algorithms are really the only algorithms ready now which offer both well understood security and post-quantum hardness. Assuming the worst case, which is someone hits the n-qbit (n being some appropriate number) barrier by 2026, even a P-521 root certificate is really not going to cut it for more than 5 to 6 years. After 2026 the odds only seem to get worse. Anything which is likely to need to have a still working root certificate in more 5 years should be probably be looking at things like XMSS now.
I'd recommend checking the latest beta as well on https://www.bouncycastle.org/betas as we've made a small addition to the private key structure to allow for sharding. I think, with a little bit of work we could come up with an ASN.1 encoding for the BDS data. Ultimately that's really what's required.
Anyway, drop me a line. Lets see what we can do.
On 25/9/19 11:06 pm, Rene Korthaus wrote:
|Free forum by Nabble||Edit this page|