Re: client certs with no subjectName only SAN

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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-bounces@xxxxxxxxxxx au nom de rgm@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxx> 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 critical
     subjectAltName.  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 there
     with null content.
Thank you all. $ openssl x509 -noout -text -in $dir/certs/device2.cert.pem
     Certificate:
          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:CA
X509v3 Key Usage: critical
                      Digital 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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux