Subject: RE: RFC2459 - CRL signature verification?

From: Darren Harter <[email-masked]>
Date: Tue, 25 May 1999 09:55:29 +0100

Sean,

The closest I can find is:

"10  Security Considerations

   ....  Since certificates and CRLs are
   digitally signed, no additional integrity service is necessary.
   ...".

But that's only an implicit 'check the signature'.

Also, 7.2.2 says the following is id-dsa-with-sha1 appears in an AlgorithmIdentifier:

 "The DSA parameters in the subjectPublicKeyInfo field of the
   certificate of the issuer shall apply to the verification of the
   signature".

But again you could argue that that means IF you bother to check the signature then you SHALL use the key in the issuer's cert. 

All that said, would you ever use untrusted information when making a security relevant decision?  IMHO, you'd be safer to not check for revocation at all than to use a CRL that you've not checked the signature on.  Otherwise, your application will be wide open for denial of service attacks.

I think the authors have probably taken the common sense assumption that applications will check the signatures of signed objects UNLESS they have received them from a trusted source.

Hope this helps,

Regards,

Darren

------------------------------------------------------------------------
Darren Harter BSc (Hons) CEng MBCS
Entegrity Solutions Corp
http://www.entegrity.co.uk
http://www.entegrity.com
Tel:  +44 (0) 1452 371383
Fax: +44 (0) 1452 371384
Cell: +44 (0) 7801 812850
Email: mailto:[email-masked]

-----Original Message-----
From:	Sean Turner [SMTP:[email-masked]]
Sent:	Tuesday, May 25, 1999 4:32 AM
To:	PKIX
Subject:	RFC2459 - CRL signature verification?

All,

I've been searching through RFC2459 looking for text that says something
about verifying the signature on the CRL.

Clause 3.3 (2nd paragraph) says:

When a certificate-using system uses a certificate (e.g., for verifying
a remote user's digital signature), that system not only checks the
certificate signature and validity but also acquires a suitably-recent
CRL and checks that the certificate serial number is not on that CRL.

But it stops short of saying 'check the signature on the CRL.' Can
somebody tell me where the requirement to verify the signature on the
CRL before using it is stated? (and to check to see that the right CA
signed it, etc.)

Thanks,

spt

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 25 May 1999 14:41:41 +0200

We have had an internal debate regarding what has to be done in order to
allow us to use the Qualified Certificates profile to construct a
certificate that fulfills the European directive on electronic signatures.

We have two issues that we can't agree on and would like to have help from
the list.

Issue 1) Identification of pseudonym names stored in commonName

The directive requires that a pseudonym "identified as such" can be used as
part of the subjects name in a certificate.

The question is if a pseudonym stored in a commonName attribute in the
subject field should include some information that the attribute contains a
pseudonym. e.g. CN="<pseudonym>Bill Clinton" in order to alert the relying
party that the name is not a real name but a pseudonym.

The alternative is to allow pseudonym name in the commoName with no other
identification of the name semantics than what is implicitly defined by an
indicated certificate policy and/or it's qualifier(s).

Issue 2) Storage of maximum value per transaction.

The directive requires that a certificate, if applicable, shall contain
information about a maximum monetary amount per transaction that the
certificate should support. 

This could be done by defining a new extension (like the Germans already
have done in their interoperability specifications), or alternatively just
say that this shall be solved by a certificate policy, possibly in
combination with a policy qualifier.

Arguments has been raised that Policy qualifiers are not suitable for
automatic interpretation but that is not confirmed.

We need reactions from mainly potential implementors. What possibilities,
problems do you see with the alternatives outlined in this mail??

Please let us know. 

/Stefan
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: Sean Turner <[email-masked]>
Date: Tue, 25 May 1999 10:15:41 -0400

Darren,

Thanks for the response.  I guess I was looking for an explicit statement of the need to verify the signature on the CRL (assuming of course you implement them, etc.).

Cheers,

spt

---

From: Juergen Brauckmann <[email-masked]>
Date: Wed, 26 May 1999 08:03:36 +0200

Hi.

>indicated certificate policy and/or it's qualifier(s).

The underlying question seems to be whether qualified certificates are
handled in a known environment where the software knows all about things
like certain policy OIDs or if we think that it might be necessary that a
human sees parts of a certificate and tries to interpret it.

If we assume that we live in a known environment, we can use policy oids.
If we assume that qualified certificates might go to some other place, it
might be a good idea to use a modifier in the DN, because such information
can always be interpreted by the user.

>automatic interpretation but that is not confirmed.

I don't think that an extension "monetaryLimit=100,-DM" is suitable for
automatic interpretation, too, because the extension does not express the
policy of the CA: Is the CA liable for the 100,-DM or not? Did the CA check
that the certificate owner in fact has 100,-DM? This are enough questions
that inhibit a decision by the software if the certificate is to be
accepted or not, and thus the software needs to check the policy.

Regards,
   Juergen
-- 
Juergen Brauckmann             Tel.:  040 / 766 29 2708
TC Trust Center for Security   Fax.:  040 / 766 29 577
in Data Networks GmbH 	    mailto:[email-masked]
Am Werder 1    		    http://www.trustcenter.de	
21073 Hamburg