[strongSwan-dev] X509_AA flag does not meet spec; implementation is buggy too

[Mike Ryan]

Ah, so the trouble is that I though the flag would be automatically
loaded from the certificate. Rather, when I load a certificate I have to
explicitly indicate that I believe this certificate belongs to an
attribute authority.

Therefore when I load my certificates I should do something like this:

cert = lib->creds->create(lib->creds,
                          CRED_CERTIFICATE, CERT_X509,
                          BUILD_FROM_FILE, file,
                          BUILD_X509_FLAG, X509_AA, BUILD_END);

On Wed, Jun 23, 2010 at 10:56:14PM +0200, Andreas Steffen wrote:
> Could you explain why this shouldn't work?
> 
> The X509_AA flag is set by
> 
> load_certdir(this, AA_CERTIFICATE_DIR, CERT_X509, X509_AA);
> 
> in libcharon/plugins/stroke/stroke_cred.c
> 
> http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/plugins/stroke/stroke_cred.c;h=68703d128180b18a3c35c8d4e1e5051b36f3c3f6;hb=HEAD#l1067
> 
> via a library call to the x509 plugin:
> 
> cert = lib->creds->create(lib->creds,
>                           CRED_CERTIFICATE, CERT_X509,
>                           BUILD_FROM_FILE, file,
>                           BUILD_X509_FLAG, flag, BUILD_END);
> 
> http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libcharon/plugins/stroke/stroke_cred.c;h=68703d128180b18a3c35c8d4e1e5051b36f3c3f6;hb=HEAD#l510
> 
> Since the x509 plugin registers to this library call it gets
> the X509_AA flag and adds it into the internal x509_cert_t structure:
> 
>      case BUILD_X509_FLAG:
>           flags |= va_arg(args, x509_flag_t);
> 
> and a little below
> 
>      if (parse_certificate(cert))
>      {
>         cert->flags |= flags;
>         return &cert->public;
>      }
> 
> http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libstrongswan/plugins/x509/x509_cert.c;h=7b362b962ba6c24b2a83ccade19c396d512a2ad8;hb=HEAD#l1701
> 
> As you can see the X509_AA flag is not extracted from the parsed
> X.509 certificate itself but is added externally via the library
> call.
> 
> Best regards
> 
> Andreas
> 
> On 06/23/2010 10:30 PM, Mike Ryan wrote:
> >In that case, the following code in x509_ac::issued_by produces
> >incorrect results for an X.509 cert that has been manually loaded:
> >
> >if (!(x509->get_flags(x509)&  X509_AA))
> >{
> >     return FALSE;
> >}
> >
> >the code can be found in libstrongswan/plugins/x509/x509_ac.c line 739.
> >
> >On Wed, Jun 23, 2010 at 10:01:51PM +0200, Andreas Steffen wrote:
> >>Hello Mike,
> >>
> >>it was never my intention to encode the X509_AA flag in an X.509
> >>certificate. The X509_AA flag is used by strongSwan to mark
> >>certificates read from /etc/ipsec.d/aacerts/ in the internal
> >>certificate linked list storage structure so that they can be
> >>extracted again during the trust chain verification of an X.509
> >>attribute certificate. Of course an authorization authority
> >>extended key usage (EKU) OID similar to ocspSigner would be
> >>helpful so that AA certs could be fetched from some public places.
> >>
> >>Best regards
> >>
> >>Andreas
> >>
> >>On 06/23/2010 09:02 PM, Mike Ryan wrote:
> >>>The X509_AA flag parallels the X509_CA flag. Its basic meaning is: the
> >>>holder if this certificate has the authority to issue X.509 attribute
> >>>certificates.
> >>>
> >>>According to RFC3281, there is no provision to encode a simple boolean
> >>>flag with the meaning of X509_AA in an X.509 certificate.
> >>>
> >>>AA controls, an optional sequence described in section 7.1, provide a
> >>>rich set of controls over which attributes may be issued by an AA. There
> >>>IS a boolean flag in there: permitUnSpecified. If this is true, then the
> >>>holder is allowed to issue any attribute.
> >>>
> >>>This flag is semantically subtly different from a boolean meaning 'is an
> >>>attribute authority'.
> >>>
> >>>The handling of the X509_AA flag is buggy as well. Setting the X509_AA
> >>>flag on a certificate sets a flag in the data structure, but when the
> >>>certificate is encoded into ASN.1 there is no difference between a cert
> >>>with and without this flag.
> >>>
> >>>-
> >>>
> >>>To exercise this bug, create a cert with the X509_AA flag, save its
> >>>encoding to a file, and then load it again. The X509_AA flag will not be
> >>>set.
> >>>
> >>>To create a cert with the AA flag, I modified pki/commands/self.c and
> >>>added X509_AA to the --ca flag like so:
> >>>
> >>>case 'b':
> >>>     flags |= X509_CA;
> >>>     flags |= X509_AA;
> >>>     continue;
> >>>
> >>>Then generate a self-signed cert with the CA flag and print the cert:
> >>>
> >>>$ pki --self --dn cn=test --ca --in private.der>   test.der
> >>>$ pki --print --in test.der | grep AA
> >>>
> >>>No mention of the AA flag is made. The cert is identical to a cert
> >>>without the AA flag specified.
> 
> ======================================================================
> Andreas Steffen                         andreas.steffen at strongswan.org
> strongSwan - the Linux VPN Solution!                www.strongswan.org
> Institute for Internet Technologies and Applications
> University of Applied Sciences Rapperswil
> CH-8640 Rapperswil (Switzerland)
> ===========================================================[ITA-HSR]==