Subject: RE: Certs in CRLs - New standards task?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 14 Sep 2006 11:05:30 -0700

It is a grotty hack but you could use the VALUE: URI which contains the raw data referenced by itself.

"VALUE:" + base64 (cert); 

Like I say.... Ugh! But....

> -----Original Message-----
> From: Stefan Santesson [mailto:[email-masked]] 
> Sent: Thursday, September 14, 2006 1:30 PM
> To: Hallam-Baker, Phillip; Stephen Farrell
> Cc: [email-masked]
> Subject: RE: Certs in CRLs - New standards task?
> 
> I'm open to all solutions that in an effective and practical 
> way solves the issue.
> 
> The reason I primary suggested a non-critical CRL extension 
> was to not disturb how legacy clients are configured to fetch 
> CRL's and the format they expect them to arrive.
> 
> RFC 3280bis states.
> 
>    If the DistributionPointName contains a general name of 
> type URI, the
>    following semantics MUST be assumed: the URI is a pointer to the
>    current CRL for the associated reasons and will be issued by the
>    associated cRLIssuer.  When the HTTP or FTP scheme is 
> specified, the
>    URI MUST point to a CRL file.  The CRL file MUST contain a 
> single DER
>    encoded CRL as specified in [RFC 2585].
> 
> As such I feel uncertain of the impacts on legacy 
> implementations if a bag of CRL+Certs is returned. But if 
> this can be done in a smooth way without causing problems, 
> then I'm all ear.
> 
> A non critical CRL extension with a certificate path would 
> simply be ignored by legacy clients and would not cause any 
> backwards compatibility problems. Thus it seems like an 
> easier path to me.
> 
> I don't believe the CA need to issue one CRL with certs and 
> one without, as David Kemp suggest. One CRL with a 
> non-critical extension with certs would work for all. And 
> this would not be included in the common CRLs of today. It 
> would only be a case for indirect CRLs and possibly when a 
> rekeyed CA take over revocation of certs issued under an older key.
> 
> 
> Stefan Santesson
> Senior Program Manager
> Windows Security, Standards
> 
> > -----Original Message-----
> > From: Hallam-Baker, Phillip [mailto:[email-masked]]
> > Sent: den 14 september 2006 07:09
> > To: Stephen Farrell; Stefan Santesson
> > Cc: [email-masked]
> > Subject: RE: Certs in CRLs - New standards task?
> > 
> > I would prefer a bag as well, DIME would be ideal but I guess this 
> > group would want something ASN.1
> > 
> > Provided BER encoding is allowed I don't see a problem.
> > 
> > 
> > Another area where the same problem comes up is when using logotype,
> it
> > would be nice to be able to deliver the certificate and the logo in
> one
> > bag. Currently I am using MIME for this.
> > 
> > 
> > I would tend to see this as an HTTP extension rather than a PKIX 
> > extension. We already have MIME archives of HTML documents with 
> > interelated parts. This would be fine for small CRLs but for large
> CRLs
> > you really do need binary encoding not base 64.
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Stephen Farrell
> > > Sent: Wednesday, September 13, 2006 5:46 PM
> > > To: Stefan Santesson
> > > Cc: [email-masked]
> > > Subject: Re: Certs in CRLs - New standards task?
> > >
> > >
> > >
> > >
> > > Stefan Santesson wrote:
> > > > I would like to hear the opinion of this group on this.
> > >
> > > Sounds like an interesting idea - would like to see a draft all 
> > > right. (Though David Kemp's idea of wrapping the cert and 
> CRL a bag 
> > > might also be worth investigating, depending on the CRL consuming 
> > > protocols one is considering.)
> > >
> > > However, I'd have to wonder whether extending the life of 
> the PKIX 
> > > WG by another couple of years would be the right approach.
> > > Would it be better to first consider re-chartering or else 
> > > chartering a new WG? (I'm not saying I think either is the way to 
> > > go, but PKIX has been on the go for a looong time.)
> > >
> > > S.
> > >
> > >
> > >
> 
>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 15 Sep 2006 16:58:45 +1000

I have heard of the "data" URL scheme (RFC 2397), but not the "value" scheme.  Is it defined somewhere?  Supported anywhere?

  data:[mine-type][;base64],data

---

From: Tom Gindin <[email-masked]>
Date: Sat, 16 Sep 2006 17:44:13 -0400

Phill:

        IMHO that's even uglier than defining an OTHER-NAME type 
containing a certificate.  Such a definition would have other uses, most 
of which would be equally ugly - just think of an issuer Alt Name with the 
full text of the CA certificate inside.  A CRL-specific extension has got 
to be cleaner than these.

                Tom Gindin

"Hallam-Baker, Phillip" <[email-masked]> 
Sent by: [email-masked]
09/14/2006 02:05 PM

To
"Stefan Santesson" <[email-masked]>, "Stephen Farrell" 
<[email-masked]>
cc
<[email-masked]>
Subject
RE: Certs in CRLs - New standards task?

It is a grotty hack but you could use the VALUE: URI which contains the 
raw data referenced by itself.

---

From: "Kemp David P." <[email-masked]>
Date: Mon, 18 Sep 2006 10:51:20 -0400

Two of the Big 3 cert consuming protocols (IPSec, TLS, and CMS) already
are designed to transport any needed combination of certificates and
CRLs.
The third (TLS) has no mechanism for transmitting CRLs at all,
regardless of whether a CRL has embedded certs.

-----------------------------------------------------------
RFC 4306 (IKE) defines Certificate payload type 13: "Hash and URL of
X.509 Bundle" which carries a pointer to a bundle of certificates:

  CertificateBundle ::= SEQUENCE OF CertificateOrCRL

  CertificateOrCRL ::= CHOICE {
    cert [0] Certificate,
    crl  [1] CertificateList }

  Hash and URL encodings (12-13) allow IKE messages to remain short
  by replacing long data structures with a 20 octet SHA-1 hash (see
  [SHA]) of the replaced value followed by a variable-length URL
  that resolves to the DER encoded data structure itself.  This
  improves efficiency when the endpoints have certificate data
  cached and makes IKE less subject to denial of service attacks
  that become easier to mount when IKE messages are large enough to
  require IP fragmentation [KPS03].

-----------------------------------------------------------
RFC 3369 (CMS) includes similar bags of certificates and CRLs for
its SignedData and EnvelopedData structures:

  OriginatorInfo ::= SEQUENCE {
     certs [0] IMPLICIT CertificateSet OPTIONAL,
     crls [1] IMPLICIT CertificateRevocationLists OPTIONAL }

  certificates is a collection of certificates.  It is intended that
  the set of certificates be sufficient to contain chains from a
  recognized "root" or "top-level certification authority" to all of
  the signers in the signerInfos field.  There may be more
  certificates than necessary, and there may be certificates
  sufficient to contain chains from two or more independent top-
  level certification authorities.  There may also be fewer
  certificates than necessary, if it is expected that recipients
  have an alternate means of obtaining necessary certificates (e.g.,
  from a previous set of certificates).  The signer's certificate
  MAY be included.  The use of version 1 attribute certificates is
  strongly discouraged.

  crls is a collection of certificate revocation lists (CRLs).  It
  is intended that the set contain information sufficient to
  determine whether or not the certificates in the certificates
  field are valid, but such correspondence is not necessary.  There
  MAY be more CRLs than necessary, and there MAY also be fewer CRLs
  than necessary.

-----------------------------------------------------------
RFC 4387 (Certificate Store Access via HTTP) specifies a simple
query/response protocol that returns certs or CRLs that match
individual HTTP GET queries.  The World Wide Web seems to survive
pretty well using a document structure that includes HTML/XML
markup with links to images displayed within a document.
The Web has not found it necessary or desirable to use HTML/XML
documents with embedded image data (as opposed to links) in order
to improve efficiency.  Images, Certs, and CRLs are all examples
of standalone data blobs that can be retrieved sequentially with
acceptable performance.  I've never heard anyone propose that
because sometimes external images fail to load, the optimum
solution is to imbed image data into referencing documents.

To improve the performance and availability of systems that 
consume both CRLs and CRL issuer certificates, the design
pattern to be followed is to leave Certs and CRLs as
independent data units but make them available from the
same repository or within the same IKE payload or CMS message.
If the repository is up, both CRL and cert can be retrieved
over a single TCP handshake.  If an IKE or CMS protocol data
unit is received, it can be structured to contain all data
needed to support path validation without requiring any
changes to the existing protocols.  The bags/bundles within
these protocols were explicitly designed for flexibility
(as opposed to TLS's rigid certificate path with no CRLs);
that flexibility is the system designer's friend.

IMO, improving implementations of the existing standards is
preferable to 1) creating new syntax, and 2) establishing
a design pattern of embedding certificates within CRLs or
vice versa.  From an architectural perspective, 2) is even
uglier than 1).

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Tom Gindin
Sent: Saturday, September 16, 2006 5:44 PM
To: Hallam-Baker, Phillip
Cc: [email-masked]; Stefan Santesson; Stephen Farrell
Subject: RE: Certs in CRLs - New standards task?

        Phill:

of which would be equally ugly - just think of an issuer Alt Name with
the 
full text of the CA certificate inside.  A CRL-specific extension has
got 
to be cleaner than these.

                Tom Gindin

To