client certs with no subjectName only SAN

[Robert Moskowitz]

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 at openssl.org au nom de rgm at 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 at 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 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
>      
>      
>      
>