Certificates with OpenSSL test key

613 views
Skip to first unread message

Hanno Böck

unread,
Nov 6, 2021, 12:37:27 PM11/6/21
to dev-secur...@mozilla.org
Hi,

I recently discovered two certificates issued for a private key that is
part of the OpenSSL source code. Here's the key in question:
https://github.com/openssl/openssl/blob/master/test/certs/x509-check-key.pem

This key is used in two certificates:
https://crt.sh/?spkisha256=79f76c34a64d70c157113947dfe3cb8e4d7d035e4319142eb3dfb84c15f25ca4

One was issued by Digicert and expired shortly before I discovered
this. The other was issued by Godaddy and has been revoked after I
reported it.

I am not sure if there should be an expectation that example/test keys
are blocked for certificate issuance. While it is certainly infeasible
to ask to do this for any possible software, it seems OpenSSL is
prominent enough that it's a relatively obvious thing to consider the
keys shipped with it as candidates for a blocklist.

--
Hanno Böck
https://hboeck.de/

Ryan Sleevi

unread,
Nov 6, 2021, 1:02:52 PM11/6/21
to Hanno Böck, dev-secur...@mozilla.org
It’s certainly possible to address post-facto, but I’m not sure this really rises to reasonable to have expected ahead of time. Hopefully with the revisions to blacklisted keys, CAs will find it easy to add this SPKI hash, based on this thread, although certainly 4.9.1.1 of the BRs provides sufficient protection.

It’s good to see there were only two certs affected.

Peter Gutmann

unread,
Nov 12, 2021, 11:59:46 PM11/12/21
to Hanno Böck, dev-secur...@mozilla.org
Hanno Böck <ha...@hboeck.de> writes:

>I am not sure if there should be an expectation that example/test keys are
>blocked for certificate issuance. While it is certainly infeasible to ask to
>do this for any possible software, it seems OpenSSL is prominent enough that
>it's a relatively obvious thing to consider the keys shipped with it as
>candidates for a blocklist.

Is there some recommended way to identify public keys corresponding to well-
known private keys? For example a list of SHA-1 fingerprints of the SPKIs of
various not-private-any-more keys? If there was an open-source list somewhere
it'd make it easy to maintain a blacklist in implementations.

In terms of identifying dubious certs, it might also be useful to check for DN
components from OpenSSL test certs, I don't know how many of those I've seen
where the devs have just done whatever's necessary to make the errors go away.

Peter.

Nick Lamb

unread,
Dec 4, 2021, 6:25:59 PM12/4/21
to dev-secur...@mozilla.org
On Sat, 6 Nov 2021 17:37:22 +0100
Hanno Böck <ha...@hboeck.de> wrote:

> I recently discovered two certificates issued for a private key that
> is part of the OpenSSL source code. Here's the key in question:
> https://github.com/openssl/openssl/blob/master/test/certs/x509-check-key.pem

> I am not sure if there should be an expectation that example/test keys
> are blocked for certificate issuance. While it is certainly infeasible
> to ask to do this for any possible software, it seems OpenSSL is
> prominent enough that it's a relatively obvious thing to consider the
> keys shipped with it as candidates for a blocklist.

Idea: What if we set aside a handful of keys of each sort, as examples,
publicising that software should use *these* examples unless it has
good reason to do otherwise ?

Think like RFC1918 addresses or the .example TLD or 555- prefix
telephone numbers.

We could then popularise these keys as, on the one hand, to be
explicitly blacklisted in *production* Certificate Authorities (but not
development or testing systems, since the example keys would be well
suited to such tasks) and as especially good choices for example keys
in documentation and software examples such as this OpenSSL file.

Nick.


Peter Gutmann

unread,
Dec 5, 2021, 3:45:04 AM12/5/21
to Nick Lamb, dev-secur...@mozilla.org
Nick Lamb <n...@tlrmx.org> writes:

>Idea: What if we set aside a handful of keys of each sort, as examples,
>publicising that software should use *these* examples unless it has good
>reason to do otherwise ?

That's a great idea, publish a set of test keys in common sizes for RSA, DSA,
ECDSA, etc and every crypto library and application can hardwire them in as
their out-of-the-box keys, ensuring that people are forced to change them
after setup/install in order to get keys that are accepted outside the test
environment.

If there's general support for this, and no-one else wants to do it, I can run
up an RFC draft with a bunch of test keys formatted as C byte strings that
could be incorporated into anything in a C-like language with little more than
cut&paste.

Peter.

Hanno Böck

unread,
Dec 5, 2021, 4:55:50 AM12/5/21
to dev-secur...@mozilla.org
On Sat, 4 Dec 2021 23:25:48 +0000
Nick Lamb <n...@tlrmx.org> wrote:

> Idea: What if we set aside a handful of keys of each sort, as
> examples, publicising that software should use *these* examples
> unless it has good reason to do otherwise ?

PKCS #1 already has a file of test vectors.
These are of course only RSA, and also they're no longer to be found at
their original location and don't comply with what you'd use as
modern-day key sizes.

https://www.foo.be/docs/opensst/ref/pkcs/pkcs-1v2/p1ovect1.txt


Generally this is not a bad idea to have a set of existing "test keys",
if someone wants to RFC this I'd though propose to re-use existing
testvector keys if they exist.

Jan Schaumann

unread,
Dec 5, 2021, 12:51:06 PM12/5/21
to Peter Gutmann, Nick Lamb, dev-secur...@mozilla.org
Peter Gutmann <pgu...@cs.auckland.ac.nz> wrote:
> Nick Lamb <n...@tlrmx.org> writes:
>
> >Idea: What if we set aside a handful of keys of each sort, as examples,
> >publicising that software should use *these* examples unless it has good
> >reason to do otherwise ?
>
> That's a great idea, publish a set of test keys in common sizes for RSA, DSA,
> ECDSA, etc and every crypto library and application can hardwire them in as
> their out-of-the-box keys, ensuring that people are forced to change them
> after setup/install in order to get keys that are accepted outside the test
> environment.

I can all but guarantee you that these keys would end
up being used in production environments, in some
cases in environments where people have no control
over changing them (e.g., IoT).

-Jan

Nick Lamb

unread,
Dec 6, 2021, 7:24:04 AM12/6/21
to dev-secur...@mozilla.org, Jan Schaumann
On Sun, 5 Dec 2021 12:51:02 -0500
"'Jan Schaumann' via dev-secur...@mozilla.org"
<dev-secur...@mozilla.org> wrote:

> I can all but guarantee you that these keys would end
> up being used in production environments, in some
> cases in environments where people have no control
> over changing them (e.g., IoT).

This seems fine?

With well-known test keys, such environments have an obvious defect
which can be mechanically detected, reducing the chance that this goes
undetected (e.g. checks you aren't using OpenSSL test keys, but in fact
you have NSS test keys)

For Mozilla's core audience, we'd reduce the risk of test keys getting
certificates in the Web PKI by making them well-known and explicitly
forbidding CAs from issuing for them. We know this has happened before,
it happened in the incident I'm replying to, and it will happen again,
let's make it less often.


If the problem is "But we're so sloppy we use test keys and never
notice" you already have a grave problem, it was not made worse by the
test keys being the same across a dozen systems, just easier to detect
and thus, perhaps, to rectify.

Nick.

Hanno Böck

unread,
Dec 8, 2021, 8:19:58 AM12/8/21
to Peter Gutmann, Nick Lamb, dev-secur...@mozilla.org
On Sun, 5 Dec 2021 08:44:51 +0000
Peter Gutmann <pgu...@cs.auckland.ac.nz> wrote:

> If there's general support for this, and no-one else wants to do it,
> I can run up an RFC draft with a bunch of test keys formatted as C
> byte strings that could be incorporated into anything in a C-like
> language with little more than cut&paste.

I think this is generally a good idea, however I'd propose that you
don't generate any new keys, but just re-use keys from existing RFC.

RFCs 4474 4870 4871 6216 7468 8225 8410 8463 8479 8696 8946 8995 9092
contain private keys.

Peter Gutmann

unread,
Dec 9, 2021, 5:37:18 AM12/9/21
to Hanno Böck, Nick Lamb, dev-secur...@mozilla.org
Hanno Böck <ha...@hboeck.de> writes:

>I think this is generally a good idea, however I'd propose that you don't
>generate any new keys, but just re-use keys from existing RFC.
>
>RFCs 4474 4870 4871 6216 7468 8225 8410 8463 8479 8696 8946 8995 9092 contain
>private keys.

I had a look and... that's a real cargo-cult exercise, those keys are in all
sorts of formats, many have inappropriate sizes like 768 bits, and some only
have public but no private keys (or at least I couldn't find any in one or
more of the above when I looked). The advantage of generating new ones is
that I can just script the creation of the right key types in the right sizes
without having to extract things from all over the place, so I can just dump
the output of the generation code into an RFC draft without a lot of hand-
editing.

Since no-one's said it's a bad idea, I'll get to work in a draft. I was
thinking:

RSA: 1024, 2048, 4096
DLP (DSA, DH, etc): 1024, 2048, 4096
ECC: P256, P384, P521

That should cover 99.99% of the usual suspects without bringing in a mass of
oddball sizes and algorithms.

Peter.

Peter Gutmann

unread,
Feb 20, 2022, 3:27:26 AM2/20/22
to dev-secur...@mozilla.org
Following up from the original discussion about creating well-known test keys, I've just posted a draft which is currently up at:

https://www.ietf.org/staging/draft-gutmann-testkeys-00.html

Peter.

Peter Gutmann

unread,
Feb 20, 2022, 3:29:32 AM2/20/22
to dev-secur...@mozilla.org
I wrote:

It's now at its final location:

https://datatracker.ietf.org/doc/draft-gutmann-testkeys/

And yes, I noticed the typo in the body text after I posted it :-).

Peter.


Corey Bonnell

unread,
Feb 23, 2022, 12:14:50 AM2/23/22
to Peter Gutmann, dev-secur...@mozilla.org
Thanks for sharing this draft, Peter. I went ahead and converted the RSA and
EC keys listed in the draft into OpenSSL private key format so that CAs can
more readily block issuance of certificates containing these keys. They are
listed below:

RSA-1024 key
-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQCw0YNSqI9T1VFvRsIOejZ9feiKz1SgGfbe9Xq5tEzt2yJCsbyg
+xtcuCswNhdqY5A1ZN7G60HbL4/Hh/TlLhFJ4zNHVylz9mDDx3yp4IIcK2lb566d
fTD0B5EQ9Iqub4twLUdLKQCBfyhmJJvsEqKxm4J4QWgI+Brh/Pm3d4piPwIDAQAB
AoGASC6fj6TkLfMNdYHLQqG9kOlPfys4fstarpZD7X+fUBJ/H/7y5DzeZLGCYAIU
+QeAHWv6TfZIQjReW7Qy00RFJdgwFlTFRCsKXhG5x+IB+jL0Grr08KbgPPDgy4Jm
xirRHZVtU8lGbkiZX+omDIU28EHLNWL6rFEcTWao/tERspECQQDp2G5Nw0qYWn7H
Wm9Up1zkUTnkUkCzhqtxHbeRvNmHGKE7ryGMJEk2RmgHVstQpsvuFY4lIUSZEjAc
DUFJERhFAkEAwZH6O1ULORp8sHKDdidyleYcZU8L7y9Y3OXJYqELfddfBgFUZeVQ
duRmJj7ryu0g0uurOTE+i8VnMg/ostxiswJBAOc64Dd8uLJWKa6uug+XPr91oi0n
OFtM+xHrNK2jc+WmcSg3UJDnAI3uqMc5B+pERLq0Dc6hStehqHjUko3RnZECQEGZ
eRYWciE+Cre5dzfZkomeXE0xBrhecV0bOq6EKWLSVE+yr6mAl05ThRK9DCfPSOpy
F6rgN3QiyCA9J/1FluUCQQC5nX+PTU1FXx+6Ri2ZCi6EjEKMHr7gHcABhMinZYOt
N59pra9UdVQw9jxCU9G7eMyb0jJkNACAuEwakX3gi27b
-----END RSA PRIVATE KEY-----

RSA-2048 key
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAsPnoGUOnrpiSqt4XynxA+HRP7S+BSObI6qJ7fQAVSPtRkqso
tWxQYLEYzNEx5ZSHTGypibVsJylvCfuToDTfMul8b/CZjP2Ob0LdpYrNH6l5hvFE
89FU1nZQF15oVLOpUgA7wGiHuEVawrGfey92UE68mOyUVXGweJIVDdxqdMoPvNNU
l86BU02vlBiESxOuox+dWmuVV7vfYZ79Toh/LUK43YvJh+rhv4nKuF7iHjVjBd9s
B6iDjj70HFldzOQ9r8SRI+9NirupPTkF5AKNe6kUhKJ1luB7S27ZkvB3tSTT3P59
3VVJvnzOjaA1z6Cz+4+eRvcysqhrRgFlwI9TEwIDAQABAoIBAEEYiyDP29vCzx/+
dS3LqnI5BjUuJhXUnc6AWX/PCgVAO+8A+gZRgvct7PtZb0sM6P9ZcLrweomlGezI
FrL0/6xQaa8bBr/ve/a8155OgcjFo6fZEw3Dz7ra5fbSiPmu4/b/kvrg+Br1l77J
aun6uUAs1f5B9wW+vbR7tzbT/mxaUeDiBzKpe15GwcvbJtdIVMa2YErtRjc1/5B2
BGVXyvlJv0SIlcIEMsHgnAFOp1ZgQ08aDzvilLq8XVMOahAhP1O2A3X8hKdXPyrx
IVWE9bS9ptTo+eF6eNl+d7htpKGEZHUxinoQpWEBTv+iOoHsVunkEJ3vjLP3lyI/
fY0NQ1ECgYEA3RBXAjgvIys2gfU3keImF8e/TprLge1I2vbWmV2j6rZCg5r/AS0u
pii5CvJ5/T5vfJPNgPBy8B/yRDs+6PJO1GmnlhOkG9JAIPkv0RBZvR0PMBtbp6nT
Y3yo1lwamBVBfY6rc0sLTzosZh2aGoLzrHNMQFMGaauORzBFpY5lU50CgYEAzPHl
u5DI6Xgep1vr8QvCUuEesCOgJg8Yh1UqVoY/SmQh6MYAv1I9bLGwrb3WW/7kqIoD
fj0aQV5buVZI2loMomtU9KY5SFIsPV+JuUpy7/+VE01ZQM5FdY8wiYCQiVZYju9X
Wz5LxMNoz+gT7pwlLCsC4N+R8aoBk404aF1gum8CgYAJ7VTq7Zj4TFV7Soa/T1eE
k9y8a+kdoYk3BASpCHJ29M5R2KEA7YV9wrBklHTz8VzSTFTbKHEQ5W5csAhoL5Fo
qoHzFFi3Qx7MHESQb9qHyolHEMNx6QdsHUn7rlEnaTTyrXh3ifQtD6C0yTmFXUIS
CW9wKApOrnyKJ9nI0HcuZQKBgQCMtoV6e9VGX4AEfpuHvAAnMYQFgeBiYTkBKltQ
XwozhH63uMMomUmtSG87Sz1TmrXadjAhy8gsG6I0pWaN7QgBuFnzQ/HOkwTm+qKw
AsrZt4zeXNwsH7QXHEJCFnCmqw9QzEoZTrNtHJHpNboBuVnYcoueZEJrP8OnUG3r
UjmopwKBgAqB2KYYMUqAOvYcBnEfLDmyZv9BTVNHbR2lKkMYqv5LlvDaBxVfilE0
2riO4p6BaAdvzXjKeRrGNEKoHNBpOSfYCOM16NjL8hIZB1CaV3WbT5oY+jp7Mzd5
7d56RZOE+ERK2uz/7JX9VSsM/LbH9pJibd4e8mikDS9ntciqOH/3
-----END RSA PRIVATE KEY-----

RSA-4096 key
-----BEGIN RSA PRIVATE KEY-----
MIIJKAIBAAKCAgEAs4tJYOY75qjbqJqCl47x9jJE5Vd9jPWGFtXKV1nUnMjZNsM4
qjy5sRHBSX5bUa9pLyYR5on3Z1SAwLD0w2VPQ6+F/oyK1zTgQqitoF/XZQjgC6D3
VsNEO76DPqfRANT7Nn7r1gvbZIZ3/H3rlCRNrRr47tHGWBLAPnxz9/NY6UG8ZkWP
97uXpJqYoRgH4CwaO5rTOlc64YDh/0Mq5VgMycq/q2AvMlvNoJfoe8em1040qH1g
ikP+suT/8fS452hqmEddtRpuvQgXKldBd0kkiyFVyLkG4NVA6Mso9MAK3J/kdYoa
w2SrOeThVSiYVEQVP+7GrUxTSLLjj/VQ9fpYM5eTNzDICIG/Ee7o/jhtW1EoSamD
mUOr89lyIHaXuOwkEaJhnVXKBCM8WiztxvKG2CnQ6Dcge3ZSmqJEhyEmjcAVC7ew
fnMxOnE+WJW6rzrf+mA5WMVn+FzyWx2AondWow0aUKHkaY7amhIrsKp6YPfNImyx
Flz8+cqDCmBswPsUh/JJ5eDHHIhibFcSgIHedsEjhLbUSLZ/DnEjru90qIWWA3R1
VIPykKfeZkZeInsrFzGPikkFKwFF+6KDdyvCmltYEqzO46tigXAZ5UgH8oiXEre4
8wO6X+FH+cLzQ0q3A8HZRnNDgqCjU/Tgy76iaku/Ic6eteedR1fX3gJ/IOUCAwEA
AQKCAgBq0bC7fN8gkU/2lM6jewFL14aT6CSjS6QWS+XRaHmNOhW5dhZteimERqr3
nbyY8cKjsYOu5GCUUnszqVRGOC0beP9Afb9Q4H2YSyDZrIvK6afaY08kiJI89VDC
Yzd+xjgbqRGIzI8f1LzoNMaG4b5xAf4eoCHgXm+P/Z1FZLt+M4TyV+qamjpTTUMH
fPOalMKaubd4G1PFvFc49m47+tHI8N5uCJCr5mCFbjt8AUGrETVVFRrtyBxttL7t
5gpoawAYT0VaLTq7LmgR4c3qOVMLj66o+CQ2ecnfdpeMXgFYV6ylnZ/kpi0VCa5i
av+OCt+VpOsBScq3Eu8+w9YCMopsUCG6GzW4WD2akEBVA/X6D0JMcoYj/IHT3Xv/
G/eMji69A6URLetliZhuSb0wBxrYQaPMqAdsz8eUYzCx/RwhKtPr032aTQqWlbgW
igiJMn1SbxbRVjf6nb8EsLg92LXEBS3FOLbK6ckuyXAQei8e5NR6ZcyluVluQnSR
m+fR7JDkUP5YWNwuAehOvZIH2Oog+jcUDonQENZQHyJhlxgE3nNoD+YcI1yPTmMf
8G297mZtu5r7/aO5ccMpDXve9cV4Wgcb6Urhigsu2K5nmrqmEIUoqF4xf4eomcWJ
9KitQpCmyh758U2NCnpm3HULabGcslgow+rwQiFcCarUqVToVQKCAQEA4EG98cm1
aaz16AItIRuHG18pIUGlif0PbctZR2scHaQBjdeh4Qg5MnRe88Zs9/8xPu1MsWgd
750pzD/oevetGenvNFZiycT05ucHqk6ZSWNMCGRxpVtnRsKu74dx7yGi7oq03sTC
BDxwz7qJ5esvYuoHx0vUFmdpEqlYn7PtcCiPigPRkcWKiJbosg8e3pGAztMDWfdf
SK/pfEbuWcknHnE3VUrXBVYXhI/TBBzWMEf2RiwOZuGDn2PGEtSjV/XldjVqqufG
SsC/2dZe30svNNrb32kGIMiVykTZYdoFsTYrStXarLkP9YYzXs1+HXoWAMsas3Jp
W27HcXYh276TVwKCAQEAzPVRKdO5JMg4p2zTadRunLgT/js5uvHrEBhH0x0JE1AD
qy/COUMc2m6ZCIg96KBUbjUoN9TrlctB2O7BSmbNOMIkfoKjlDkpJ7v1cKhlXg8q
wkPl+4dv0gtIdnOidy2pcMHfR6Mt6op15wlUcyKcaTyIajFtLOy/A1l7BMqeyr2j
Nm4HZIgFmyRZb1326FaX2+YqsvjMcax/dDtkEm0B8rNhJxbsp2l15RTtTXijIpC+
CoLxRBSZK9GAPa3Jg93ydtLK4aCpA/keeL48C8r1jzzpjRI6pshfZVHFcAf+R3rI
fgOLmpSsxiDeEiWBBTRKDPs3ZVBejn7IasCG9lVkIwKCAQAvfBwxN2nPb40+TD+s
E/0ewZ6e6RyZRFlhAT7tTXPNnu2pUDB5ytj5owR8D9cBCCswTOUBZ693DktMcXfT
meAwbYV2CpiuaqMExYSs/imdDYaK/GHIBruukwihtYddgDzUz9AOn5EJfpbQlYof
ghYtlqqA+8Bz4f+wsOUQI/Qx3JTQP5C/khmMZI/vLB54OE0S/kFmamflp0IES6yq
nFpJKuXxjIBNI/ak3iNraoO8A3DVWPzPsg7B0EmfsSDJPksRJaxpddxZ9chp4ueB
1pSvV2xZOQ7QIEj/ZGa3PogYBwVRukisbB9B+OGlwFNlAHXqQxdrSd2fO6zFjKMM
uaTPAoIBAFdahwkor9Q5ccwJ2eFVJP+uhPbqDyTaTrFBZ/tWeLO+epHPfRwiun1u
fdLhHmGzU8jU5xtEqFPjmWD4AXHQds8mD5/L1iQqaJwCxA0L+IgqNrMtdSvLAaGo
JW42wpvA3mKsfplttvgroyyhEVkw+zDvF8UK49kt3gtza7cTFLKcOJ/OLWBviNQi
neuVRNKpdXfHlZNJ7vjT6E6FsZUY2Ke0REgAwURo8lJ8pNdL/1uQDS81t9aoYNAI
LnwbQbPuOJTkKowXiXGkD5Sun7D3A8nU0EXL6yuCYwYv39Jr1bhpYGI06J8tlqWr
BHr/eQnay2TU/Ts1EdfxuUGmZN9AbbkCggEBANEMkY2p8m2pTf87CSQ8jMPUOQJt
5iuenzesYLvXqVLLB4SUvXN+zDplDJPELtf2SQIHrplrPNH/H01jnWHd0ecSjVY8
HBbIs52U1d5ek3/mWji4GeRp+Iw84CUh4q2p40bmob1RJ8e9sh2ixhHjX2yJ591m
oGbLIz75a60a05mUDK0FWt9cWHn4MKgIPKbWwFhYwmYDCjO/tK2DtcySny9soh5Q
KVQriuvna2lE4YY+OUc7btmtkmp9v+LHKOI8dPabsOBU8Z8UbOGeHSNrZTQwpx3E
p0riDg0UEzFmoYrfbvf+2VzEZDX/TJYjK9VkA8w5+xat8iS0/euKuvSRMb8=
-----END RSA PRIVATE KEY-----

P256 key
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIObLW92AqkWunJXowVR2Z5/+yVPBaFHnEedDk5WJxk/BoAoGCCqGSM49
AwEHoUQDQgAEQiVI+I+3gv+17KN0RFLHKh5Vj71vc75eSOkyMsxFxbFsTNEMTLjV
uKFxOelIgsiZJXKZNCX0FBmrfpCkKklCcg==
-----END EC PRIVATE KEY-----

P384 key
-----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDDiVjMo36v2gYhga5EyQoHB1YpEVkMbCdUQs1/syfMHyhgihG+iZxNx
qagbrA41dJ2gBwYFK4EEACKhZANiAARbCQG4hSMpbrkZ1Q/6GpyzdLxNQJWGKCv+
yhGx2VrbtUc0r1cL+CtyKM8ia89MJd28/jsaOtOUMO/3Y+HWjS4VHZFyC3eVtY2m
s0Y5YTqPubWo2kjGdHEX+ZGehCTzfsg=
-----END EC PRIVATE KEY-----

P521 key
-----BEGIN EC PRIVATE KEY-----
MIHcAgEBBEIB2STcygqIf42Zdno32HTmN6Esy0d9bghmU1ZpTWi3ZV5QaWOP3ntF
yFQBPcd6NbGGVbhMlmpgIg1A+R7Z9RRYAuqgBwYFK4EEACOhgYkDgYYABAHQ/XJX
qEx0f1YldcBzhdvr8vUr6lgIPbgv3RUx2KrjzIdf8C/3+i2iYNjrYtbS9dZJJ44y
FzagYoy7swMItuYY2wD2KtIExkYDWbyBiriWG/Dw/A7FquikKBc85W8A3psVfB5c
gsZPVi/K3vxKTCj200LPPvYW/ILTO3KFySHyvzb92A==
-----END EC PRIVATE KEY-----

As an aside, I believe the draft is specifying the parameter value octets in
big endian format, not little endian as indicated in section 2. Interpreting
the octet sequences as little endian was yielding errors such as the private
exponent ("d") of the RSA-1024 being larger than the modulus ("n"), etc.

Thanks,
Corey
--
You received this message because you are subscribed to the Google Groups
"dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to dev-security-po...@mozilla.org.
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/SY4PR01MB6251A56575300C6B2B4C277CEE399%40SY4PR01MB6251.ausprd01.prod.outlook.com.

Peter Gutmann

unread,
Feb 24, 2022, 6:15:53 AM2/24/22
to Corey Bonnell, dev-secur...@mozilla.org
Corey Bonnell writes:

>Thanks for sharing this draft, Peter. I went ahead and converted the RSA and
>EC keys listed in the draft into OpenSSL private key format so that CAs can
>more readily block issuance of certificates containing these keys. They are
>listed below:

Thanks for that, I'll post an updated draft in a minute. And thanks for
catching the endianness error, the internal format is little-endian but when
serialised the values are big-endian, I've corrected the text.

Peter.


Reply all
Reply to author
Forward
0 new messages