Subject: RE: straw poll on certs in CRLs

From: "Guida, Richard [JJCUS]" <[email-masked]>
Date: Wed, 7 Mar 2007 15:01:00 -0500

Paul - thanks very much, that indeed helps clarify things.  One final
question then: if the concern is that the extension may hold one or a few
certs, and since a typical cert may be 1K or 2K in size (mine is 1.4K
DER-encoded), how much bloat do you anticipate in a typical CRL?  If the
proposal were to limit the number of certs in the extension to a small
number - say 10 at most - then might that ameliorate concerns?  I admit that
my viewpoint may be a bit jaded since the CRL we publish is quite large -
5MB (we also have OCSP responders) - so 10K to 20K extra does not seem to be
much.  But again, I am just trying to ensure I understand the concerns that
have been expressed.  Thanks very much -- Rich

Richard A. Guida
Director, Information Security

Johnson & Johnson
Room GS8217
410 George Street
New Brunswick, New Jersey  08901
Phone:  732 524 3785

-----Original Message-----
From: Paul Hoffman [mailto:[email-masked]]
Sent: Wednesday, March 07, 2007 2:32 PM
To: Guida, Richard [JJCUS]; Stefan Santesson; [email-masked]
Subject: RE: straw poll on certs in CRLs

At 2:20 PM -0500 3/7/07, Guida, Richard [JJCUS] wrote:
>Paul - perhaps I am missing something here (would not be the first 
>time...) but the proposal is that it be a non-critical extension and 
>as such, under RFC3280, relying party software can indeed ignore it 
>if they fail to recognize it, correct?

Yes, definitely. But that's not the concern of many of the "no" folks 
have voiced.

>  Your e-mail said "turned it on" but I was not clear what you meant by
that.

Good point; I should have said "deployed, perhaps by default".

Issuing CRLs with this extension causes the CRL to grow, possibly 
significantly. Transmitting this kruft in every CRL retrieval, 
particularly in protocols that require CRL retrieval, is wasteful. 
Further, other folks have proposed better solutions that allow more 
useful information to be given to the relying party than the 
one-size-fits-all view that the CRL issuer knows all possible chains 
it should include in the CRL.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Mar 2007 12:15:36 -0800

At 3:01 PM -0500 3/7/07, Guida, Richard [JJCUS] wrote:
>Paul - thanks very much, that indeed helps clarify things.  One 
>final question then: if the concern is that the extension may hold 
>one or a few certs, and since a typical cert may be 1K or 2K in size 
>(mine is 1.4K DER-encoded), how much bloat do you anticipate in a 
>typical CRL?

We don't know, and that's one of the problems with the proposed 
design. The certs are to help validating parties make chains. The CRL 
issuer doesn't know all the relying parties at the time it creates 
the CRL, and therefor must make the worst-case guess about which 
chains to add.

>If the proposal were to limit the number of certs in the extension 
>to a small number - say 10 at most - then might that ameliorate 
>concerns?

Yes, but it would also not fulfill the purpose of the proposed 
design. A different design could handle many more chains without 
burdening the relying party at all (except at the times that they 
choose to do chain validation).

--Paul Hoffman, Director
--VPN Consortium

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 8 Mar 2007 15:20:22 +0000

Paul,

Some points.

1) To clarify my last posting. My view of the "feature" is to enable storage of certs in a CRL. Not to enable the PKI to structure its infrastructure so clients can retrieve everything it wants in a single fetch. I'm open to all solutions that enable me to store certs in the CRL, I don't believe we need a solution from PKIX for the other part.

2) A standard is useful if it applies to one or more relevant use cases. It does not have to apply to all use cases. To argue that it is a bad idea for a use case where it is not intended is a bad argument IMO. To explain why it is not useful where it intended to be used is a good argument.

3) You seem to argue from the space of public PKIs. Yet public PKIs represent a very small fraction of the certificates in use today. In closed communities, you typically know a lot about the network and the clients that will use the CRL as well as their capabilities. As Richard pointed out.

4) Standards are also needed for supporting closed community PKIs, as it allows use of standard products.

Yes, this feature provide redundancy in many cases. But so do CRLs in general. I need a few bits of information and I may get 5MB. This is why we have OCSP and maybe soon SCVP. But even these optimizations include validation certificates in responses. In the cases where the proposed feature is intended to be used, the extra redundancy is negligible. If this feature can help even in that 1 out of 1000 cases where the client does not have the certificate to validate the CRL, and the resources to get it is not available or network latency creates unwanted time-outs, this feature may still be very valuable. Also if it can help simplify storage of validation data for later use.

I don't foresee that this feature will be turned on by default. But I foresee that it will be used and provide value.

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Paul Hoffman
> Sent: den 7 mars 2007 21:16
> To: [email-masked]

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 8 Mar 2007 15:28:50 +0000

All,

I'm requesting input to the agenda for the PKIX meeting in Prague.

If you have anything you want to contribute to this meeting, please send me a note with:

- Subject
- proposed title
- Related document(s) if any
- Presenter
- Requested time

I need at least one of the editors of each active PKIX document to send me a note, even if you don't have anything to present.
I would appreciate a response with this week, but I will need it at latest Wednesday next week to accommodate your request.

Thank you in advance.

Stefan Santesson
Senior Program Manager

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Mar 2007 10:42:11 -0800

At 3:20 PM +0000 3/8/07, Stefan Santesson wrote:
>1) To clarify my last posting. My view of the "feature" is to enable 
>storage of certs in a CRL. Not to enable the PKI to structure its 
>infrastructure so clients can retrieve everything it wants in a 
>single fetch. I'm open to all solutions that enable me to store 
>certs in the CRL, I don't believe we need a solution from PKIX for 
>the other part.

A "feature" is something that helps one of the parties; a "solution" 
is a way to get the feature. The feature here is allowing the relying 
party to get the information it needs on revocation. If that can be 
done in one grab, that's great; if it takes more than one grab, the 
relying party needs to have a definitive way of finding the location 
for the additional information.

Your choice of the solution instead of looking at the needs of the 
parties does not seem like a good way to design the "feature".

>2) A standard is useful if it applies to one or more relevant use 
>cases. It does not have to apply to all use cases. To argue that it 
>is a bad idea for a use case where it is not intended is a bad 
>argument IMO. To explain why it is not useful where it intended to 
>be used is a good argument.

As many people have already said on the list, there is no way for a 
relying party in a "use case where it is not intended" to ask for a 
CRL that does not have the feature you propose to add.

Further, it is not good protocol design to require people to "explain 
why it is not useful where it intended to be used". Instead, a better 
design methodology is to take the requirements and think of many 
solutions, then map them to the requirements. A solution might be 
useful, but it might have negative aspects that other solutions 
don't. Your procedure pre-ordains a solution to the problem.

>3) You seem to argue from the space of public PKIs.

IETF protocols are designed to be used in the public internet, yes.

>Yet public PKIs represent a very small fraction of the certificates 
>in use today. In closed communities, you typically know a lot about 
>the network and the clients that will use the CRL as well as their 
>capabilities. As Richard pointed out.

If you are saying that future PKIX WG work should allow focus on 
"closed community" PKI, that is a very different question.

>as it allows use of standard products.

This makes no sense at all in the IETF context.

>Yes, this feature provide redundancy in many cases. But so do CRLs 
>in general. I need a few bits of information and I may get 5MB. This 
>is why we have OCSP and maybe soon SCVP. But even these 
>optimizations include validation certificates in responses. In the 
>cases where the proposed feature is intended to be used, the extra 
>redundancy is negligible.

We still haven't seen a list of those cases.

>If this feature can help even in that 1 out of 1000 cases where the 
>client does not have the certificate to validate the CRL, and the 
>resources to get it is not available or network latency creates 
>unwanted time-outs, this feature may still be very valuable.

In what cases could pulling down one CRL be OK but pulling down path 
validation information not be?

>Also if it can help simplify storage of validation data for later use.

This doesn't make sense to me. Validation certificates are always 
stored separately from the data.

>I don't foresee that this feature will be turned on by default. But 
>I foresee that it will be used and provide value.

...but you cannot see how other solutions to the same problem might be better?

--Paul Hoffman, Director
--VPN Consortium

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 12 Mar 2007 15:47:59 +0000

Paul,

I have responded in-line.

Let me first recap the motivation for this proposal.

When PKI was created, many things related to PKI life-cycle management was put aside or partly neglected, as was the case with the early PKI implementations that to a great deal influence current PKIs.
Hard problems are introduced when we need to manage a PKI over time, such as change CA keys during the operational time of the CA.

As a practical result, the implementation of CA-key change and CRL issuance has not turned out to be very agile in practice.
Still we have Root CAs that issues infinite CRLs or very long CRLs because the private CA key used to issue these CRLs are locked away most of the time.
Still we have many CAs configured with a lifetime that has to extend all certificates they issue, because many clients can't handle the transfer of revocation between CA keys for previously issued certs.

As we try to fix these problems, by introducing certificates and CRLs that are validated through different paths, a number of practical problems arises.
First of all, the certificates needed to validate the CRL does also have to be validated, if this introduce new paths for new CRLs the graph can grow significantly.
Every network retrieval in this context may be a significant burden. Every time the client needs to wait for information (due to routing setup, overloaded servers network latency etc), the user will also be kept waiting.

So for example if each CRL could contain all information needed to validate it, this would offer a very straightforward approach in cases where this otherwise would be a great challenge. Phil H Baker has suggested for example that stored CA certificates in the CRL path also could be accompanied with pre-produced OCSP responses. This way we may not save only 1 network retrieval, but many.

That to me is an interesting approach that could offer significant performance win in certain environments + make it easier to effectively cash validation info.
We represent vendor/service provider facing practical problems that we want to solve. We have also heard active users, facing problems they want to solve. I think all of us are open to the means how to solve it, as long as it works and is practical to implement. So far I have yet not seen an alternative that I believe in.

Stefan Santesson
Senior Program Manager

> Sent: den 8 mars 2007 19:42
> To: Stefan Santesson; [email-masked]

No need to bash words. I was just explaining my original posting and why it was misunderstood.

> CRL that does not have the feature you propose to add.

Your picture of a PKI community must be vastly different from my daily experience. I can think of no customer that would want this feature. The performance win would be extremely insignificant payoff for adding this complexity. In general the CA offers the service that best serve its community of users.

> don't. Your procedure pre-ordains a solution to the problem.

Yes, because I can see no other reasonable solution that would be worth implementing. It's based on our assessment that this "problem" does not motivate the introduction of another choice for the RP client, nor returning data in a way it is not used to. The impact on legacy would be too big and the win would be lost.

> IETF protocols are designed to be used in the public internet, yes.

This seems like an odd argument from you Paul :).
Closed community applications are used over the public internet. IETF has produced numerous protocols that are intended to support closed community communication over the public internet. One obvious is VPN. And then we can add Kerberos protocols and a big bunch of others.

> This makes no sense at all in the IETF context.

It absolutely does.

> We still haven't seen a list of those cases.

Only for instances where this solution would not be used.

> validation information not be?

Yes. One of the single biggest practical problems with PKI is the number of network retrievals needed to pull down all information. Each possibility for optimizations is valuable.

> stored separately from the data.

Not always. There are protocols for attaching validation data to a signed document. This capability is of great focus especially related to the EU electronic signature directive.
But this is sort of irrelevant. The win is that the CRL and the certificates needed to validate it would not have to be stored separately. But this is not the most important argument. It's more a positive side effect.

> ...but you cannot see how other solutions to the same problem might be

No, none that I have seen presented here.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 14 Mar 2007 12:09:14 +0000

OK,

This was the end of the deadline,

I have only received two responses from people saying that they are not going to go to Prague.

David Cooper has told me that he will not be coming and that he has nothing to present for 3280bis and SCVP.

So, at this point I have no requests for agenda items.

I have a number of issues that I want to have on the agenda however.

- Concluding certs in CRL as accepted/rejected work item. IF rejected, should we do something else instead?
- Updating POP options for CMC (see separate mail)
- Finalizing the ECC algorithm document

There is no updates on the ECC document so there might be nothing to present. But I would like to have a discussion at least.

So, if you have anything to add, please send me a hint right away, or we will have a very short PKIX meeting.
This is an excellent opportunity if you have a liaison presentation or similar you would like to do.

Stefan Santesson
Senior Program Manager

> [email-masked]] On Behalf Of Stefan Santesson
> Sent: den 8 mars 2007 16:29
> To: [email-masked]
> Cc: Stephen Kent
> Subject: Request for agenda items for the IETF-68 PKIX meeting
>
>
> All,
>
> I need at least one of the editors of each active PKIX document to send
> me a note, even if you don't have anything to present.
> I would appreciate a response with this week, but I will need it at
> latest Wednesday next week to accommodate your request.
>
>
> Thank you in advance.
>
> Stefan Santesson
> Senior Program Manager

---

From: Scott Lawrence <[email-masked]>
Date: Wed, 14 Mar 2007 10:39:46 -0400

> This was the end of the deadline,

I just joined the list yesterday in anticipation of sending this
request... sorry for having missed your earlier call.

> similar you would like to do.

I'm one of the co-authors of a draft whose goal is to specify
conventions for the construction of certificates for SIP domains [1]
(not individual users - that's a slightly different set of problems).

We'd like some review and discussion of this, and I suspect that there
are some general principles about how to do it that are not well known
outside the pkix WG .

The draft has some content that readers not intimately familiar with SIP
may find confusing (especially some references to ongoing work), but the
key issues from a pkix perspective are these:

We would like to be able to create a certificate for creating a TLS
connection either as a client or a server that binds the name of the SIP
domain to the connection.  A SIP domain is the part of a SIP address
(which looks just like an email address, but uses the URL scheme 'sip';
so my SIP URL is 'sip:[email-masked]').  A SIP domain may have
many servers (called proxies) that are authoritative for the domain:
some may only accept connections for requests into the domain (these are
listed in the DNS using NAPTR and SRV records that are functionally
equivalent to MX records for mail), others may only originate
connections outbound from the domain (there is currently no way to
describe these in the DNS), and some may do both.   SIP proxies that are
either forwarding or receiving connections for requests may need to
authenticate the peer domain in order to apply access controls, billing,
or other policies.  Because of the number of servers and their different
possible roles, certificates that bind the FQDN of the proxy are not
sufficient (and may in fact be problematic, since in high availability
configurations there may be multiple redundant proxies that are
equivalent).

We also believe that it is important to be able to construct the
certificates in such a way that they can make the distinction that the
proxy is authoritative for the SIP domain 'example.com', but not
necessarily for any other service (such as email, for example).

At present, deployment of SIP over TLS between domains is quite rare,
and one of the most important reasons is that there is no uniform
convention for how to construct and validate the certificates in a
uniform way.  We would appreciate your help in overcoming this.

[1]  Domain Certificates in the Session Initiation Protocol (SIP)
 http://www.ietf.org/internet-drafts/draft-gurbani-sip-domain-certs-04.txt
 or, in html:
 http://svn.resiprocate.org/rep/ietf-drafts/gurbani/domain-certs/draft-gurbani-sip-domain-certs-04.html

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 15 Mar 2007 17:36:57 +0000

This sounds like a very interesting topic.

Will you be there to present?
How much time do you need?

Stefan Santesson
Senior Program Manager

> From: Scott Lawrence [mailto:[email-masked]]
> Sent: den 14 mars 2007 15:40
> To: Stefan Santesson
> Cc: [email-masked]; Stephen Kent; Vijay Gurbani
> Subject: RE: Request for agenda items for the IETF-68 PKIX meeting
>
> > This is an excellent opportunity if you have a liaison presentation
> or
> > similar you would like to do.
>

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 15 Mar 2007 17:52:48 +0000

> How much time do you need?

Yes, both Vijay and I will be there.  I can come and present at the PKIX
meeting (it conflicts with one of the SIP WG sessions, but that's the
way the ball bounces).

How much time it needs depends on how it is received :-)

I think that I can coherently explain the problem in 5-10 minutes.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 19 Mar 2007 10:28:39 +0000

An agenda for the meeting on Tuesday is available at: http://www3.ietf.org/proceedings/07mar/agenda/pkix.txt

I have a few requests without a confirmed presenter.
A few topics may be added ad-hoc if that situation changes.

Stefan Santesson
Senior Program Manager

---

From: Milan Sova <[email-masked]>
Date: Mon, 19 Mar 2007 19:25:37 +0100

Stefan.
> A few topics may be added ad-hoc if that situation changes.
	Could we spare a couple of minutes on the next process of solving the
URN in sujectAltName issue?

	Sorry for the late request but I was detached to other tasks.

	Thanks
-- 
						Milan Sova
						[email-masked]

---

From: Milan Sova <[email-masked]>
Date: Mon, 19 Mar 2007 19:30:15 +0100

Stefan.

	Thanks
-- 
						Milan Sova

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 20 Mar 2007 13:17:01 +0000

The final agenda for the PKIX meeting is posted.

It seems like we will have a full agenda after all, so the meeting will kick off exactly on time to give all presentations the time they need.
Reminding to please try to send me your slides before meeting starts.

Stefan Santesson
Senior Program Manager