headers
Russ Housley | 1 Apr 2007 17:46

Re: netscape-cert-renewal-url & beyond


Such an extension is suitable for publication as an informational 
RFC, unless change control is released to the IETF, in which case a 
standards-track RFC is possible if there is sufficient 
interest.  That said, it does nothing to help a relying party.  It 
helps the subject of the certificate, but this same information could 
be provided to the subject when the certificate is issued without 
burdening all of the parties that make use of the certificate.

Russ

At 02:32 AM 3/31/2007, Anders Rundgren wrote:

>Although the "netscape-cert-renewal-url" certificate extension does
>not appear to be incorporated in any PKIX RFC, it is anyway
>documented in vendor specs like:
>http://msdn2.microsoft.com/en-us/library/aa378149.aspx
>
>I have two open questions regarding this particular extension:
>
>1. Is it supported by any PKI-clients and if so which ones?
>
>2. If it is not already supported on major scale wouldn't it be
>worthwhile supporting such a facility?  My personal experience
>with certificates (I have had numerous), is that they tend to silently
>expire, leaving you high and dry and concluding that "passwords are
>better".   When you have to "renew" from scratch you are thrown
>into laborious processes which can take weeks to perform.
>
>If you have certificate and key in a connected device
(Continue reading)

Permalink | Reply | 0 comments |
headers
Anders Rundgren | 1 Apr 2007 21:08
Picon

Re: netscape-cert-renewal-url & beyond


>Russ Housley wrote:
<snip>

>It helps the subject of the certificate, but this same information
>could be provided to the subject when the certificate is issued

Ehh? When the certificate is "issued"?  I think you need to
elaborate a bit on what you had in mind preferably fitting the 10M
and counting consumer/citizen certificate holders in the EU.

>without burdening all of the parties that make use of the certificate.

How could a relying party be "burdened" by a non-critical extension
it may not understand and definitely do not have to care for?

Anders

At 02:32 AM 3/31/2007, Anders Rundgren wrote:

>Although the "netscape-cert-renewal-url" certificate extension does
>not appear to be incorporated in any PKIX RFC, it is anyway
>documented in vendor specs like:
>http://msdn2.microsoft.com/en-us/library/aa378149.aspx
>
>I have two open questions regarding this particular extension:
>
>1. Is it supported by any PKI-clients and if so which ones?
>
>2. If it is not already supported on major scale wouldn't it be
(Continue reading)

Permalink | Reply | 1 comment |
headers
Russ Housley | 1 Apr 2007 21:16

Re: netscape-cert-renewal-url & beyond


Anders:

> >It helps the subject of the certificate, but this same information
> >could be provided to the subject when the certificate is issued
>
>Ehh? When the certificate is "issued"?  I think you need to
>elaborate a bit on what you had in mind preferably fitting the 10M
>and counting consumer/citizen certificate holders in the EU.

At the time the CA provides the certificate to the subject, they 
could provide the URL for renewal.  It does not need to be in the 
certificate itself.  It just needs to be available to the subject 
when they want to renew.

> >without burdening all of the parties that make use of the certificate.
>
>How could a relying party be "burdened" by a non-critical extension
>it may not understand and definitely do not have to care for?

It is information for the subject, it has no value to the relying 
party.  The extension makes the certificate larger, so it takes more 
bandwidth, which remains an important consideration in some parts of 
the Internet.

Russ
Permalink | Reply | 0 comments |
headers
Philipp Gühring | 6 Apr 2007 02:18
Picon

OCSP Problem


Hi,

The OCSP RFC says that a OCSP request can contain several queries for 
different certificates. 
Those queries can be for certificates from different CA´s  (/Sub-CAs).
Additionally, the RFC demands that the OCSP response has to be signed by the 
OCSP Server certificate that corresponds to the CA of the certificate that 
was asked for in the request.
According to the RFC, the whole OCSP response has to be digitally signed.

Now what happens if a client asks for several different certificates from 
different CA´s? Which corresponding OCSP server certificate should be used to 
sign the whole response?

* The one of the first certificate request?
* The one of the last certificate request?
* Any of the certificate requests?

Is it a security hole, that the digital signature can´t cover the other 
certificates in that case?

Or is it prohibited to ask for certificates from different (Sub-)CA´s in a 
OCSP request?

I couldn´t find anything in the RFC mentioning that issue.

Best regards,
Philipp Gühring
(Continue reading)

Permalink | Reply | 2 comments |
headers
Santosh Chokhani | 6 Apr 2007 03:29

RE: OCSP Problem


The responder should have certificates signed by each of the CAs that it services.  The Responder should
send all the certificates that are relevant to the request.

-----Original Message-----
From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of Philipp Gühring
Sent: Thursday, April 05, 2007 8:18 PM
To: ietf-pkix <at> imc.org
Subject: OCSP Problem

Hi,

The OCSP RFC says that a OCSP request can contain several queries for 
different certificates. 
Those queries can be for certificates from different CA´s  (/Sub-CAs).
Additionally, the RFC demands that the OCSP response has to be signed by the 
OCSP Server certificate that corresponds to the CA of the certificate that 
was asked for in the request.
According to the RFC, the whole OCSP response has to be digitally signed.

Now what happens if a client asks for several different certificates from 
different CA´s? Which corresponding OCSP server certificate should be used to 
sign the whole response?

* The one of the first certificate request?
* The one of the last certificate request?
* Any of the certificate requests?

Is it a security hole, that the digital signature can´t cover the other 
certificates in that case?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ryan Hurst | 6 Apr 2007 04:16
Picon
Favicon

RE: OCSP Problem


OCSP allows for several trust models (although not explicitly called out).

I generally refer to them as:
VA Direct - I trust the OCSP responder to sign for any CA.
VA Delegated - I trust the OCSP responder to delegate its signing ability to any of its sub-Vas.
CA signed - Signed by the same ca/key that signed the certificate.
CA delegated - Signed by a OCSP responder delegated by the CA to sign responses on its behalf.

The most common deployed trust model is the CA delegated trust model.

In your case (a OCSP request for multiple certificates issued by multiple CAs) the responder could have a
certificate from each of the CAs its delegated for where each of these certificates are bound to the same
key pair therefore the signature would still be valid and the bag in the response could contain each of
these certificates.

With that being said it is uncommon for a client to generate requests for more than one certificate at a time.

Ryan

-----Original Message-----
From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org] On Behalf Of Philipp Gühring
Sent: Thursday, April 05, 2007 5:18 PM
To: ietf-pkix <at> imc.org
Subject: OCSP Problem

Hi,

The OCSP RFC says that a OCSP request can contain several queries for 
different certificates.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Rescorla | 6 Apr 2007 20:30

AlgorithmIdentifier, SHA-1, etc.


I'm trying to get a handle on how one ought to encode AlgorithmIdentifier.

As people will perhaps remember, the ASN.1 is:

AlgorithmIdentifier  ::=  SEQUENCE  {
     algorithm               OBJECT IDENTIFIER,
     parameters              ANY DEFINED BY algorithm OPTIONAL  }
                                -- contains a value of the type
                                -- registered for use with the
                                -- algorithm object identifier value

Present hash functions do not take any useful parameters, leaving
us with two encoding options:

  - omit the parameter.
  - include a NULL

To make things more complicated, there are (at least) two different
contexts in which this production appears:

  - The S/MIME DigestAlgorithmIdentifier production.
  - Inside the DigestInfo of the S/MIME signature.

RFC 3370's guidance is to omit the parameter for SHA-1 and include
a NULL for MD5 (see S 2.1 and 2.2.).

However, the current PKCS#1 errata
(ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1errata.txt)
recommend that when one is encoding DigestInfo, one should
(Continue reading)

Permalink | Reply | 0 comments |
headers
Blake Ramsdell | 6 Apr 2007 22:02
Favicon

Re: AlgorithmIdentifier, SHA-1, etc.


Eric Rescorla wrote:
> Technically these don't conflict, but obviously, it's undesirable to
> have the encoding in the message not match that in the DigestInfo,
> since doing binary comparisons is common practice here. So, what's the
> right answer here?

In my case when I receive a digest AlgorithmIdentifier, I bust it open 
and get the OID out and discard the wrapper (the outer 
AlgorithmIdentifier). So I'm not affected by a mismatch if I do that.

But yeah, short of normalizing the values in some way, you're pretty 
much done. That is, there's no binary comparison, and you perform an 
equivalence check by converting both values in such a way that the same 
answer comes out. So if you have { sha-1, NULL } and { sha-1 } you get 
the same answer.

Blake
--

-- 
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com
Permalink | Reply | 0 comments |
headers
Eric Rescorla | 6 Apr 2007 22:09

Re: AlgorithmIdentifier, SHA-1, etc.


At Fri, 06 Apr 2007 13:02:58 -0700,
Blake Ramsdell wrote:
> 
> Eric Rescorla wrote:
> > Technically these don't conflict, but obviously, it's undesirable to
> > have the encoding in the message not match that in the DigestInfo,
> > since doing binary comparisons is common practice here. So, what's the
> > right answer here?
> 
> In my case when I receive a digest AlgorithmIdentifier, I bust it open 
> and get the OID out and discard the wrapper (the outer 
> AlgorithmIdentifier). So I'm not affected by a mismatch if I do that.
> 
> But yeah, short of normalizing the values in some way, you're pretty 
> much done. That is, there's no binary comparison, and you perform an 
> equivalence check by converting both values in such a way that the same 
> answer comes out. So if you have { sha-1, NULL } and { sha-1 } you get 
> the same answer.

Yeah, my thinking is that it would be better for these to match
so that naive implementations work.

-Ekr
Permalink | Reply | 0 comments |
headers
Russ Housley | 6 Apr 2007 22:09

Re: AlgorithmIdentifier, SHA-1, etc.


Note that the DigestInfoValue is part of the structure that is 
"encrypted" with the RSA private key when generating a signature.  It 
is recovered by "decrypting" the signature value with the RSA public key.

An implementation should check that the expected digest algorithm was 
used.  As Eric point out, this check is easier to perform if the two 
values are encoded in exactly the same manner.

One needs to look deeper into signatures in certificates and CMS 
SignerInfo to see where these comparisons are really performed.

The certificate signature has this structure:

    Certificate  ::=  SEQUENCE  {
         tbsCertificate       TBSCertificate,
         signatureAlgorithm   AlgorithmIdentifier,
         signatureValue       BIT STRING  }

In practice, the signature algorithm tells the digest algorithm as 
well as the digital signature algorithm. The ones that are relevant 
to this question are:

    sha1WithRSAEncryption
    sha224WithRSAEncryption
    sha256WithRSAEncryption
    sha384WithRSAEncryption
    sha512WithRSAEncryption

There is no filed that explicitly carries a digest algorithm
(Continue reading)

Permalink | Reply | 0 comments |

Gmane