internet-drafts | 7 Mar 21:47 2012
Picon

I-D Action: draft-ietf-pkix-caa-05.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : DNS Certification Authority Authorization (CAA) Resource Record
	Author(s)       : Phillip Hallam-Baker
                          Rob Stradling
	Filename        : draft-ietf-pkix-caa-05.txt
	Pages           : 16
	Date            : 2012-03-07

   The Certification Authority Authorization (CAA) DNS Resource Record
   allows a DNS domain name holder to specify the certificate signing
   certificate(s) authorized to issue certificates for that domain.  CAA
   resource records allow a public Certification Authority to implement
   additional controls to reduce the risk of unintended certificate mis-
   issue.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-caa-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-caa-05.txt

_______________________________________________
pkix mailing list
pkix <at> ietf.org
(Continue reading)

Phillip Hallam-Baker | 7 Mar 21:55 2012
Picon

Re: I-D Action: draft-ietf-pkix-caa-05.txt

This has only got one major change, and this is to tweak the
definition of the Extended Issuer Authorization set so that it is now
strictly hierarchical.

While doing this, I decided that the term 'public delegation point'
was most likely to be interpreted as being the suffix under which
names are delegated rather than the delegation. [i.e. the PDP for
example.com would be .com].

I tried to fix that but I have just noticed that I wrote prefix rather
than suffix. I have corrected the editors copy and will roll that with
any other changes that are proposed.

On Wed, Mar 7, 2012 at 3:47 PM,  <internet-drafts <at> ietf.org> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work
item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
>
>        Title           : DNS Certification Authority Authorization (CAA) Resource Record
>        Author(s)       : Phillip Hallam-Baker
>                          Rob Stradling
>        Filename        : draft-ietf-pkix-caa-05.txt
>        Pages           : 16
>        Date            : 2012-03-07
>
>   The Certification Authority Authorization (CAA) DNS Resource Record
>   allows a DNS domain name holder to specify the certificate signing
>   certificate(s) authorized to issue certificates for that domain.  CAA
>   resource records allow a public Certification Authority to implement
>   additional controls to reduce the risk of unintended certificate mis-
(Continue reading)

Tom Gindin | 10 Mar 18:50 2012
Picon

Possible OCSP Extensions

        Why isn't there an OCSP response extension containing "never 
issued" or "outside validity period" which a responder may use if they 
have the CA's certificate repository available?  Getting a request that 
produces such an error would not be anything which the responder would be 
expected to report.  A client who had received a response with such an 
extension could then demonstrate that an actual compromise had occurred by 
resending the request with a request extension containing the actual 
certificate, or perhaps the chain, which had provoked that response 
extension above.  Receiving such a certificate would allow the OCSP server 
to verify that the CA had actually been cracked and then react.
        I think that such a feature would be useful to responders operated 
by a CA with many subordinate CA's, and possibly to others as well.

Tom Gindin
P.S. - The above suggestion is mine, and not necessarily that of my 
employer.

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix

Phillip Hallam-Baker | 11 Mar 17:17 2012
Picon

Re: Possible OCSP Extensions

I think it would be good to have a way to state precisely what the
server knows about the certificate. This can lead to problems though
if the OCSP server is on a batch update from the certificate service.

If we are going to make this scale it has to be possible to pre-sign
the proofs of non-existence as an option. That means adopting the
NSEC-type approach of signing the gaps between the existing records.

So what I think is needed is actually two pieces of response data:

1) This service has no knowledge of any certificate between serial # X and Y
2) This assertion was generated from data current at time X

The signing time is arguably a proxy for the second - or could be made such.

What I totally reject is the notion that we should constrain the spec
according to the architecture of certain third party OCSP responders
as has been proposed in the past. The CAs have this data and the
relying apps have a purpose that requires it.

There may well be a role for fourth parties (not a CA, subject or RP)
to add value to PKIX certificates as I have proposed on the Right Key
list. I just don't think OCSP is the right protocol for doing that.
Nor is DNS.

On Sat, Mar 10, 2012 at 12:50 PM, Tom Gindin <tgindin <at> us.ibm.com> wrote:
>        Why isn't there an OCSP response extension containing "never
> issued" or "outside validity period" which a responder may use if they
> have the CA's certificate repository available?  Getting a request that
> produces such an error would not be anything which the responder would be
(Continue reading)

Piyush Jain | 11 Mar 18:17 2012

Re: Possible OCSP Extensions

Is this trying to address the case where CA continues to operate after it
has been compromised?
I'm assuming that in this case EE certificates have been signed using the CA
key and somehow deleted from the CA's issued certificates repository.
What happens if the attacker issued an OCSP signing certificate (with
OCSP-no-check) as opposed to an EE certificate?

Many of us would believe that only way to address this breach is to revoke
the CA.

There could be limited use of this extension for the CA to determine if it
has been compromised.

-Piyush

> -----Original Message-----
> From: pkix-bounces <at> ietf.org [mailto:pkix-bounces <at> ietf.org] On Behalf Of
> Tom Gindin
> Sent: Saturday, March 10, 2012 9:50 AM
> To: pkix
> Subject: [pkix] Possible OCSP Extensions
> 
>         Why isn't there an OCSP response extension containing "never
issued" or
> "outside validity period" which a responder may use if they have the CA's
> certificate repository available?  Getting a request that produces such an
> error would not be anything which the responder would be expected to
> report.  A client who had received a response with such an extension could
> then demonstrate that an actual compromise had occurred by resending the
> request with a request extension containing the actual certificate, or
(Continue reading)

Tom Gindin | 12 Mar 04:50 2012
Picon

Re: Possible OCSP Extensions

        Piyush:

        One purpose of this is to identify cases where the issuer has 
apparently been compromised, and the major purpose of the request 
extension (call it "requested certificate body" or "requested certificate 
chain") is to allow such a case to be substantiated.  Once the request is 
substantiated, I would expect the issuer key to be treated as compromised 
unless the submitted certificate is a digest duplicate against an actual 
issued certificate.  That would be an algorithmic issue rather than a key 
compromise.
        I'd like to adapt part of Phill's suggestion, and redefine the 
proposed "never issued" status as "Not issued before" and a time.  The 
presigned variant, which might be called "no serial number within range", 
seems right for issuers with increasing serial numbers but makes less 
sense for issuers who assign serial numbers which don't monotonically 
increase with time.  Phill, is that supposed to be the closed interval 
(with the two endpoint serial numbers not issued) or the open one (with 
the two endpoint serial numbers issued)?  Also, is there an option in 
which the upper bound is not specified which means "no serial number above 
L had been issued as of time T"?

Tom Gindin

From:   Piyush Jain <piyush <at> identicate.com>
To:     Tom Gindin/Watson/IBM <at> IBMUS, "'pkix'" <pkix <at> ietf.org>, 
Date:   03/11/2012 01:17 PM
Subject:        RE: [pkix] Possible OCSP Extensions

Is this trying to address the case where CA continues to operate after it
has been compromised?
(Continue reading)

Phillip Hallam-Baker | 12 Mar 13:57 2012
Picon

Re: Possible OCSP Extensions

And many of us think that we should fix the damn spec to do what it
was originally intended to do until a bunch of people with a business
model and a startup ruined it.

There are many reasons why this functionality would be required. There
are tens of thousands of certs revoked for cause every year. less than
1% of those so revoked last year were due to mis-issue.

Why do we have so many people obsessing about what has been the rarest
use case for OCSP and not the fact that the browsers don't actually
hard fail on OSCP?

On Sun, Mar 11, 2012 at 1:17 PM, Piyush Jain <piyush <at> identicate.com> wrote:
> Is this trying to address the case where CA continues to operate after it
> has been compromised?
> I'm assuming that in this case EE certificates have been signed using the CA
> key and somehow deleted from the CA's issued certificates repository.
> What happens if the attacker issued an OCSP signing certificate (with
> OCSP-no-check) as opposed to an EE certificate?
>
> Many of us would believe that only way to address this breach is to revoke
> the CA.
>
> There could be limited use of this extension for the CA to determine if it
> has been compromised.
>
> -Piyush
>
>
>
(Continue reading)

Phillip Hallam-Baker | 12 Mar 14:29 2012
Picon

Re: Possible OCSP Extensions

Actually, the idea for the serial numbers was not that they would
necessarily be monotonic, rather the idea is just to sign the gaps. If
the CA signs non-monotonic serial numbers then they would have to sort
them into order first.

So the way a CA would work is that every OCSP signing increment, say 1
hour, they would create OCSP responses for

1) Every known cert issued
2) The gaps between the serial numbers.

So with 100 certs issued, this would be 200 OCSP responses.

If a cert is issued within that time interval, the CA creates three
additional OCSP responses, one for the new cert and two for the new
serial number intervals that have just been created.

This approach allows CAs to avoid creating additional timing errors
but is still robust if they are introduced by others.

On Sun, Mar 11, 2012 at 11:50 PM, Tom Gindin <tgindin <at> us.ibm.com> wrote:
>        Piyush:
>
>        One purpose of this is to identify cases where the issuer has
> apparently been compromised, and the major purpose of the request
> extension (call it "requested certificate body" or "requested certificate
> chain") is to allow such a case to be substantiated.  Once the request is
> substantiated, I would expect the issuer key to be treated as compromised
> unless the submitted certificate is a digest duplicate against an actual
> issued certificate.  That would be an algorithmic issue rather than a key
(Continue reading)

Rob Stradling | 12 Mar 14:45 2012

Re: Possible OCSP Extensions

On 12/03/12 13:29, Phillip Hallam-Baker wrote:
> Actually, the idea for the serial numbers was not that they would
> necessarily be monotonic, rather the idea is just to sign the gaps. If
> the CA signs non-monotonic serial numbers then they would have to sort
> them into order first.
>
> So the way a CA would work is that every OCSP signing increment, say 1
> hour, they would create OCSP responses for
>
> 1) Every known cert issued
> 2) The gaps between the serial numbers.
>
> So with 100 certs issued, this would be 200 OCSP responses.
>
>
> If a cert is issued within that time interval, the CA creates three
> additional OCSP responses, one for the new cert and two for the new
> serial number intervals that have just been created.
>
> This approach allows CAs to avoid creating additional timing errors
> but is still robust if they are introduced by others.

The CA may have issued three additional OCSP Responses, but how do you 
force clients to use them instead of cached copies of the previous 
Responses?

Would the Responder have to set the various HTTP "no cache" headers when 
it sends a "gaps between the serial numbers" Response?

Or would we just have to accept that newly issued certs may cause 
(Continue reading)

denis.pinkas | 12 Mar 14:45 2012
Picon
Picon

Re: Possible OCSP Extensions

Tom,

Your email is not crystal clear (at least to me) and seems to address at the same time two different topics:

   - an OCSP response extension containing "never issued" and
  - an OCSP response extension containing "outside validity period".

I can understand "never issued", but I don't know what you mean, in the context of OCSP, with "outside validity period"

Your proposal seems allowing an OCSP server "to verify that a CA had actually been cracked and then react".
The problem is that we cannot do this, until we first specify a way to return a status like "never issued".

Simply adding an additional status report like "never issued" would not be sufficient as explained below.

The problem is that OSCP was originally designed to work either :

 - with CRLs only, or
 - with a revocation status data base for revoked certificates only, or
 - with a revocation status data base for all issued certificates managed directly by the CA which issued that certificate.

We currently have no way to indicate either in the request or in the response
which of the three modes is/was requested or used.

An OCSP server might only indicate "never issued", if  it also indicates that it got this information using
a revocation status data base for all issued certificates managed directly by the CA which has issued that certificate.

This means that this extension may only be present if the OCSP responder is using  a revocation status data base
for all issued certificates managed directly by the CA which has issued that certificate.
 
This extension would then contain a boolean to say whether of not the certificate was issued.

I remember that we discuss this topic on the PKIX  list but I don't remember any concrete proposal.

Once we have such a mechanism (or a similar one), then we can build on it and discuss (and understand better) your proposal.

Denis




De :        Tom Gindin <tgindin <at> us.ibm.com>
A :        pkix <pkix <at> ietf.org>
Date :        10/03/2012 18:51
Objet :        [pkix] Possible OCSP Extensions
Envoyé par :        pkix-bounces <at> ietf.org



        Why isn't there an OCSP response extension containing "never
issued" or "outside validity period" which a responder may use if they
have the CA's certificate repository available?  Getting a request that
produces such an error would not be anything which the responder would be
expected to report.  A client who had received a response with such an
extension could then demonstrate that an actual compromise had occurred by
resending the request with a request extension containing the actual
certificate, or perhaps the chain, which had provoked that response
extension above.  Receiving such a certificate would allow the OCSP server
to verify that the CA had actually been cracked and then react.
       I think that such a feature would be useful to responders operated
by a CA with many subordinate CA's, and possibly to others as well.

Tom Gindin
P.S. - The above suggestion is mine, and not necessarily that of my
employer.

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
pkix <at> ietf.org
https://www.ietf.org/mailman/listinfo/pkix

Gmane