On 8/16/19 12:34 PM, Erwann Abalea wrote:
Bonjour, Having a critical extension adds 3 octets (the BOOLEAN tag, length=1, value=0xff). It may, as a side effect, enlarge the number of octets necessary to encode some structure size. Remove the 2 Netscape extensions, they're way obsolete (don't know why OpenSSL keeps them by default). If size is a hard constraint: - you can probably remove the emailProtection EKU (it's an OID, you'll gain 10 octets). Depending on your use-case, you may need to tweak the EKU (or remove it completely). - SKI and AKI extensions may not be necessary - Key Usage may be marked as non critical (it's a SHOULD in PKIX)
I will look at this and figure out what to change in my .cnf. I have been using what I have in my:
draft-moskowitz-eddsa-pki
A quick reading of RFC8002 tells me that you may need to include the IssuerAltName extension as well?
That is the 8002 SHOULD. But following rfc 2119 on SHOULD, since I can calculate the Issuer HHIT from the prefix in issuerName and the Issuer's Public Key (not carried in the client cert, got to go up the chain to get that), I am avoiding at this stage of development to closely follow 8002. Still thinking on all this.
Thank you on your help
Cordialement, Erwann Abalea Le 16/08/2019 17:11, « openssl-users au nom de Robert Moskowitz » <openssl-users-boun...@openssl.org au nom de r...@htt-consult.com> a écrit : Viktor,On 8/16/19 8:41 AM, Viktor Dukhovni wrote:>> On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users <openssl-users@openssl.org> wrote: >> >> subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark subjectAltName as non-critical" > This is wrong. When the subject DN is empty, the subjectAltName should be > marked as critical. IIRC some Java implementations reject the certificate > otherwise.I have just created a client cert with empty subjectName and criticalsubjectAltName. Interestingly, it is 4 bytes larger than the earlier non-critical SAN cert. See below for the output of the cert.>> I can believe that OpenSSL doesn't support empty subjectName's. An empty one, with no relative disintuished name components, is not the same as not present.> OpenSSL supports empty (empty RDN sequence) subject DNs. > The "-subj /" option is one way to make that happen. > > Empty is of course different from "absent", which is not > possible, since the subject DN is a required component of > an X.509 certificate.I now have it clear that Empty SN is NOT a cert with NO SN. It is therewith null content.Thank you all. $ openssl x509 -noout -text -in $dir/certs/device2.cert.pemCertificate: Data: Version: 3 (0x2) Serial Number: c9:8f:b2:7b:e1:95:74:d0 Signature Algorithm: ED25519 Issuer: CN = 2001:24:28:14::/64 Validity Not Before: Aug 16 14:54:58 2019 GMT Not After : Aug 25 14:54:58 2020 GMT Subject: Subject Public Key Info: Public Key Algorithm: ED25519 ED25519 Public-Key: pub: 69:4f:1c:77:56:69:3a:cd:86:c4:3a:b0:67:b9:50: c3:12:9c:6f:85:65:a0:8f:fa:b5:74:b1:c4:56:f8: 4c:a5 X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Client, S/MIME Netscape Comment: OpenSSL Generated Client Certificate X509v3 Subject Key Identifier: 8A:8D:18:B6:F7:70:7D:17:64:AA:2F:C7:FF:1F:C2:30:E2:D8:56:DD X509v3 Authority Key Identifier: keyid:B1:45:18:9B:33:82:6C:74:29:69:2A:15:93:3B:1C:31:D2:37:D6:CAX509v3 Key Usage: criticalDigital Signature, Non Repudiation, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, E-mail Protection X509v3 Subject Alternative Name: critical IP Address:2001:24:28:14:2B6E:2C43:A2D8:507C Signature Algorithm: ED25519 01:54:3e:d2:21:36:27:57:f2:da:d7:ee:42:ec:8f:05:99:b1: 4b:de:2c:c4:3b:95:6f:ba:f6:25:a5:10:bb:2d:5c:9b:15:46: dc:67:ea:b4:74:df:a6:52:60:6f:cd:06:af:f4:69:5f:37:1a: ba:1a:b4:17:c0:bb:0f:da:be:02
