Subject: questions

From: Carlos González-Cadenas <[email-masked]>
Date: Tue, 1 Jun 2004 10:02:25 +0200

Hello,

Two questions

*	It’s a common practice for a CA to issue different kinds of
certificates (i.e. a CA issuing email certificates can issue two
certificates, a certificate for signing and another one for encryption (key
encipherment). Normally, when people want to differentiate this certificates
sintetically (not looking at the certificate characteristics, but looking to
an OID or similar), they derive the policy under the certificate is issued
with an identifier determining the certificate type.

Example: The class 2 certificate policy is identified under OID
1.3.6.1.4.1.x.100.2. So, we can obtain two more OIDs for the two different
types of certificates

1.3.6.1.4.1.x.100.2.1 for the signing cert

1.3.6.1.4.1.x.100.2.2 for the encryption cert

I think using the policies this way we are somewhat perverting the standard.
What we must include in the Certificate Policies (in EE certs) is the policy
under the certificate is issued, not an hybrid between the policy and a
qualifier of the certificate.

Questions about that:

*Is this an ad-hoc standard?? (What’s your oppinion about that??)

*Is there any place (standard one) to include the certificate type OID?

*Are there some ideas about this in son-of-3280?? (I wasn’t able to find
nothing comparable to that in 3280).

*	I’m trying to configure a hierarchy of tree levels of CAs, plus
another level of end entity certificates.

I want to maintain compatibility with Certificate Path Validation algorithms
in RFC3280, specially when referring to policy-tree validation. I want to
assert that the points stated below are ok,

*	For the root certificate, no policies at all (it’s a trust anchor,
and by default can issue certificates with any policy).
*	For the first intermediate certificate (it represents an
organization), I must assert the anyPolicy special policy in the Certificate
Policies, if not, the policy tree gets null after evaluating this node.
*	For the second intermediate certificate (it represents a class CA,
issuing certificates under some well-known policies), I include these
policies in  the Certificate Policies (to restrict the policies that the EE
certificates can be issued under).
*	In the End entity, I include these Policies in the Certificate
Policies, to state that the certificate is issued under these policies.

Questions,

*Is my configuration considered as a “best practice”?

*What are the possible modifications for a son-of-3280?. This configuration
will be affected adversely for that?

Thank you very much in advance

Carlos

Carlos González-Cadenas

Jefe de Departamento de Arquitectura Software

Software Architecture Department Manager

Responsable de Seguridad de la Información

Information Security Responsible

netfocus
by Siemens-BancSabadell

C/Sena, 12 nucli C planta 2
Edifici Landscape
08190 Sant Cugat del Vallès

phone:  +34933556139
fax:      +34933556142
mailto:  [email-masked]
web:     www.netfocus.es <http://www.netfocus.es/>

Advertencia legal:
Este mensaje y, en su caso, los ficheros anexos son confidenciales,
especialmente en lo que respecta a los datos personales, y se dirigen
exclusivamente al destinatario referenciado. Si usted no lo es y lo ha
recibido por error o tiene conocimiento del mismo por cualquier motivo, le
rogamos que nos lo comunique por este medio y proceda a destruirlo o borrarlo,
y que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o
comunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo pena
de incurrir en responsabilidades legales. El emisor no garantiza la integridad,
rapidez o seguridad del presente correo, ni se responsabiliza de posibles
perjuicios derivados de la captura, incorporaciones de virus o cualesquiera
otras manipulaciones efectuadas por terceros.

Advertiment legal:
Aquest missatge i, si escau, els fitxers annexos tenen caire confidencial,
especialment pel que fa a les dades personals, i s'adrecen exclusivament al
destinatari referenciat. Si no es tracta d'aquest i l'ha rebut per error o se li
ha fet arribar per qualsevol motiu, li preguem que ens ho comuniqui per aquesta
mateixa via i el destrueixi o l'esborri, i que en tot cas s'abstingui d'utilitzar,
reproduir, alterar, arxivar o comunicar a tercers aquest missatge i fitxers
annexos, tot sota pena d'entrar en responsabilitats legals. L'emissor no garanteix
la integritat, la rapidesa o la seguretat d'aquest correu, ni es responsabilitza
de possibles perjudicis derivats de la captura, incorporacions de virus o
qualsevol altres manipulacions que facin tercers.

Disclaimer:
This message and any attached files transmitted with it, is confidential,
especially as regards personal data. It is intended solely for the use of the
individual or entity to whom it is addressed. If you are not the intended recipient
and have received this information in error or have accessed it for any reason,
please notify us of this fact by email reply and then destroy or delete the message,
refraining from any reproduction, use, alteration, filing or communication to third
parties of this message and attached files on penalty of incurring legal
responsibilities. The sender does not guarantee the integrity, the accuracy, the
swift delivery or the security of this email transmission, and assumes no
responsibility for any possible damage incurred through data capture, virus
incorporation or any manipulation carried out by third parties.