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

Andreas Steffen andreas.steffen at strongswan.org
Wed Jun 23 22:56:14 CEST 2010

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


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);


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;


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

Best regards


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)

More information about the Dev mailing list