[xmlsec] core methods for write of <X509SubjectName/> and <X509IssuerSerial/>

Roumen Petrov xmlsec at roumenpetrov.info
Fri Jul 18 02:51:20 PDT 2003

Hi Aleksey,

Please find answers in quoted text.

Aleksey Sanin wrote:

> Hi, Roumen!
> Unfortunatelly, I could not open your diff files by some reasons

Please check http://roumenpetrov.info/tmp/xmlsec/ for the files.
About patch:
- please review new methods - they are release candidates;
- all other is very early release, even before alpha version ;-).

> (the folders are there but diff itself is empty). However, from your
> description I see a problem with this patch. You are using a static
> variable to determine the format and this seems wrong to me.

:-) Yes this is OPEN ISSUE: which format (<X509Certificate/>, 
<X509SubjectName/> or <X509IssuerSerial/>) to use method 
- instead of  "switch (x509data_type)" we should use right condition 
(open issue !).
- instead of  "case 1/case 2/case 3" we should use defines, as example:
#define    xmlSecX509DataTypeUndefined         0
#define    xmlSecX509DataTypeCertificate         1
#define    xmlSecX509DataTypeSubjectName    2
#define    xmlSecX509DataTypeIssuerSerial      3
, but where to put these/similar defines (open issue) ?

> xmlsec library has two ways to control the processing: templates
> and contexts. This allows user to have different processing rules
> for different threads. Using a static variable breaks this very
> important feature.
> I would think that the right way to achieve your goal would be to
> put control in templates.  For example, xmlsec could read the
> <X509Data/> node from template and write back:
>    1) <X509Certificate/> if there is no child elements
>    2) subject name/issuer/certificate if there is corresponding
>    child node in the <X509Data/> template

good idea, but "merlin-xmldsig-twenty-three/signature-x509-is.tmpl" has 
only <X509Data/>, i.e. elements format in X509Data should be specified 
from command line and/or environment. Of course when template contain 
"<X509Data><X509SubjectName/></X509Data>"  we should use 'sn' when 
element X509Data type is undefined.

> In addition to that we should determine when to write CRLs (always?).

No idea. Yes we can send crl, but when signer (one side) has old CRL and 
verifier (other side) has new CRL we should care for this (especially 
when new CRL revoke one of certificates). I think is possible new CRL to 
be issued before expiration date of old CRL. Some CRLs are too big.

> Finally, there is a good question about an option to write full
> certificate and subject for another one in the same time. Is it possible? 

yes. How to specify this from command line ?

My idea is:
$ xmlsec sign --privkey-pem 
"<KEYFILE>[,[{|crt:|sn:|is:}]<CERT_FILE>...]" ...
$ xmlsec sign --privkey-pem "<KEYFILE>[,<CERT_FILE>[#{|crt|sn|is}]...]" ...
, i.e. when certificate file name begin/end with 'sn:/#sn' we should 
write X509SubjectName, for 'is:/#is' - X509IssuerSerial, 'crt:/#crt' - 
allways X509Certificate and otherwise default format (X509Certificate 
when is not specified other).

We can use environment to specify default format:
$ xmlsec sign --privkey-pem "<KEYFILE>,[<CERT_FILE>...]" ...
, where allowed values are '{sn|subjectname}' (case insensitive) for 
<X509SubjectName/>, '{is|issuerserial}' for <X509IssuerSerial/> and all 
other for <X509Certificate/>
or command line:
$ xmlsec sign --with-x509datatype=<SAME_VALUES_AS_IN_ENVIRONMENT> 
--privkey-pem "<KEYFILE>,[<CERT_FILE>...]" ...
or from template:

Note: command line must take precedence over environment settings, and 
template over all other settings.

Other ideas ?

> Can you suggest a good simple scheme to control this?

I'm not familiar with xmlsec enough. After one, two months... ;-)

> Aleksey

More information about the xmlsec mailing list