Subject: [pkix] Fwd: New Version Notification for draft-hamilton-cmr-00.txt

From: "Kyle Hamilton" <[email-masked]>
Date: Thu, 20 Oct 2011 23:42:25 -0700 (Pacific Daylight Time)

All,

DigiNotar (and its subsequent bankruptcy) is an example of why blacklist-based revocation is a bad idea.  However, Mozilla will not do anything to change its 

I propose that PKIX create a whitelist-based format.

To obtain whitelist CRL processing as inexpensively as possible:

0) Import CRL.
1) Change the initial stream identifier from 1 to 3.
2) Change default processing path for unlisted certificates to INVALID or REVOKED.
3) Add entries to the main CRL for issued certificates, with the reasonCode removeFromCrl.

I request that the WG evaluate this and potentially take it up.

Thanks for your time,

-Kyle H

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Thu, Oct 20, 2011 at 9:27 AM
Subject: New Version Notification for draft-hamilton-cmr-00.txt
To: [email-masked]
Cc: [email-masked]

A new version of I-D, draft-hamilton-cmr-00.txt has been successfully submitted by Kyle Hamilton and posted to the IETF repository.

Filename:        draft-hamilton-cmr
Revision:        00
Title:           Certificate Manifest Register (Certificate Revocation List v4)
Creation date:   2011-10-20
WG ID:           Individual Submission
Number of pages: 6

Abstract:
  In the spirit of simple, incremental improvement, we describe a
  whitelist-based revocation mechanism called the &quot;Certificate
  Manifest Register&quot;.  This is a list of all potentially-valid
  certificates which are (as of the date of production) known to have
  been legitimately issued by the CA and how they are to be treated by
  the client.  This permits certificates which are checked against it
  to be presumed invalid unless listed.

  Several recent events have cast doubt on the sufficiency of
  blacklist-based PKIX certificate revocation mechanisms.  At least
  one publicly-trusted Certification Authority was recently found to
  have been penetrated by a state-backed attacker, which issued itself
  several certificates valid for a particular global web search and
  email provider and then removed the records that it had done so.  In
  effect, the attacker was able to cause the CA to sleepwalk.  There
  was nothing that the client software developers could do to protect
  their users and themselves except remove the trust in that CA&#39;s
  root.  This event directly caused that particular CA&#39;s insolvency.

  The Certificate Revocation List format and definitions (X.509v2 as
  described in RFC 5280, its predecessors, and possibly its
  successors) are used and adapted whole-hog, with no data format
  changes and the alteration of one rule and one semantic to support
  whitelist-based processing.  CMR is defined to use version integer 3
  (v4) to differentiate its processing path from v2 CRL.  The changes
  from the CRL Profile are so minor, though, that they potentially
  might be implemented without a version bump, without disruption to
  current v2 CRL consumers.

The IETF Secretariat

---

From: <[email-masked]>
Date: Fri, 21 Oct 2011 10:27:15 -0400

Hi Kyle,

Thanks for producing this draft. Upon reading it, the most obvious issue
that strikes me is CRL size; if I'm understanding your proposal correctly,
all CAs will be required to generate a very large all-encompassing CRL which
contains all non-expired certificates that have been issued by that CA.
Network bandwidth issues aside (think mobile devices), your proposal would
also require that this large CRL be stored for every CA that the RP trusts.
While delta CRLs will be smaller, they too will still be large since new
delta CRLs will need to continue to be generated daily to reflect newly
issued certificates.

I like the idea of a whitelist, but distributing it via CRLs seems
unmanageable. Would it not be better to propose such an approach using OCSP
instead? 

Thanks,
Walter

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Kyle Hamilton
> Sent: Friday, October 21, 2011 1:42 AM
> To: [email-masked]
> Subject: [pkix] Fwd: New Version Notification for
draft-hamilton-cmr-00.txt
> 
> All,
> 
> DigiNotar (and its subsequent bankruptcy) is an example of why blacklist-
> based revocation is a bad idea.  However, Mozilla will not do anything to
> change its
> 
> 3) Add entries to the main CRL for issued certificates, with the
reasonCode
> removeFromCrl.
> A new version of I-D, draft-hamilton-cmr-00.txt has been successfully
> submitted by Kyle Hamilton and posted to the IETF repository.
> 
> Creation date:   2011-10-20 WG ID:           Individual Submission Number
of
> pages: 6

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 21 Oct 2011 11:41:07 -0400

Hi Kyle,

I have to say that in general I am not a lover of white-listing, mostly because of
Privacy concerns.

It seems to me that what you are proposing is mostly targeted to CAs that are focused
on server certificates. Besides the size of the CRLs and all of the considerations
behind mobile devices, I think the solution does not address the real problem you
posed as a motivation: the inclusion of Trust Anchors in applications and the
inability to dynamically add/remove trust (well.. from the average user perspective!).

Therefore, I think the item should not be a WG item (sorry Kyle).

Best Regards,
Max

On 10/21/2011 02:42 AM, Kyle Hamilton wrote:
> All,
>
> DigiNotar (and its subsequent bankruptcy) is an example of why blacklist-based revocation
> is a bad idea. However, Mozilla will not do anything to change its
> A new version of I-D, draft-hamilton-cmr-00.txt has been successfully submitted by Kyle
> Hamilton and posted to the IETF repository.
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

-- 

tel.718-260-4009 | web: http://member.acm.org/~openca/

Massimiliano Pala, Ph.D.
Director & Founder, OpenCA Labs
Research Professor, NYU Poly
Assistant Director, CRISSP

http://crissp.poly.edu

---

From: "Kyle Hamilton" <[email-masked]>
Date: Sun, 23 Oct 2011 08:20:23 -0700 (Pacific Daylight Time)

> I have to say that in general I am not a lover of white-listing, mostly

Mr Pala,

I'm a privacy activist.  I'm building a system to take what PKIX currently perceives as "privacy" and make it look like the garish spotlight of public attention.

If CAs as a whole body -- meaning every one of them, legion -- could provide the guarantee that they would never screw up or sleepwalk, then CAs could legitimately keep their lists of issued serial numbers private.  Since they can't, the consumer of the service must demand that the CAs do the minimum necessary to ensure that the guarantees that the RP expects from the service can still be provided -- which means that the list of valid serial numbers (and no other part of the certificates involved!) must be made available.

In this case, there is one single action which can be done by every publicly-trusted CA, whole-cloth, with a single and straightforward implementation in every library with no changes to current CRL production/processing, copypasting the CRL code with minimal design and code changes to implement it.  It is minimally-invasive to CA businesses, and most importantly *it provides a means for CAs to prevent themselves from being forced into bankruptcy*.

If CAs wish to obscure the number of real certificates, they would be able to generate a bunch of fake serial numbers with the understanding that they were taking the liability for non-issued serial number collision.  Either way, a bounded set of potential target false serials is much smaller than the unbounded set that currently exists, and is an incremental improvement which can be made.

> on server certificates.

I'm actually suffering a bit of a lack of imagination how it can be used directly in a server-certificate focused system.  Do you seriously think that a new manifest could be issued and distributed to every consumer immediately upon every new certificate issuance?  The only thing that needs that kind of update interval is the CA's own OCSP infrastructure.  Asynchronous messages could be sent with newly-issued credentials and processed after the CMR issuance and distribution caught up.

This is not a replacement for the CRL as it currently exists in every circumstance.  It's not supposed to be.  More than anything else, I need this for client, email, and other non-realtime communications.  But, it actually can improve server-certificate based systems (by feeding OCSP servers which are currently fed by CRLs with additional information that can close gaping barn-doors in the security boundary).

> Besides the size of the CRLs and all of the
> considerations

Uh.  Did you even read my draft?  I don't want to dynamically add or remove trust, I want to be able to handle that all programmatically with more authoritative information than what can currently be obtained via the standards.  I don't want to have to remove trust at all, and I certainly don't think a binary "trusted/untrusted" is sufficient.

This is what brought up the motivation for this: we need some standard to communicate bulk authoritative trust information between CAs and consuming software that doesn't assume that the cryptography, implementation, and human institution behind it all are flawless.  If we ever have subscription CAs (subscribe to a single source of revocation information, for example), they're going to need this.  If we ever have subscription cross-certification CAs (subscribe to a single source of trust and let it do the due diligence about other CAs' CPSes and such), they're going to need this.

It's 2011, so where's my flying car?  We've reached the apparent limit of what can be achieved with the current infrastructure, and there are major flaws and failures which the people who want to keep the current infrastructure static are burying their heads in the sand about.

> Therefore, I think the item should not be a WG item (sorry Kyle).

Incremental improvement.  This is one thing which can be implemented for thousandths or millionths of cents on the dollars already spent on the problem, which will do more than anything else that has already been done, to protect more people and systems than have ever been protected, against more threats than have ever been protected against.

The security that PKIX has engineered up to now is fragile to this class of attacks.  Businesses which are built around providing services in this security space have no security that they will not be forced insolvent if they suffer an attack.  PKIX WG is the body which is supposed to be charged with providing identity and security services to the Internet and all of its participating consumers and service providers.  If we don't act now, the next time that a CA goes insolvent will be on our heads, moreso for the warning we've received.

This highlights a philosophical difference, between making something better and leaving something alone.  I'm all for "if it isn't broke, don't fix it"; however, a cost-benefit analysis suggests that leaving this one alone costs far more than the minimal changes required to improve it.

Think about it this way, for a moment:  A corporation (corporations are people too) formed and existed (was born and lived), which based its entire business model and life around the standards from PKIX.    That corporation, that person, was basically slipped a zolpidem mickey and induced to sign things it never would have signed otherwise, things that it wasn't given or didn't keep a copy of -- and the results of it were that the corporation was taken over (imprisoned) by a state, and then forced into insolvency (killed).

A corporate person died because of PKIX WG's oversight.  Do you want to kill another one, too?

-Kyle H

---

From: Scott Schmit <[email-masked]>
Date: Sun, 23 Oct 2011 13:08:46 -0400

On Sun, Oct 23, 2011 at 08:20:23AM -0700, Kyle Hamilton wrote:
> If CAs as a whole body -- meaning every one of them, legion -- could
> provide the guarantee that they would never screw up or sleepwalk,
> then CAs could legitimately keep their lists of issued serial numbers
> private.  Since they can't, the consumer of the service must demand
> that the CAs do the minimum necessary to ensure that the guarantees
> that the RP expects from the service can still be provided -- which
> means that the list of valid serial numbers (and no other part of the
> certificates involved!) must be made available.

If only the serial number is used to check that the cert is valid or
revoked, what's to prevent an attacker from generating a fraudulent
certificate with a serial number duplicating a legitimate certificate?
Now the whitelist attests to the validity of not only the legitimate
cert, but also the fraudulent ones as well.

Reading your draft, you seem to recognize that that including a hash of
the certificate would be an improvement, but it's not clear to me that
you realize that without it, this change does very little to improve the
RP's security. This proposal neutralizes attackers that are able to get
control of the CA certificate issuance process but cannot control the
serial number. How likely is that? If we make this change, how likely is
it to stay that way?

Also, I don't know that we can make that kind of change without working
with ITU-T to revise X.509. AIUI, they own the X.509 format, the IETF
only profiled it for Internet use. For example, the X.509v2 CRL format
states that the next update field is optional, but RFC 5280 says that
it's required anyway. I would expect that bumping the format number from
v2 to v4 would also require action by ITU-T.

If you want to proceed down this path anyway, then I'd suggest not
altering the v2 CRL format at all. Instead, change the interpretation of
missing information, and alter the protocols that provide or use it
accordingly so that RPs can take advantage of that interpretation.

-- 
Scott Schmit

---

From: [email-masked]
Date: Mon, 24 Oct 2011 10:53:13 +0200

Kyle,

The solution you propose is not adequate to solve the issue: it is 
inappropriate to list  all good certificates using
a CRL structure since the list would be too long.

It is also inappropriate to use the term CRLs to advertise "good" 
certificates since CRLs are for black lists only.

If you want to make some improvements, they could be made on OCSP. 

When reading an OCSP response, it is currently not possible to know what 
source of information was used.
It would be interesting to define a singleExtensions in a SingleResponse 
to signal that the response what picked 
using directly the CA data base rather than simply a CRL and at the same 
time extend the error  response codes 
to add "does not exist".

Denis

De :    Massimiliano Pala <[email-masked]>
A :     [email-masked]
Date :  21/10/2011 17:42
Objet : Re: [pkix] Fwd: New Version Notification for 
draft-hamilton-cmr-00.txt
Envoyé par :    [email-masked]

Hi Kyle,

I have to say that in general I am not a lover of white-listing, mostly 
because of
Privacy concerns.

It seems to me that what you are proposing is mostly targeted to CAs that 
are focused
on server certificates. Besides the size of the CRLs and all of the 
considerations
behind mobile devices, I think the solution does not address the real 
problem you
posed as a motivation: the inclusion of Trust Anchors in applications and 
the
inability to dynamically add/remove trust (well.. from the average user 
perspective!).

Best Regards,
Max

> 3) Add entries to the main CRL for issued certificates, with the 
reasonCode removeFromCrl.
> A new version of I-D, draft-hamilton-cmr-00.txt has been successfully 
submitted by Kyle

-- 

Massimiliano Pala, Ph.D.

http://crissp.poly.edu

---

From: Martin Rex <[email-masked]>
Date: Mon, 24 Oct 2011 17:35:43 +0200 (MEST)

> a CRL structure since the list would be too long.

There is truth in your words, but there are a number of CA
(I know a few operated by the US gov.) that use CRLs far beyond
reasonable sizes ( more than one million certs in the CRL).

A CA should be retired (i.e. not issue new certificates) early enough
so that it will be extremely unlikely that the growth of its CRL
for the already issued certs will not exceed reasonable sizes
(probably 50.000)

But without strong authentication of the certs in CRLs and OCSP
(=certificate hash), the shortcoming that X.509/PKIX can not cope
with disaster recovery and be made to fail remains as a problem.

> certificates since CRLs are for black lists only.

I principle, I agree.

But somehow that particular seems to have already been committed
by X.509/PKIX with the CRLReason "removeFromCRL(8)".  ;-)

> If you want to make some improvements, they could be made on OCSP. 

OCSP when performed by the RP is a serious privacy problem
(unless operating a local OCSP responder that feeds on CRLs,
 but the latter is unable to check against a list of existing
 certs unless there is a standardized format to distribute
 that information...)

-Martin

---

From: <[email-masked]>
Date: Mon, 24 Oct 2011 12:00:52 -0400

> Martin Rex
> Sent: Monday, October 24, 2011 10:36 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [pkix] Fwd: New Version Notification
>
> > inappropriate to list  all good certificates using a CRL structure
> > since the list would be too long.
>
> There is truth in your words, but there are a number of CA (I know a few
> operated by the US gov.) that use CRLs far beyond reasonable sizes ( more
> than one million certs in the CRL).
>
> A CA should be retired (i.e. not issue new certificates) early enough so that it
> will be extremely unlikely that the growth of its CRL for the already issued
> certs will not exceed reasonable sizes (probably 50.000)
>
>
> But without strong authentication of the certs in CRLs and OCSP (=certificate
> hash), the shortcoming that X.509/PKIX can not cope with disaster recovery
> and be made to fail remains as a problem.
>
>
> >
> But somehow that particular seems to have already been committed by
> X.509/PKIX with the CRLReason "removeFromCRL(8)".  ;-)
>
>
> >
> OCSP when performed by the RP is a serious privacy problem (unless
> operating a local OCSP responder that feeds on CRLs,  but the latter is unable
> to check against a list of existing  certs unless there is a standardized format
> to distribute  that information...)
>

Would you care to elaborate on the bit regarding the privacy issues surrounding OCSP? I hear this as a rather constant refrain against the use of OCSP. Is the privacy issue the theoretical mapping that an OCSP responder could do against an RP's IP address, meaning that the OCSP responder could have a time/date stamp along with IP address for sites which a user visits? If so, I don't see how OCSP compromises privacy any more so than a public DNS resolver could. Is there some more fundamental issue that I'm missing?

Thanks,
Walter

---

From: Martin Rex <[email-masked]>
Date: Mon, 24 Oct 2011 18:24:45 +0200 (MEST)

[email-masked] wrote:
> > operating a local OCSP responder that feeds on CRLs,  but the latter
> > is unable to check against a list of existing certs unless there is
> > a standardized format to distribute that information...)
> >
> 
> Would you care to elaborate on the bit regarding the privacy issues
> surrounding OCSP?  I hear this as a rather constant refrain against
> the use of OCSP.  Is the privacy issue the theoretical mapping that
> an OCSP responder could do against an RP's IP address, meaning that
> the OCSP responder could have a time/date stamp along with IP address
> for sites which a user visits?

Correct.  And the user does not have a choice in that OCSP responder,
the CA may choose to operate that OCSP responder in a country that
is very privacy-ignorant.

The only way to migitate this privacy problem would be to locally operate
an OCSP responder that feeds on CRLs (or avoid the OCSP overhead
entirely and work locally on CRLs in a proprietary fashion).

>
> If so, I don't see how OCSP compromises privacy any more so than
> a public DNS resolver could.
> Is there some more fundamental issue that I'm missing?

With DNS you have the freedom of choice whom to ask and there is
no bias towards the cert issuer.  Finding recursive DNS resolver
that operates in a country with reasonable privacy protection
laws that prohibit the DNS server operater to log client IP-Addresses
and what DNS requests they wanted to have resolved is fairly easy.

-Martin

---

From: <[email-masked]>
Date: Mon, 24 Oct 2011 12:41:31 -0400

> From: Martin Rex [mailto:[email-masked]]
> Sent: Monday, October 24, 2011 11:25 AM
> To: Goulet, Walter
> Cc: [email-masked]; [email-masked]; [email-masked]
> > the use of OCSP.  Is the privacy issue the theoretical mapping that an
> > OCSP responder could do against an RP's IP address, meaning that the
> > OCSP responder could have a time/date stamp along with IP address for
> > sites which a user visits?
> 
> Correct.  And the user does not have a choice in that OCSP responder, the
CA
> may choose to operate that OCSP responder in a country that is very
privacy-
> ignorant.
an
> OCSP responder that feeds on CRLs (or avoid the OCSP overhead entirely
> and work locally on CRLs in a proprietary fashion).
> 
> 
> >
> > If so, I don't see how OCSP compromises privacy any more so than a
> > public DNS resolver could.
> With DNS you have the freedom of choice whom to ask and there is no bias
> towards the cert issuer.  Finding recursive DNS resolver that operates in
a
> country with reasonable privacy protection laws that prohibit the DNS
server
> operater to log client IP-Addresses and what DNS requests they wanted to
> have resolved is fairly easy.
> 
> 
> -Martin

I'm still not sure I quite get it since a user could make the same choice
regarding which CA they want to trust. Same goes for site operators that are
buying SSL certificates for their sites; if user privacy is a paramount
concern (for both users and site operators), then shouldn't site operators
simply choose to use CAs which do business in countries with privacy
protection laws? Same for users, if a user is sophisticated enough to find a
recursive DNS resolver that is located in a privacy friendly country then
they will have the means to manually choose which CAs to trust.

That being said, a hybrid solution using Kyle's CMR to generate certificate
whitelists that are only distributed to OCSP responders is a compelling
alternative. By not distributing the very large whitelist CRLs to all
devices but instead distributing them to a smaller subset of OCSP responders
many of the size/network bandwidth constraints are alleviated.

Thanks,
Walter

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 24 Oct 2011 09:59:06 -0700

On Oct 24, 2011, at 9:41 AM, <[email-masked]> <[email-masked]> wrote:

> regarding which CA they want to trust.

Relying parties in multi-CA environments do not get to choose which CA they want to trust.

> Same goes for site operators that are
> protection laws?

Relying parties and site operators often have different privacy models.

> Same for users, if a user is sophisticated enough to find a

Please name a single commonly-used operating system where that statement is true. Editing the list of name servers is easier than even finding (much less editing) the list of trusted CAs in the OSs I am familiar with.

--Paul Hoffman

---

From: <[email-masked]>
Date: Mon, 24 Oct 2011 13:09:50 -0400

> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Monday, October 24, 2011 11:59 AM
> To: Goulet, Walter
> Cc: PKIX
> Subject: Re: [pkix] New Version Notification
> 
> > I'm still not sure I quite get it since a user could make the same
> > choice regarding which CA they want to trust.
> 
> Relying parties in multi-CA environments do not get to choose which CA
they
> want to trust.
> > buying SSL certificates for their sites; if user privacy is a
> > paramount concern (for both users and site operators), then shouldn't
> > site operators simply choose to use CAs which do business in countries
> > with privacy protection laws?
> 
> > Same for users, if a user is sophisticated enough to find a recursive
> > DNS resolver that is located in a privacy friendly country then they
> > will have the means to manually choose which CAs to trust.
> 
> Please name a single commonly-used operating system where that
> statement is true. Editing the list of name servers is easier than even
finding
> (much less editing) the list of trusted CAs in the OSs I am familiar with.
> 
> --Paul Hoffman
> 

Interesting;  I've always thought Firefox for example made it rather simple
to remove CAs from your trust list. On Windows it's a little harder because
of Microsoft's automatic update functionality they use for third party
trusted roots; you'd have to turn off that feature then manually edit your
trust list which, while doable; is certainly not easy. Not sure about Apple
OSs.

Thanks,
Walter

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 24 Oct 2011 14:51:12 -0400

On 10/24/2011 12:24 PM, Martin Rex wrote:
[...]
> entirely and work locally on CRLs in a proprietary fashion).

I would like to add the fact that there's been quite few publication on
the matter. Some good work (although it would be quite difficult to implement
in the current OCSP standard) is from Tsudik [1].

Personally I worked on the matter, never released the software as.. too
many different things to do - but it is possible to actually enhance the
current OCSP requests and responses by obfuscating the requested certificate
identifier (serial number) thus allowing for some privacy for the requester
(eg., n out of m type of privacy).

If people think that an extension to the OCSP standard could be useful
for privacy-preserving (but compatible) OCSP services.. well, I can take
on the task... with some collaborators.. :D

Cheers,
Max

[1] 
http://www.google.com/url?sa=t&rct=j&q=tsudik%20ocsp%20privacy&source=web&cd=4&ved=0CCwQFjAD&url=http%3A%2F%2Fsprout.ics.uci.edu%2Fpapers%2Fprivacy_revocation.pdf&ei=PLOlTuDSJsfm0QGp1vGPBQ&usg=AFQjCNEBDGBBIgt_cTdxdKGrr-9sLXHAIQ&cad=rja

-- 

Massimiliano Pala, Ph.D.

http://crissp.poly.edu
http://www.poly.edu/user/mpala
http://www.openca.org/

---

From: Martin Rex <[email-masked]>
Date: Mon, 24 Oct 2011 21:09:23 +0200 (MEST)

[email-masked] wrote:
> Paul Hoffman wrote:
> > Walter Goulet wrote:
> > finding (much less editing) the list of trusted CAs in the OSs
> > I am familiar with.
> 
> trust list which, while doable; is certainly not easy.

You do not seem to be familiar with any Version of Microsoft Windows
from the 6.x Series (Vista =6.0, Win7= 6.1).

While it is true that with Windows 5.x (XP=5.1, 2003=5.2) it was
possible to see *ALL* of your trustanchors and disable automatic
updating for that list, both of these are gone in Vista an later.

You simply don't know which trust anchors there are in Vista an
Win7 because the trust anchor certificates are not preloaded and
only downloaded on the fly when needed.  Deleting a trust anchor
will not get you anywhere, it will be automatically downloaded
again.  If you want to get rid of a TrustAnchor, you'll have
to obtain the certificate and add it to the "Untrusted Certs"
list.  But how could that scheme work if you do not have the
slighest idea how large that Microsoft-maintained dynamic
Trust universe is, and which three letter agencies besides
Microsoft have to power to make your Windows machine trust
a CA of their choice whenever they see it fit.

With respect to selecting a recursive DNS resolver that does not
violate your privacy: for a home DSL subscription where I live,
you typically get an IP Address of a recursive DNS resolver
conveyed through DHCP.  So for a number of users living in
jurisdiction with reasonable privacy protections by law, there
is no additional configuration required, it just works.

-Martin

---

From: <[email-masked]>
Date: Mon, 24 Oct 2011 15:30:41 -0400

> Sent: Monday, October 24, 2011 2:09 PM
> To: Goulet, Walter
> Cc: [email-masked]; [email-masked]
> > > > recursive DNS resolver that is located in a privacy friendly
> > > > country then they will have the means to manually choose which CAs to
> trust.
> > >
> > > statement is true. Editing the list of name servers is easier than
> > > even finding (much less editing) the list of trusted CAs in the OSs
> > > I am familiar with.
> >
> > Interesting;  I've always thought Firefox for example made it rather
> > simple to remove CAs from your trust list. On Windows it's a little
> > harder because of Microsoft's automatic update functionality they use
> > for third party trusted roots; you'd have to turn off that feature
> > then manually edit your trust list which, while doable; is certainly not easy.
>
> You do not seem to be familiar with any Version of Microsoft Windows from
> the 6.x Series (Vista =6.0, Win7= 6.1).
>
> While it is true that with Windows 5.x (XP=5.1, 2003=5.2) it was possible to
> see *ALL* of your trustanchors and disable automatic updating for that list,
> both of these are gone in Vista an later.
>
> Win7 because the trust anchor certificates are not preloaded and only
> downloaded on the fly when needed.  Deleting a trust anchor will not get
> you anywhere, it will be automatically downloaded again.  If you want to get
> rid of a TrustAnchor, you'll have to obtain the certificate and add it to the
> "Untrusted Certs"
> list.  But how could that scheme work if you do not have the slighest idea
> how large that Microsoft-maintained dynamic Trust universe is, and which
> three letter agencies besides Microsoft have to power to make your
> Windows machine trust a CA of their choice whenever they see it fit.
>
>
> With respect to selecting a recursive DNS resolver that does not violate your
> privacy: for a home DSL subscription where I live, you typically get an IP
> Address of a recursive DNS resolver conveyed through DHCP.  So for a
> number of users living in jurisdiction with reasonable privacy protections by
> law, there is no additional configuration required, it just works.
>
>
> -Martin

No no, I'm quite familiar with how Windows Vista and later manage their trust stores; I've had some painful conversations with customers trying to explain why or why not a particular root is not present on their Windows boxes. The differences between earlier versions of Windows and the later versions caused me many customer management headaches when setting up enterprise PKI deployments. My short reply obviously didn't convey this clearly enough.

But rather than arguing this point (and after a very illuminating lunch conversation on this topic with a non-technologist), I see the potential privacy issues with OCSP and why they are not simple fixes.

---

From: [email-masked]
Date: Tue, 25 Oct 2011 09:43:28 +0200

Martin,

You said:

"While it is true that with Windows 5.x (XP=5.1, 2003=5.2) it was
possible to see *ALL* of your trustanchors and disable automatic
updating for that list, both of these are gone in Vista an later.

list."

Although it is a little bit outside the core discussion, would it be 
possible that you give pointers 
to MS technical papers which tell more about this ?

It seems that the new "trust model" from MS is no more adequate, ... which 
is quite a problem.

Denis

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Oct 2011 08:17:09 -0400

>reasonable sizes ( more than one million certs in the CRL).

true, but these are examples of bad system design, not a 
justification for very large CRLs.

>for the already issued certs will not exceed reasonable sizes

That's a very odd suggestion. The usual suggestion is that one should 
manage the cert lifetimes to keep the CRL size manageable. (This 
assumes a fill CRL, not
taking advantage of any of the schemes that break a CRL into smaller pieces.)

>with disaster recovery and be made to fail remains as a problem.

What do you mean by "... strong authentication of the certs in CRLs..." A CRL
does not contain a cert, pere se.

>...

Well, almost. One first revokes a cert, then declares a Mulligan via 
this extension.  There is no reason code that says "I didn't really 
revoke it; I just wanted to whitelist it later" :-). RemoveFromCRL is 
a good an idea as cert on hold, IMHO.

>  certs unless there is a standardized format to distribute

I agree that there are potential privacy issues, but use of a local
responder is a viable alternative, as you noted.  If privacy were
viewed as a bigger concern, we'd see such responders offered by
folks analogous to the way that TOR nodes are operated.

The more relevant issue, is that we have SCVP as a query protocol
to determine cert status, not just revocation status, so OCSP is
not the preferred approach anyway.

Steve

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 25 Oct 2011 12:24:31 +0000

On 10/25/11 2:43 AM, "[email-masked]" <[email-masked]> wrote:
>Although it is a little bit outside
>the core discussion, would it be possible that you give pointers

http://technet.microsoft.com/en-us/library/cc751157.aspx

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 25 Oct 2011 12:27:00 +0000

>taking advantage of any of the schemes that break a CRL into smaller

... Or at least learn why revocations appear excessive and make
administrative or business process changes to eliminate unnecessary
sources.

-- T

---

From: [email-masked]
Date: Tue, 25 Oct 2011 15:27:53 +0200

Steve,

You said:

SCVP does not guaranty in anyway that the certificate exists.
OCSP is much simpler than SCVP and is, IMO, the preferred approach.

Denis

De :    Stephen Kent <[email-masked]>
A :     [email-masked]
Cc :    [email-masked]
Date :  25/10/2011 14:17
Objet : Re: [pkix] Fwd: New Version Notification
Envoyé par :    [email-masked]

That's a very odd suggestion. The usual suggestion is that one should 
manage the cert lifetimes to keep the CRL size manageable. (This 
assumes a fill CRL, not
taking advantage of any of the schemes that break a CRL into smaller 
pieces.)

>with disaster recovery and be made to fail remains as a problem.

What do you mean by "... strong authentication of the certs in CRLs..." A 
CRL
does not contain a cert, pere se.

Steve

---

From: "Liaquat Khan" <[email-masked]>
Date: Tue, 25 Oct 2011 14:44:37 +0100

I wouldn’t say OCSP is preferred approach compared to SCVP, any more than
SCVP is preferred approach compared to OCSP.  

They are trying to meet different needs, i.e. one is certificate revocation
checking only whilst other is full certificate path building and validation.

I agree with Denis though that SCVP doesn’t necessarily require that the
SCVP server much check that the certificate was actually issued by the CA in
a legitimate way.   Of course SCVP server could be made to check this was
the case by comparing what is the CA database, but as far my understanding
is this is outside the scope of the actual protocol.   In case of OCSP it’s
only the serial number that the OCSP responder has to go by, and it can only
check this serial number in the CA database (as opposed to the full
certificate).   So in this respect SCVP can be said to be “better” than
OCSP,  probably this is what Steve was also referring to.   To be honest in
a real-world I doubt many SCVP servers will actually have access to the CAs
databases, since they will probably be owned and operated by separate entity
to the CA(s).  

Regards

Liaquat

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 25 October 2011 14:28
To: [email-masked]
Subject: Re: [pkix] Fwd: New Version Notification

Steve, 

You said: 

Denis 

  _____  

Steve
_______________________________________________
pkix mailing list
[email-masked]
 <https://www.ietf.org/mailman/listinfo/pkix>
https://www.ietf.org/mailman/listinfo/pkix

---

From: <[email-masked]>
Date: Tue, 25 Oct 2011 10:49:29 -0400

> Miller, Timothy J.
> Sent: Tuesday, October 25, 2011 7:25 AM
> To: [email-masked]; [email-masked]
> >the core discussion, would it be possible that you give pointers to MS
> >technical papers which tell more about this ?
> 
Also http://technet.microsoft.com/en-us/library/bb457160.aspx which
describes the automatic root certificate update component that was introduce
in Windows XP.

---

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 25 Oct 2011 09:06:39 -0700 (Pacific Daylight Time)

>> > > If you want to make some improvements, they could be made on OCSP.

How?  This format, or something like it, is necessary to feed the OCSP server.

> entirely and work locally on CRLs in a proprietary fashion).

This is the fundamental problem, because CRLs rely upon the issuing CA having not sleepwalked.  There is simply no current way to transmit a register of valid serial numbers, or a register of valid hashes, or a register of anything other than "we know that this serial number is bad".

I recognize that there are major issues, including a lack of strong authentication for the certificates in question.  I'm wondering if a CRL extension could be allocated to contain hashes for all valid certificates (plus however much slop for CAs to obscure their enrollment numbers).

"Incremental improvement", not "perfection or bust".  If we can do this as a first step to making something better, we'll be far better off than we are now.  Frankly, I don't think that there's any need or 

> and what DNS requests they wanted to have resolved is fairly easy.

I should also point out that users routinely send their keystrokes to Microsoft and Google for as-you-type suggestions.  That kind of service is much more privacy-invasive, but also much more useful.

-Kyle H

---

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 25 Oct 2011 09:20:09 -0700 (Pacific Daylight Time)

> a CRL structure since the list would be too long.

By definition, a whitelist is a list of all good certificates, period.  No matter how long you think the list would be, it must be that big to function as a whitelist, period.

Let's do some math:

Average size of a DER-encoded SHA-1 digest: 20 bytes

Average size of a serial number: CAcert does 3 bytes, including the leading 00 byte.  StartCom does 2 bytes (just look at my signing certificate).

Average size of a 3-byte serial number on a CRL: 7 bytes (TLV for the sequence, the integer serial number, the one-byte integer reasonCode)

No matter what you might think, distributing valid certificate serial numbers is smaller than distributing valid certificate digests, and distributing valid certificate serial numbers via the mechanism that's already got a "removeFromCrl" reasonCode is cheaper than trying to define a full new way.

I'm also suggesting that it not even be processed through the CrlIssuers extension.  Did you read the draft at all, particularly the IANA Considerations section?

> certificates since CRLs are for black lists only.

This is why I'm calling it "Certificate Manifest Register".

> If you want to make some improvements, they could be made on OCSP.

No, they can't.  Something like this is required, to be able to feed non-issuing OCSP responders.

> source of information was used.

Right.  That's not in-scope of this draft, as this draft solely treats CRL/CMR.

> It would be interesting to define a singleExtensions in a SingleResponse to
> signal that the response what picked

I await your I-D on this, and how to transfer information from the issuing CA to the relying party's OCSP responder.

Note that a CRL-fed responder would never be able to answer anything other than "does not exist".

-Kyle H

---

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 25 Oct 2011 09:28:30 -0700 (Pacific Daylight Time)

> cert, but also the fraudulent ones as well.

The fact that publicly-trusted CAs have all implemented at least 20 bits of entropy in the TBSCertificatev1 structure, most often in the serial number but sometimes in other places.

But it's also important to realize that putting out a whitelist makes it possible to change from an "unknown unknown" to a "known unknown".  With a whitelist, if a fraudulent certificate is detected with any serial number, it can be easily changed.  But, without the whitelist, the number of potentially-valid serial numbers is 2 to the power of 160 minus however many exist on the blacklist.

> serial number. How likely is that? If we make this change, how likely is

It's so likely that it's already happened.

> v2 to v4 would also require action by ITU-T.

First, you assume that IETF and ITU-T are the only bodies which are trying to do anything for user security.  There is also the CA/Browser Forum, which has specified and led to the implementation of the aforementioned 20 bits of entropy.

The ITU has screwed this up already, do we really want them to screw Internet security up that much more?  Also, do we want to deal with the 5-year turnaround on any ITU-T recommendation update?

> accordingly so that RPs can take advantage of that interpretation.

I initially thought of that, but then I realized that NSS is insanely pedantic to the point of every MUST being checked.  It will most likely choke on a v2 CRL that isn't a delta CRL that contains serials with the reasonCode removeFromCrl (0x80).

-Kyle H

---

From: Trevor Freeman <[email-masked]>
Date: Tue, 25 Oct 2011 20:55:34 +0000

Hi Martin,

If you want details on the Microsoft root CA program and how it works, it's published here http://support.microsoft.com/kb/931125 There is a link to the current list of third party root CAs. 

It is a windows group policy setting to turn on\off third party root CA trust. You can find the node under security settings\public key policies\certificate path validation settings.

Trevor 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Monday, October 24, 2011 12:09 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] New Version Notification

[email-masked] wrote:
> > > country then they will have the means to manually choose which CAs to trust.
> > 

You do not seem to be familiar with any Version of Microsoft Windows from the 6.x Series (Vista =6.0, Win7= 6.1).

While it is true that with Windows 5.x (XP=5.1, 2003=5.2) it was possible to see *ALL* of your trustanchors and disable automatic updating for that list, both of these are gone in Vista an later.

You simply don't know which trust anchors there are in Vista an
Win7 because the trust anchor certificates are not preloaded and only downloaded on the fly when needed.  Deleting a trust anchor will not get you anywhere, it will be automatically downloaded again.  If you want to get rid of a TrustAnchor, you'll have to obtain the certificate and add it to the "Untrusted Certs"
list.  But how could that scheme work if you do not have the slighest idea how large that Microsoft-maintained dynamic Trust universe is, and which three letter agencies besides Microsoft have to power to make your Windows machine trust a CA of their choice whenever they see it fit.

With respect to selecting a recursive DNS resolver that does not violate your privacy: for a home DSL subscription where I live, you typically get an IP Address of a recursive DNS resolver conveyed through DHCP.  So for a number of users living in jurisdiction with reasonable privacy protections by law, there is no additional configuration required, it just works.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 25 Oct 2011 23:09:48 +0200 (MEST)

Stephen Kent wrote:
> Martin Rex wrote:
> > for the already issued certs will [...] exceed reasonable sizes
> > (probably 50.000)
> 
> manage the cert lifetimes to keep the CRL size manageable.
> (This assumes a fill CRL, not taking advantage of any of the schemes
>  that break a CRL into smaller pieces.)

To me it looks like the idea
"manage the cert lifetimes to keep the CRL size manageable"
fails badly in practice.  At best for the limited use of pure online
authentication.

If checking of a digital signature some time into the past is desired,
then one needs to carry along expired certs on the CRL basically
forever (you also need that to be able to revoke a cert after
it has expired (in case that you notice that it has been compromised
only after the certificate has expired).

There are also schemes involving offline operation and verification
of digital signatures by X.509 certs where you have to archive the
CRL used in the verification along with the document as evidence
individually for each transaction.  The storage requirements are
huge when such a CRL is 20+ MBytes.

Really, I think that a CA (i.e. that specific issuer DName) should
be retired when the expected growth of the CRL during the remaining
lifetime of all certs signed with the issuer DName exceeds a
reasonable size.

> What do you mean by "... strong authentication of the certs in CRLs..."
> A CRL does not contain a cert, pere se.

The idea of X.509 CRLs is based on a number of assumptions which were
proven to be flawed by the DigiNotar CA compromise.  The primary
problem is that its designers did not account for disaster recovery
at all, i.e. the possibility that an attacker might succeed to have
arbitrary certificates signed by the CA key and destroy audit/logs
about issuance of these certs (like certs with attacker-chosen
attributes, duplicate serial numbers of previously issued certs, 
omission of CRL-distribution points or OCSP-AIA extensions, or
potentially attributes such as BasicConstraint cA=TRUE)

In the DigiNotar case, the only solution after the hack was to kill
the entire PKI surrounding that CA as fast as possible, which means
having to re-issue credentials to *ALL* current certificate holders
in extremely short time and no real transition period available.

If there was a central database of previously issued, known-safe
certificates on backup, something which is normally available for desaster
recovery, then it would be possible to tell known-good and unknown
(likely fake) certs reliably apart based on their certificate hash
even without the slightest knowledge about how many and which fraudulent
certs had been issued.  The certificate serial number is unreliable
for telling those certs apart.  If you don't know which certs the
attacker managed to craft, you don't know whether he re-used existing
serials and which of them.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 26 Oct 2011 02:57:36 +0200 (MEST)

> potentially attributes such as BasicConstraint cA=TRUE)

Actually, the attacker might have issued himself a CRLsigner cert
and inserted his own CRL-Distribution points of OCSP-AIA extensions
into his fraudulent certs.  So conveying such information through
the cert itself rather than through CA cert seems to open another
can of worms.

-Martin

---

From: Tom Gindin <[email-masked]>
Date: Tue, 25 Oct 2011 22:08:47 -0400

Walter:

        You could do what Kyle suggests by partitioning the CRL using CRL 
Distribution Points.  Indeed, it would be unworkable to do so without them 
for the reasons you point out.  Likewise, only server certificates would 
need to go on those whitelist CRL's.
        My issue is simpler, and I don't see that anyone has raised it. 
Does the problem of compromised RA's get solved in this way?  Unless the 
semantics of CRL Distribution Point allow the CA to say "don't accept this 
certificate without accessing the CRL", those browsers which accept 
servers without revocation checking will continue to do so.  If those 
semantics do permit a certificate to demand checking (whether by adding a 
new flag or by redefining critical on the CRL DP extension to imply that), 
whitelist is hardly necessary.
        Of course, we can most simply let CA's demand revocation checking 
by adding a new critical extension called "Untrustworthy without 
revocation check", whose value is an enumeration consisting of getCRL, 
useOCSP, getSomeStatus.  The problem is that all existing browsers will 
reject that certificate and so no CA's will issue such certificates by 
default for several years.  Thus, it would probably be more practical to 
ask browsers to interpret CRLDP critical as meaning "if you can't get the 
CRL, reject this cert".  Is that legitimate?

Tom Gindin

From:   <[email-masked]>
To:     <[email-masked]>
Cc:     [email-masked]
Date:   10/21/2011 10:28 AM
Subject:        Re: [pkix] Fwd: New Version Notification for 
draft-hamilton-cmr-00.txt
Sent by:        [email-masked]

Hi Kyle,

Thanks for producing this draft. Upon reading it, the most obvious issue
that strikes me is CRL size; if I'm understanding your proposal correctly,
all CAs will be required to generate a very large all-encompassing CRL 
which
contains all non-expired certificates that have been issued by that CA.
Network bandwidth issues aside (think mobile devices), your proposal would
also require that this large CRL be stored for every CA that the RP 
trusts.
While delta CRLs will be smaller, they too will still be large since new
delta CRLs will need to continue to be generated daily to reflect newly
issued certificates.

I like the idea of a whitelist, but distributing it via CRLs seems
unmanageable. Would it not be better to propose such an approach using 
OCSP
instead? 

Thanks,
Walter

> 2) Change default processing path for unlisted certificates to INVALID 
or
> REVOKED.
reasonCode
of
>   current v2 CRL consumers.

[attachment "smime.p7s" deleted by Tom Gindin/Watson/IBM] 
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Simon Tardell <[email-masked]>
Date: Wed, 26 Oct 2011 10:01:03 +0200

On Tue, Oct 25, 2011 at 23:09, Martin Rex <[email-masked]> wrote:

> forever

That is one way. Another way would be to save the CRL (or OCSP response)
that was current at the time of the signature creation.

at all, […]

I agree, but…given DigiNotar's screwup, would you trust that they had their
database of issued certificates in order? What about an attack that managed
to insert the fraudulent certificates into the database in a way that they
could not be separated from the good ones without quite some effort? I don't
think it is a stretch of mind to imagine that.

Being a customer of a CA, you should have your own disaster recovery plan.
What if your CA does a DigiNotar? Have a backup certificate for your keys,
so that you can rollover. It is a simpler, more resilient solution to the
same problem.

Simon Tardell,
Technology Nexus.

---

From: Martin Rex <[email-masked]>
Date: Wed, 26 Oct 2011 13:59:33 +0200 (MEST)

> that was current at the time of the signature creation.

No, you normally have to save the CRL at the time of _verification_.

If your scenarios involve something like an rfc3161 timestamp, then
you _do_ want to use the current CRL at the time of verification,
but query about the certificate status for the rfc3161 timestamp
rather than for the certificate status at the time of signature
verification.

> I agree, but given DigiNotar's screwup, would you trust that they had
> their database of issued certificates in order? What about an attack
> that managed to insert the fraudulent certificates into the database
> in a way that they could not be separated from the good ones without
> quite some effort? I don't think it is a stretch of mind to imagine that.

That applies _only_ to the _online_ database.  You can still trust
the backups going some time back, this is exactly why you ought to
perform disaster recovery after a breakin.

You go back in time with sufficient safety margin and then audit
all transaction records in newer backups for their accuracy.

> so that you can rollover. It is a simpler, more resilient solution to the

Except that it doesn't work with existing hardware and software and
probably noone is doing it...

-Martin

---

From: Simon Tardell <[email-masked]>
Date: Wed, 26 Oct 2011 14:34:31 +0200

> rather than for the certificate status at the time of signature

The assumption here was that you verify the signature shortly after the
creation (to minimize the risk that something bad happens in the meantime),
and thereafter you rely on information that was available at that time (plus
any timestamps on timestamps on timestamps…).

> all transaction records in newer backups for their accuracy.

Which could take some time, during which you can't use the CA at all.

> probably noone is doing it...

It doesn't require any special software at all. Just replace the server cert
with one from another CA that you have already prepared.

It would of course be nice if the client could send its list of accepted CAs
to the server as part of the SSL handshake to make it more magic, but I
believe we are in the wrong wg for that… (I could think of a few more
mechanisms that would achieve the same thing, but would preserve the
handshake protocol, still outside of the scope of this group; however, I
believe that the general idea, redundancy, is the only viable way to
mitigate the DigiNotar type threat)

/Simon

---

From: Tomas Gustavsson <[email-masked]>
Date: Wed, 26 Oct 2011 16:41:40 +0300

> rather than for the certificate status at the time of signature

<snip>

Martgin, I think this is incorrect (all depending on your specific use
case of course). When verifying a digital signature you are often more
interested in seeing if the certificate was revoked _at the time of
signature creation_, than if it is revoked now.
Especially so when talking about long term signatures, i.e. something
that can be archived. In these cases you are not interested if the
certificate is expired or revoked _now_, because you want to know if the
signed document is valid, i.e. if it was properly signed back then.

Archiving specifications do this. Something as easy as PDF signatures
cater for both embedding CRLs and/or OCSP responses when you sign the
document. With this information embedded you can verify the document at
any time in the future without relying on CAs still being around and
uncompromised, or something as silly as keeping all expired certificates
in CRLs.

Cheers,
Tomas

---

From: <[email-masked]>
Date: Wed, 26 Oct 2011 10:17:02 -0400

> From: Tom Gindin [mailto:[email-masked]]
> Sent: Tuesday, October 25, 2011 9:09 PM
> To: Goulet, Walter
> Cc: [email-masked]; [email-masked]
> Subject: Re: [pkix] Fwd: New Version Notification for draft-hamilton-cmr-
> 00.txt
> 
>         Walter:
> 
> Does the problem of compromised RA's get solved in this way? 

Compromising a RA is simply another way to get a CA to issue false certificates; and if revocation is used properly then I'm not sure why traditional blacklist based CRLs would work. As long as the CA is aware of the breach I don't see why the CA can't issue updated CRLs to revoke certs issued by the compromised RA.

>         Of course, we can most simply let CA's demand revocation checking by
> adding a new critical extension called "Untrustworthy without revocation
> check", whose value is an enumeration consisting of getCRL, useOCSP,
> getSomeStatus.  The problem is that all existing browsers will reject that
> certificate and so no CA's will issue such certificates by default for several
> years.  Thus, it would probably be more practical to ask browsers to interpret
> CRLDP critical as meaning "if you can't get the CRL, reject this cert".  Is that
> legitimate?
> 
> Tom Gindin

I don't believe such an approach is legitimate because I don't think it solves the core problem of forcing browsers to implement hard fail. The issues with hard fail (primarily discussed in context of OCSP hard fail) appear to be privacy (discussed earlier) and availability. That is, availability of OCSP responders maintained by CAs directly impacts the availability of SSL protected websites; if a large CAs OCSP responders fail then all sites using certificates issued by that CA are unavailable. As I understand it from discussions within the browser community, unless these issues were to be sufficiently addressed we are unlikely to see hard fail implemented.

Thanks,
Walter

---

From: Martin Rex <[email-masked]>
Date: Wed, 26 Oct 2011 19:09:42 +0200 (MEST)

Simon Tardell wrote:
> 
> Martin Rex <[email-masked]> wrote:
> >
> > Simon Tardell wrote:
> > >
> > > Martin Rex <[email-masked]> wrote:
> > > >
> and thereafter you rely on information that was available at that time
> (plus any timestamps on timestamps on timestamps).

The point in time where you verify a digital signature is extremely
dependent on the usage scenario, and "verify signature shortly after
the creation" basically only exists for purely online-connected
scenarios, and does not work at all for offline/disconnected scenarios.

If a digital signature is for some singular transaction, then you
typically check revocation at the time of processing that transaction
and verifying the signature for the time current time, and then you
have to archive the CRL that you used during that verification
in your audit/accounting logs.

If a digital signature is for something that is for multiple use,
either some kind of capability/privilege/authorization, then
your typically checking revocation each time you process the
signed data with the current CRL for the current time, and the
time of signature creation may be quite some time in the past.

And if the digital signature is used e.g. for signing code and
with an rfc3161 (or similar) timestamp, then you want to check
the current CRL at the time of processing, but for the point
in time of the secure timestamp rather than the current time.

Not carrying through expired certs in current CRLs and not being
able to revoke certs after expiration creates serious problems for
a number of usage scenarios, so IMHO, limiting CRL size by
short certificate lifetimes works only for limited-purpose CAs.

> Which could take some time, during which you can't use the CA at all.

Just a short time, less than 12 hours.  I talking about real desaster
recovery, not any kind of desaster memorial.

The "could take some time" would apply solely to very recently issued
certs that need to be confirmed through audit before being reinserted
into the last-known-good backup.

> > > What if your CA does a DigiNotar? Have a backup certificate for
> > > your keys, so that you can rollover. It is a simpler, more resilient
> > > solution to the same problem.
> >
> It doesn't require any special software at all. Just replace the server
> cert with one from another CA that you have already prepared.

Having to manually re-personalize every holder of a certificate from the
CA is a *HUGE* effort, and I do not think that having those lying around
is very common.

How many companies provide PKI credentials (soft or hard) to their employees?
And how many of those companies create *two* PKI credentials for *every*
employee upfront so that they can "switch" when something bad happens?
(and have up-to-date ACLs for both of them on all their systems).

I know several of the former, but exactly none of the latter.

What are the desasters for which you should plan a very quick desaster
recovery probably depends on the primary purpose of your business.

The primary purpose of a CA should be trust and availability, so the
desasters for which they should plan for quick desaster recovery is
availability/connectivity and security breaches of their infrastructure
and operational procedures.  If that is not what your planning for to
recover from quickly, then maybe you should not be in the CA business.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Oct 2011 13:31:14 -0400

>fails badly in practice.  At best for the limited use of pure online

Online auth is the principle use for certs today; NR apps are a 
special case. More to the point, the discussion here is motivated by 
online auth, so ...

>only after the certificate has expired).

There are at least two models. One calls for a CA to maintain an 
ever-growing list of expired, revoked certs on CRLs.  The other calls 
for RPs to acquire and retain CRLs and CA certs needed to establish 
the validity of an EE cert at the time of a transaction. The latter 
model closely parallels what we do in the physical world, and teh 
LTANS WG produced specs that support this model. I think the first 
model is an unreasonable burden on CAs, and other RPs, so I always 
advise client to not follow that model.  It is also fair to say that 
X.509 did not intend the first model, i.e., the default practice is 
to remove expired certs from CRLs.

>huge when such a CRL is 20+ MBytes.

but, as i said earlier, is the result of poor cert lifetime management.

>lifetime of all certs signed with the issuer DName exceeds a

One could do that, but it's not consistent with baseline assumptions for CA
operation, and it's not needed.

>proven to be flawed by the DigiNotar CA compromise.

I do not agree. The DigiNotar compromise fallout was a result of poor practices
that are outside the scope of standards.

>  The primary

Details such as audit trails are outside the scope of X.509 and PKIX 
specs. They are the province of CPs and CPS's.

>in extremely short time and no real transition period available.

The price a CA pays for poor security controls, and the price 
Subjects pay for choosing a poorly managed CA.

>serials and which of them.

A "central database" for all CAs is infeasible, as it would have to 
span an unknown number of CAs, sub-CAs, etc. Each CA is responsible 
for its own disaster recovery. It is inappropriate to burden all CAs 
with a privacy-insensitive solution to a per-CA problem.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Oct 2011 13:31:21 -0400

>OCSP is much simpler than SCVP and is, IMO, the preferred approach.

The DPV function of SCVP validates a target cert. So, the result 
should be equivalent to a white list, in the normal case. If there 
has been a CA compromise, then bogus certs may be issued, and SCVP 
would not detect them
as bogus. But, the same is true for a white list, i.e., the attacker could
issue a new white list and make it available to targeted clients. the details
of the attack would be different, but the bottom line is the same.

If there is an RA compromise, but not a CA compromise, then SCVP will
not detect the bogus cert until the CA/RA detects the compromise, 
But, here too, the CA would presumably have updated the white list to 
include the
bogus certs, so the effect is the same.  In both cases, when the compromise
is detected, the bogus certs can be revoked, or de-white listed, IF 
the CA knows which ones were issued.  That, as Martin and I have 
debated, is a matter of
local good housekeeping, and outside the scope of IETF (and ITU-T) standards.

So, I am not persuaded, so far, that a white list approach offers any 
substantial benefits over use of existing protocols. It also creates 
all
the problems of vert large CRLs, which we really do not want to perputate.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 26 Oct 2011 14:30:41 -0400

>in your audit/accounting logs.

yes, this is the typical NR scenario. Before committing to the
signed doc, verify the sig chain, verify cert status up the chain, time stamp
and archive the data, and proceed.

>time of signature creation may be quite some time in the past.

this is the typical auth scenario. but, this has no implication for
keeping expired certs on a CRL, so why is this relevant to the discussion?

>in time of the secure timestamp rather than the current time.

I am not familiar with code signing and 3161 time stamps being used together.
A 3161 timestamp is usually used for NR contexts, and code signing is
usually an auth/integrity context.

>short certificate lifetimes works only for limited-purpose CAs.

I don't see how the paragraph above is supported by the examples
you cited. real time auth and NR based on timestamped, archived
certs and CRLs do not require CRLs to carry expired cert info.

Steve

---

From: Martin Rex <[email-masked]>
Date: Thu, 27 Oct 2011 14:29:26 +0200 (MEST)

Tomas Gustavsson wrote:
> Martin, I think this is incorrect (all depending on your specific use

You can not trust the signing time at all, because that time is self-asserted
by the signer.  What you can trust is either the current time (from a locally
trusted time source) and the timestamp from a trusted timestamping service.

The only CRL for which it seems to be standardized how to get it
is the *currently* valid CRL.  If expired certs are removed from the
CRL, you run in a lots of undefined protocol areas.

  - when do get certs removed from the CRL after they have expired ?
  - what do you do with certs where you determine their compromise
    only after they've expired ?
  - how do you determine which past CRL (number/id) you would need
    to query (in case that expired certs get removed from the CRL) ?
  - how do you obtain specific past CRLs?

As soon as you add usage scenarios with timestamps, you need to carry
certs on the CRL forever or you get completely unpredictable behaviour
for you software because of the undefined situations.

> signed document is valid, i.e. if it was properly signed back then.

On the contrary -- you want to know whether the cert is revoked _now_,
because the only well-defined scheme in the existing protocols to
obtain the exact point in time when a cert was revoked is to query
the *current* CRL for the revocationDate and invalidityDate for this
cert.

It is not uncommon that certificate compromises (and more so misissued certs)
are detected, reported and revoked *after* the compromise (or missisue),
and it could be that it is only detected, reported and revoked several
CRL generations after a fraudulent signature has been created.

> uncompromised, or something as silly as keeping all expired certificates

While you can not undo actions that happened in the past, you very probably
want to have the revocation show up on every future signature verification
that authorizes continued or additional resource access or privileges.

For the purpose of accounting, you archive the initial signature verification
along with then current CRL that was used.  But if it is something
like a lease rather than a sale, you might be repeating the verification
at later times, and then with the _new_ CRL, even when checking against
the point in time when the contract was originally verified and established.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Thu, 27 Oct 2011 14:42:43 +0200 (MEST)

> Subjects pay for choosing a poorly managed CA.

I think you're greatly oversimplifying the situation.  I assume
that they had passed the relevant audits.  What came as a suprise
was not that subverting the CA was possible, I'm pretty confident
that can be done to all CAs of the TLS X.509 PKI.  What came as
a suprise was that such a thorough compromise was doable entirely
remotely, with no need for physical access to anything.  And this
is the only detail where I assume (acutally HOPE) that other CAs
might differ (or at least will try differ for the future).

> with a privacy-insensitive solution to a per-CA problem.

I'm sorry if my terminology was confusing.  That is not what I meant.

I was refering to a central database for *each* CA, a database that is
populated for each issued cert.  That central database should be
accessible to the OCSP responder of the CA and to the RAs for the CA.
(RAs will have to check for duplicate public keys, which they ought
 to refuse unless it's a clear renewal of an existing cert).

It's up to the CA operater whether they share an OCSP responder
or database for several distinct issuer DNames.

-Martin

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 27 Oct 2011 17:58:50 +0300

> the *current* CRL for the revocationDate and invalidityDate for this

It is well described and standardized in several papers and document
formats how should work and why. I guess you know PAdES for example
(http://en.wikipedia.org/wiki/PAdES)?

Keeping expired certificates on CRLs is imho an example of plugging a
square peg into a round hole.

Regarding existing protocols, most protocols are really tuned to reject
expired certificates. No need to do revocation checking. And if you are
doing something more exotic anyhow (like long term validation), I think
it's better stick to one of the established standards that has been
around for ages now.

There are many ways to solve problems, and many ways tries to do it by
inventing something unlimitedly expensive to maintain. I am afraid that
this falls into that category.

Cheers,
Tomas

---

From: Martin Rex <[email-masked]>
Date: Thu, 27 Oct 2011 17:35:54 +0200 (MEST)

> (http://en.wikipedia.org/wiki/PAdES)?

No, I don't know anything about those, but they must be irrelevant.

> square peg into a round hole.

No, it isn't.

Scenario: you get some data and a PKCS#7 or CMS detached SignedData
for it along with an rfc3161 timestamp from a trusted time stamping
service.  The PKCS#7 includes the entire certificate chain of the
signer.  The timestamp is 3 years old and the signer cert expired
2.5 years ago.

How do you verify that based on the PDUs that you get
(PKCS#7 or CMS SignedData with RFC3161 timestamp, a chain of X.509v3
certs with CRLDistributionPoints in them).

And if verification of that old signature is meaningful to you at
all, then you ABSOLUTELY want to know if that signer cert, which
expired 2.5 years ago, had been determined to have been compromised
whether it was retroactively revoked with an invalidity date
of 2.8 or 3.2 years into the past, because it would make a difference
for your decision to trust the information *now*.

If the answer is not in rfc3280+rfc2630+rfc3161, then the behaviour
is *undefined*.

> it's better stick to one of the established standards that has been

PAdES says it is for the European requirements for electronic signatures,
so it has a very limited scope and purpose and is likely overkill for
a number of environment and uses (there are more things under the sun
besides legal contracts and fiscal accounting/bookkeeping.

-Martin

---

From: Stephen Kent <[email-masked]>
Date: Thu, 27 Oct 2011 13:32:41 -0400

>might differ (or at least will try differ for the future).

I don't see how you observation about the vulnerability of the CA/RA
relative to remote attacks contradicts my observations. It is commonly believed
that the folks who perform security audits are generally unqualified, low paid
(hot be confused with low priced) folks who follow checklists and are
in the business of approving applicants, so that they can be paid, repeatedly.
This problem is hardly confined to the CA business.

>I'm sorry if my terminology was confusing.  That is not what I meant.

good.

>  to refuse unless it's a clear renewal of an existing cert).

Tha make more sense.  The CA product we sold, long ago, had that sort of
DB. Our FIPS 140 level 3 crypto, in a later version, even maintained
audit info internally on each cert it signed. This was possible 
because the device didn't sign a hash of a cert, but rather took a 
TBS cert as input, assigned the serial number, computed the hash, and 
signed the result.

>or database for several distinct issuer DNames.

everything is, ultimately, up to each CA operator.

Steve

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 27 Oct 2011 22:42:05 +0300

On 10/27/2011 08:32 PM, Stephen Kent wrote:
> audit info internally on each cert it signed. This was possible because
> the device didn't sign a hash of a cert, but rather took a TBS cert as
> input, assigned the serial number, computed the hash, and signed the
> result.

I would actually assume that this is the capability of most CA products.
Keeping a database of issued cert should be normal. Whether this is
available to responders or not might be a different issue, some has it
(ejbca for example), some not. For RAs that would of course depend on
the architecture deployed, but even if the RA does not have it the CA
could deny the issuance if renewal is not allowed.

---

From: Tomas Gustavsson <[email-masked]>
Date: Thu, 27 Oct 2011 22:49:20 +0300

> No, I don't know anything about those, but they must be irrelevant.

I read that as irony. Quite funny actually.

> for your decision to trust the information *now*.

I think you need to extend this to say 10-50 years...
If the actual scope of the document is such that it is of _real_
importance that it needs to be verified 2-50 years in the future, the
system should be designed to cope with evens such as the CA going out of
business for example. Your scheme seems to fail if the CA is not around
anymore, such as DigiNotar. The CA (including CRLs) not being available
does not mean the document signature is invalid.
> If the answer is not in rfc3280+rfc2630+rfc3161, then the behaviour

I like frc5280 etc, but I don't think they do, or even claim to, define
the whole truth.

> besides legal contracts and fiscal accounting/bookkeeping.

RFC5280 says that it is for the "Internet community". This does not mean
it is not suitable as reference for a non-internet community.
On the contrary actually.

---

From: Martin Rex <[email-masked]>
Date: Thu, 27 Oct 2011 23:33:22 +0200 (MEST)

> I read that as irony. Quite funny actually.

No, actually that wasn't a joke, but the naked truth.
For most of the protocols and technologies that were doing in the IETF,
those specs are completely irrelevant.

> does not mean the document signature is invalid.

Which makes such CAs entirely useless for protocols such as S/Mime EMail.

The only protocol that was sensibly usable for secure EMail 16 years ago
was PGP, and the only protcol that seems sensibly usable for secure EMail
is still PGP.  S/Mime sucks big time.

I have PGP-signed Emails from 1995, and they still verify today
(although the trust in the crypto algorithms of back then is fading...)

Most of the S/Mime signed EMails that I received fail Signature
verification (pretty much all of them after some months to a year).
Simple X.509v3 is completely unusable for S/Mime.  It could be made
to work if the receiving S/Mime client would add and rfc3161 timestamp
to every received Email, but the prerequisite is that the CA keeps
certs on the CRL forever.

A sensible S/Mime implementation requires rfc3161+rfc2630+rfc3280
and this technology *IMPLIES* that CAs keep expired certs on their
CRLs for at least 10 years and allow retroactive revocation of certs
for at least 10 years (it depends on the lifetime of your timestamp
server cert -- having to wade through your entire archives before
the timestamping cert expires and re-stamp everything is not workable
for casual users).

I'm curious: are there any sensible S/Mime implementations out there
that do this (add rfc3161 timestamps to received messages)?
I consider S/Mime for EMail pretty much useless without this.
(although we have started using rfc3161, we're *not* using
 PKCS#7/CMS for EMail)

> I like frc5280 etc, but I don't think they do, or even claim to, define

When you're newly adopting a technology, then you start out with the
minimum set of protocols that are necessary to compose a useful
technology.  S/Mime with short-lived X.509 certs without rfc3161
is pretty useless for and medium-term integrity protection and authentication
of data.  The minimum is 3161 and its references (2630 and actually 2459
rather than 3280).  So that is the starting point.  And it requires
a CA that keeps expired certs on its CRL and supports retroactively
revoking certs, even expired ones.

> On the contrary actually.

Easy availability of the specs has been the biggest advantage for technology
developed by the IETF.  Unfortunately, some of the specs reference non-free
specs from other SDOs (like those pesky X9.*  DH/ECDH/ECDSA).
I certainly do have a very strong reluctance to implement any parts of
specs that are *NOT* openly available (and it reliably precludes
that I check out the effort in my spare time just out of curiosity).

-Martin

---

From: Peter Lipp <[email-masked]>
Date: Thu, 27 Oct 2011 23:36:23 +0200

Am 27.10.2011 17:35, schrieb Martin Rex:
> so it has a very limited scope and purpose

> certs with CRLDistributionPoints in them).
Sounds very much like the services provided by X/C/PAdES - so maybe not 
as irrelevant as you may believe.

Peter

---

From: Martin Rex <[email-masked]>
Date: Fri, 28 Oct 2011 02:24:14 +0200 (MEST)

> as irrelevant as you may believe.

I'm in development and usually on a very tight resources budget,
so I'm usually going for the KISS principle, or the quote from
Antoine de Saint-Exupery "Perfection in Design is achived not
when there is nothing left to add, but when there is nothing
left to take away".

So my approach would certainly be
What _subset_ of rfc2630 + rfc3161 + rfc3280 do I need.
I will certainly not look for additional or more feature-rich
specifications to add to the list of requirements, and even
less so for additional specs from outside the IETF.

-Martin

---

From: Tomas Gustavsson <[email-masked]>
Date: Fri, 28 Oct 2011 09:37:54 +0300

> less so for additional specs from outside the IETF.

Just out of curiosity, is IETF doing any work related to long term
signatures?
I do agree that the openness of standards from IETF, Oasis and some
others are far superior to the semi-closed standards (ISO et al).

Regarding S/MIME for secure email I consider that pretty much a dead
fish as well. That area needs substantial overhaul, on several fronts,
in order to be usable outside very limited communities.
If your goal is to re-invent secure email, good luck :-)

For other purposes (I don't consider email a good case for long term
signatures) I'd still look around, also outside IETF, for something
standardised. Especially if on a tight budget since reusing already done
work usually saves me time. Home-grown stuff has a tendency to get back
to bite you in the long run.

Cheers,
Tomas

---

From: [email-masked]
Date: Fri, 28 Oct 2011 11:37:02 +0200

Martin,

Apparently, you have not read the RFCs for a long time, since two of the 
references you mention are now obsolete: rfc2630 + rfc3280

There exists an RFC which describes how to form a signature that can be 
verified beyond the end of the validity of the signer's certificate.
Take a look at RFC 5126. There also exists many ETSI Technical 
Specifications, but it is unfortunate that you already mentioned 
that you will not look at them.

Denis

===================================================================================================

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 28 Oct 2011 16:11:13 +0200 (MEST)

> references you mention are now obsolete: rfc2630 + rfc3280

Actually, no, they aren't.  rfc0791 describes the core IPv4 protocol,
rfc0793 describes the core TCP for IPv4 protocol, rfc2630 describes
the core CMS protocol and rfc2246 describes the core TLS protocol.

What I was given was an implementation of PKCS#7 (rfc2315) and
what I needed was something that I can use with rfc3161 timestamps.

The other issue is: if you want to ship into productive installed bases
that are up to 10 years old, you really don't want to face them with
fancy new stuff, but rather be very conservative,  So what is really
relevant is described in the original documents, not in the newer
kitchen-sink ones.

> that you will not look at them.

Compare size and comprehensibility of rfc3161 with rfc5126.

Unless you're on a research project with no timelines and unlimited
resources, it is pretty clear which of those is easier to implement
and fully (!!) test, and the difference in effort is more than a
magnitude.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 28 Oct 2011 17:44:47 +0200 (MEST)

> Just out of curiosity, is IETF doing any work related to long term

There is rfc3161.

> others are far superior to the semi-closed standards (ISO et al).

What it even more important: the effort that is necessary to fix, change
or extend an existing protocol.  What certainly helps is if you've been
active before in the SDO that is relevant for the protocols you're using.

The big plus of the IETF is that it is open, there is no formal membership,
public discussion archives, public mailing lists, and once you're used
to how the IETF works, many things _can_ be done through remote
participation.

> If your goal is to re-invent secure email, good luck :-)

The situation with S/Mime is really somewhat strange.
>From the origin of its name (S/Mime and CMS) it claims to be
protection at the message transport level, and rather than
for "online" communication, it should be usable for
offline (non-connected) communication.   Archiving Email is
also far form uncommon, so it should be suitable for
non-volatile data as well.

Original PGP does this extremely well, and provides exactly
what is necessary: data origin authentication, data integrity
protection and optionally data confidentially protection --
and it works just fine for Email archives.

The X.509 stuff, as it turns out, is still entangled and polluted with
concepts like "non-repudiation", "legally binding expression of intent"
"policy", "authority".  And while there might be areas where these
attributes matter, _EMail_transport_ is definitely all the wrong place
for it.

> to bite you in the long run.

Secure EMail _without_ longterm data origin authentication and longterm data
integrity protection and longterm data confidentiality protection
is seriously broken and pretty useless.

But if you're looking for longterm archival of "legally binding
expressions of intent" (in the non-repudiation sense), or for the
purpose of accounting/bookkeeping, then that is a completely different
issue.  For such purposes, legislative requirements may become
relevant for your solution, and you may have to turn to the kitchen sink
lobbyists and protocol specs from some other SDOs.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 29 Oct 2011 05:10:00 +1300

Martin Rex <[email-masked]> writes:

>The situation with S/Mime is really somewhat strange. From the origin of its
>name (S/Mime and CMS) it claims to be protection at the message transport
>level, and rather than for "online" communication, it should be usable for
>offline (non-connected) communication.

While there's probably some major user of encrypted email hiding somewhere 
(governments and multinationals who can define their own reality, I'd guess), 
pretty much all the commercial usage of S/MIME (as CMS) I've ever seen has 
been for messaging other than encrypted email.  There are tens or even 
hundreds of GB of data bouncing around the world every day as CMS-encrypted 
store-and-forward messaging (FTP, HTTP, email, hand-carried on SD cards, you 
name it), and that's only the small subset that I know of.

>Original PGP does this extremely well, and provides exactly what is
>necessary: data origin authentication, data integrity protection and
>optionally data confidentially protection -- and it works just fine for Email
>archives.

Yup.  The main reason why CMS gets used in place of PGP is because there's
some perception at the management level that you need to involve certificates
whenever you do anything with security.  I've rarely seen any situations where
this actually increases security, but it always hugely increases complexity
and cost.

(Not playing the PGP advocate here, I'd use CMS myself, just pointing out some
real-world observations).

Peter.

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 28 Oct 2011 12:13:30 -0400

Some of us use encrypted e-mail S/MIME extensively.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Gutmann
Sent: Friday, October 28, 2011 12:10 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [pkix] Fwd: New Version Notification

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Sun, 30 Oct 2011 07:46:14 -0400

>Just out of curiosity, is IETF doing any work related to long term

see the (now closed) LTANS WG.

Steve