gmane.ietf.x509

Re: Whitelisting

Peter Gutmann — 2013-05-19T01:43:26


Another solution, which has been around as long as OCSP has, is RTCS, which
was desgined to fix all (known) problems with OCSP:

http://tools.ietf.org/html/draft-gutmann-cms-rtcs-01

Peter.

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

Re: [Technical Errata Reported] RFC5912 (3626)

Stephen Kent — 2013-05-17T19:31:53

I concur with Jim.

Steve
------
On 5/17/13 12:02 PM, Jim Schaad wrote:

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

Re: [Technical Errata Reported] RFC5912 (3623)

Piyush Jain — 2013-05-17T16:05:35

[[Piyush] The way I interpret it is following the combining rules which are
defined in 5280, though not using a mathematical notation.
Base CRL is a set. Delta is another set where each entry should be either
added or deleted from the Base CRL based on the reason code.
You are interpreting 'combination' as a simple search in both the base CRL
and delta CRL which is incorrect IMO.

[Piyush] I think you misunderstood me. RPs don't need to remove expired cert
from merged CRL. They just need to remove entries from the base CRL that are
marked as "removeFromCRL" in the delta while creating a merged CRL. Or if
you prefer the word "combination", the serial number must be searched in
both Base and delta to figure out the revocation status (even if an entry
for that serial exists in the base CRL).

revoked
is
[Piyush] You cannot conclusively  use a current CRL to determine the status
of a certificate sometime in the past.
But I hear your point. What you are saying is "add 1 to 0" and delete "1
from the result" is not same information as "0" because in former case you
know that add and delete operations were performed whereas in the latter
case you don't. 
However, I don't see any practical use of this information in context of
certificate revocation status check.
 
certificate status
[Piyush] You cannot use current CRL to determine historical status. SO this
is a moot point.
[Piyush] Its optional. I wish you understand the tradeoffs before passing
judgments. In an environment where there is no need for historical
validation, including status of expired certificates is waste of space and
bandwidth. 
to
[Piyush] To find the status at time t, find a CRL whose thisUpdate is less
than t and nextUpdate is greater than t. 
How to find such a CRL is beyond the scope of the document. Consult your CRL
infrastructure administrator for additional information :).

[Piyush] You have created an artificial requirement that historical
validations should be possible using current CRL. While it is nice to have,
it's not a requirement for every implementation, hence the option. In some
scenarios archival solutions can chose to archive the revocation information
source with the record of the transaction. In other scenarios they can
choose to include the revocation information beyond expiry.


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

Re: [Technical Errata Reported] RFC5912 (3626)

Jim Schaad — 2013-05-17T16:02:46

Totally reasonable - should be accepted.

"Reply
is
edit the
Using

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

Re: Whitelisting

Piyush Jain — 2013-05-17T15:06:11

And this
http://tools.ietf.org/html/draft-perrin-tls-tack-02



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

Re: Whitelisting

Adam Langley — 2013-05-17T14:35:31

It is possibly this document:
https://tools.ietf.org/html/draft-ietf-websec-key-pinning-04


Cheers

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

Re: Whitelisting

Erik Andersen — 2013-05-17T14:31:05

The reason I am asking is that I am sitting with a document that I am
commenting. It says:

"In certain deployments, additional support is necessary to further restrict
the usage of certificates based on their serial numbers and issuers. This
restriction is known as certificate white listing or certificate pinning,
and is currently being defined in the IETF"

I was trying to find out whether that is true and if yes, what the status
is.

Erik

-----Oprindelig meddelelse-----
Fra: Martin Rex [mailto:mrex< at >sap.com] 
Sendt: 17. maj 2013 16:10
Til: Erwann Abalea
Cc: Erik Andersen; PKIX
Emne: Re: [pkix] Whitelisting

I assume Erik was asking about an OCSP Extension "Proof of cert issuance",
such as a CertHash included with an OCSP "good" status.

One example for an "existing solution" was mentioned by Johannes Merkle and
is quoted here:

http://www.ietf.org/mail-archive/web/pkix/current/msg32667.html

-Martin

Erwann Abalea wrote:
ideas?

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

Re: Whitelisting

Martin Rex — 2013-05-17T14:09:55

I assume Erik was asking about an OCSP Extension "Proof of cert issuance",
such as a CertHash included with an OCSP "good" status.

One example for an "existing solution" was mentioned by
Johannes Merkle and is quoted here:

http://www.ietf.org/mail-archive/web/pkix/current/msg32667.html

-Martin

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

Re: Whitelisting

Erwann Abalea — 2013-05-17T13:57:18

Are you talking about MECAI, Google CT, EFF Sovereign Keys, and similar ideas?

2013/5/17 Erik Andersen <era< at >x500.eu>:

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

[Technical Errata Reported] RFC5912 (3626)

RFC Errata System — 2013-05-17T10:34:32

The following errata report has been submitted for RFC5912,
"New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5912&eid=3626

--------------------------------------
Type: Technical
Reported by: Carl Wallace <carl< at >redhoundsoftware.com>

Section: 14

Original Text
-------------
   -- CRL number extension OID and syntax
   ext-CRLNumber EXTENSION ::= {SYNTAX
       INTEGER (0..MAX) IDENTIFIED BY id-ce-cRLNumber }
   id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

   CRLNumber ::= INTEGER (0..MAX)

Corrected Text
--------------
   -- CRL number extension OID and syntax
   CRLNumber ::= INTEGER  (0..MAX)

   ext-CRLNumber EXTENSION ::= {SYNTAX
       CRLNumber IDENTIFIED BY id-ce-cRLNumber }
   id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

Notes
-----
The CRLNumber extension was not defined to use the CRLNumber type.  It should use the CRLNumber type.  This is a corrected resubmission of an earlier errata submission that included an error.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5912 (draft-ietf-pkix-new-asn1-08)
--------------------------------------
Title               : New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)
Publication Date    : June 2010
Author(s)           : P. Hoffman, J. Schaad
Category            : INFORMATIONAL
Source              : Public-Key Infrastructure (X.509)
Area                : Security
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
pkix mailing list
pkix< at >ietf.org
https://www.ietf.org/mailman/listinfo/pkix

Whitelisting

Erik Andersen — 2013-05-17T10:31:58

There were some ideas about whitelisting of certificates. What is the
status?

 

Erik

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

Re: [Technical Errata Reported] RFC5912 (3623)

Martin Rex — 2013-05-17T10:06:08

[ Charset UTF-8 unsupported, converting... ]

Whoa there!  more flying pigs (in Appendix B of X.509 08/2005):
(Thanks for the pointer, though).

  B.5.2 Validate delta CRL scope

  The dCRL shall be issued after the base CRL. One way to ensure this is
  to check that the CRL number in the crlNumber extension of the dCRL is
  greater than the CRL number in the crlNumber extension of the base CRL
  the relying party is using and the cRLStreamIdentifier fields in the
  base and the dCRL match.  This approach may require additional logic
  to account for number wrapping. Another way is to compare the thisUpdate
  fields in the base and dCRLs the relying party has;

Wrapping a CRLNumber that is defined as montonically increasing from the
INTEGER range (0..MAX) exceed "positive infinity" and wraps is a lame
argument (OK, CRLs require DER encoding, and DER doesn't allow
indefinite length encoding, but anyhow).


Curiously, I found the following in an X.509:

  BaseCRLNumber ::= CRLNumber

  The value of type BaseCRLNumber identifies the CRL number of the
  base CRL that was used as the starting point in the generation of
  this delta-CRL, i.e. this delta-CRL contains the changes between
  the base CRL and the complete CRL issued along with this delta-CRL.
  It is the decision of a CA as to whether to provide delta-CRLs.
  However, a delta-CRL shall not be issued without a corresponding
  complete CRL being issued at the same time. The value of the CRL
  number, as conveyed in the CRL number extension field (if present),
  shall be identical for both the delta-CRL and the corresponding
  complete CRL.


Some of this text is carried through in rfc5280.  Curiously, some of
it got dropped in a clearly backwards-incompatible and formally provable
breaking fashion from newer specs.  Ouch!


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

Re: [Technical Errata Reported] RFC5912 (3623)

Jim Schaad — 2013-05-17T08:29:22

The following text is from RFC 5280

   id-ce-cRLNumber OBJECT IDENTIFIER ::= { id-ce 20 }

   CRLNumber ::= INTEGER (0..MAX)

This says that the ASN.1 makes it a positive number

positive
Infrastructure

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

Re: [Technical Errata Reported] RFC5912 (3623)

Erwann Abalea — 2013-05-17T08:24:13

2013/5/17 Martin Rex <mrex< at >sap.com>:
[...]

See X.509 Annex C for such examples.

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

Re: [Technical Errata Reported] RFC5912 (3623)

Martin Rex — 2013-05-17T07:10:56

While I had not read through that section, this is relevant exclusively
to "CAs conforming to rfc5280" (if at all), but NOT for RPs, _unless_
the same exists in ITU-T Rec. X.509 08/2005 due to the guidance in
rfc5280 section 6.1:

   Therefore, the algorithm only includes checks to verify that the
   certification path is valid according to X.509 and does not include
   checks to verify that the certificates and CRLs conform to this
   profile.  While the algorithm could be extended to include checks for
   conformance to the profiles in Sections 4 and 5, this profile
   RECOMMENDS against including such checks.



(1) it says "the combination of ... revocation information" which is NOT
    equal to first merging the CRLs and then looking at the result.
(2) removing expired certs from any "merged CRL" locally created by the RP
    (a) is neither required, nor appropriate, nor reasonable, and
        the CRL does not even whether the CA would remove expired certs.
    (b) not even possible for the RP, because it only sees cert serials



I think we can safely ignore such unreasonable/illogical interpretations.



Knowing that a cert was temporarily revoked during some time in the past
is _still_ "revocation information", no matter how you look at it.

Whether such information is useful or relevant for checks performed by
the RP is highly dependent on the RP's usage scenario and/or purpose.
For stuff that is also digitally timestamped (e.g. rfc3161), the certificate
status at the time indicated by the secure timestamp might be MUCH more
relevant than the current cert status (which may even be expired by then).

btw. which well-known CRL extension will be present on complete CRLs
where the CA does stupid things such as removing revoked certs after
they expire, or no longer accept and publish revocations for a cert
that has expired?

And where in rfc5280/pkix is the algorithm described for the RP software
to determine and obtain the necessary CRL to determine the cert status
for some point in the past for an already expired cert?

Allowing CAs to drop certs off CRLs without either of these being
standardized and used, would make S/Mime/CMS pretty useless for
offline use and archival, including use in EMail.



They technically could, but they will fundamentally break X.509 if they do.



Nope, that would create 3 holes "n+1", "n+2" and "n+3" in the sequence
numbering of complete CRLs.  The X.509 promise about CRLNumber is that
it will be monotonically increasing, that the CRL user aka RP is allowed
to use CRLNumber to ensure that it has seen and processed all prior CRLs,
while allowing the very same RP to be entirely ignorant about delta CRLs.


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

Re: [Technical Errata Reported] RFC5912 (3623)

Piyush J.comain — 2013-05-17T04:08:33

[Piyush] That would be incorrect.  A delta cannot be combined with
concurrently generated CRL. Section 5.2.4 bullet (d).

then (allegedly intended meaning of) the second sentence

baseCRL
[Piyush] correct. 
[Piyush] I don't see the defect.

[Piyush] An acceptable complete CRL to merge with a delta is one with the
CRL number greater than or equal to the one that is referenced as base CRL
number in the delta. Once the merging happens the merged CRL would contain
the same entries as a concurrently issued complete CRL.
deltaCRL.
[Piyush] Depends on how you interpret "SAME revocation information".
"removeFromCRL" is a mechanism to indicate  that entry was removed from CRL
i.e. the cert referenced by that entry is not considered revoked anymore.
The absence of the entry in the concurrent complete CRL indicates the same
thing.

have
[Piyush] removeFromCRL just indicates that the entry was removed from the
complete CRL. It could be because the cert was reinstated or because it
expired.

misleading
[Piyush] An acceptable complete CRL's number must be less than that of the
delta. So concurrently issued CRL cannot be an acceptable CRL to merge with
the delta.
the
to
in
[Piyush] I don't think that your conclusion is correct. CAs can issue deltas
more frequently than complete CRLs.
e.g. CRL number 'n' could be associated with both a delta and a full,
numbers 'n+1', 'n+2', 'n+3' would be associated with just deltas and 'n+4'
would be again associated with both delta and complete.

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

Re: [Technical Errata Reported] RFC5912 (3623)

Martin Rex — 2013-05-17T02:21:50

Correct, that is one possible consequence when allowing CAs
to remove revoked certs from CRLs after they have expired when
there were listed at least once on a complete CRL.



Sorting that mess out will be a time-consuming job, and one that
I won't do.

Example provable non-sense (from the second paragraph of 5.2.3):

                     If a delta CRL and a complete CRL that cover the
   same scope are issued at the same time, they MUST have the same CRL
   number and provide the same revocation information.  That is, the
   combination of the delta CRL and an acceptable complete CRL MUST
   provide the same revocation information as the simultaneously issued
   complete CRL.

If the deltaCRL would reference the concurrently generated complete CRL
as BaseCRLNumber, then (allegedly intended meaning of) the second
sentence would result in a tautology (the concurrently generated
complete CRL being the only acceptable complete CRL in existence)
and the deltaCRL would have to be empty. 

Therefore I assume the idea here was to create a deltaCRL to a prior
baseCRL concurrently with a new complete CRL, so that CRL user could
continue to use a "technically expired" baseCRL with that deltaCRL.


The two defects in this paragraph are:
(1)  "the combination of the delta CRL and an acceptable complete CRL"
(2)  "MUST provide the same revocation information as ... complete CRL"

What it may have actually meant is
  "the combination of the delta CRL and EVERY acceptable complete CRL
   MUST provide NO LESS revocation information as the simultaneouly
   issued complete CRL".


(2) "The SAME revocation information" in the latter sentence
is formally provable non-sense, because a delta-CRL may contain
"removeFromCRL" entries that can not appear on the complete CRL,
and that will require any temporary revocation they refer to not
appear on the new complete CRL, although that temporary revocation
information may have been present on an earlier complete CRL that
is acceptable for combination with the deltaCRL.

On top of that, unless this requirement is supposed to entirely void
the permission for CAs to drop revoked certificates off the CRL after
they have expired, there may be further revocation information missing
on the new complete CRL that is available in the combination of
the deltaCRL and an acceptable complete CRL -- in case that deltaCRL
references a an earlier BaseCRLNumber than that of the concurrently
generated complete CRL.

(1) Since the first sentence starts with the premise
"If a delta CRL and a complete CRL that cover the same scope are issued
 at the same time", the new complete CRL will be _an_ acceptable
complete CRL for combination with the deltaCRL, so the use of
"an acceptable complete CRL" is a misleading tautology.  What is
really important here, is that the "NO LESS revocation information"
applies to combination of this delta CRL and *EVERY* acceptable
complete CRL.


I also believe that as a backwards compatibility requirement with
X.509, the weird fashion how rfc5280 abused the CRLNumber extension
in deltaCRLs (an idea that I did not see in X.509) implies that a
CA will *ALWAYS* have to issue a complete CRL with every deltaCRL,
otherwise it would create holes in the sequence numbers of
complete CRLS, breaking a fundamental promise/assumption of X.509.


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

Re: [Technical Errata Reported] RFC5912 (3623)

Piyush J.comain — 2013-05-16T22:26:28

being

[Piyush] Why the CRL user needs to detect if all prior CRLs were processed
is an open question and there may be legitimate use cases that can be
addressed by doing so.
But I cannot fathom why an RP will require that all prior CRLs be processed
before considering a cert from that CA valid.

One genuine use case that comes to mind is providing time based validation
i.e. checking revocation status of a currently  expired certificate at some
time in the past. If the RP has missed a few prior CRLs, it cannot be sure
if a now expired certificate was revoked at some point in the past and then
removed from the CRL because it expired.

So I agree with you that CRL Numbers should be in arithmetic progression
with difference between consecutive numbers being 1.
It is also easier to issue the first CRL with number 0 so it is implicit to
the client that CRL with number 0 is the first CRL. However, the standard
does not preclude the CA from issuing the first CRL with number 29678 and
communicating this number of the first CRL to the RPs out of band. But these
are theoretical discussions. I can't imagine an implementation that
generates CRL numbers using geometric progression or even using arithmetic
progression with difference being more than 1 unless the implementer is
trying to reveal his sense of humor.


that

As I said above CA may use any number for first CRL and publish that number
as the one associated with the first CRL.


True.

Specifics please. What are the self-contradictions and the logical
fallacies.



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

Re: [Technical Errata Reported] RFC5912 (3623)

Martin Rex — 2013-05-16T21:34:55

Some of my previous message seems garbled.

The one and only explicit purpose of CRLNumber given in ITU-T Rec X.509:


means that a "CRL user" aka "Relying Party" may REQUIRE (whenever it feels
like it) to have seen and processed *ALL* prior CRLs of a CA before
considering a cert from that CA as valid.

The CA is prohibited from doing anything that would interfere with RPs
that want to make use of that guarantee from X.509, so formal logic
deduction requires that a CA MUST issue their first CRL with number 0
and MUST NOT issue a CRL with CRLNumber (n+1) when it has not previously
issued a CRLNumber (n) (and n is a valid number for a CRL to have).


Speaking of rfc5280 section 5.2.3:
What sections 5.2.3 CRLNumber and 5.2.4 Delta CRL Indicator of rfc5280
say about CRLNumbers of Delta CRLs looks incomprehensible to me
and contains ambiguities and self-contraditions.  It looks like a
huge mess to me, containing formally provable logical fallacies.


X.509 (11/2008) is also confusing, e.g. X.509 says:

                                        However, the cRLNumber referenced
    in the BaseRevocationInfo field of a dCRL shall be less than or equal
    to the cRLNumber of the most recently issued CRL that is complete for
    the applicable scope.

which looks bogus and I assume really should have said:

                                        However, the CRLNumber referenced
    in the BaseRevocationInfo field cRLNumber of a dCRL shall be less than
    or equal to the CRLNumber of the most recently issued CRL that is
    complete for the applicable scope.

based on the accompanying ASN.1 definitions:

  cRLNumber EXTENSION ::= {
        SYNTAX           CRLNumber
        IDENTIFIED BY    id-ce-cRLNumber }

  CRLNumber ::= INTEGER (0..MAX)

  BaseRevocationInfo ::= SEQUENCE {
        cRLStreamIdentifier  [0]    CRLStreamIdentifier OPTIONAL,
        cRLNumber            [1]    CRLNumber,
        baseThisUpdate       [2]    GeneralizedTime }


Rfc5912 is slightly better by using "ext-CRLNumber" rather than
"cRLNumber" for the extension type.


I'm still an ASN.1 layman for most parts of ASN.1, and the correct
terminology.  Frankly, to me it looks like ASN.1 is at least a
magnitude too difficult that it can be used in an error-free fashion
in practice...

I'm unaware of any non-trivial ASN.1-based protocol definition
that is (a) error-free and (b) describes the actual behaviour of
the installed base.


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

Re: [Technical Errata Reported] RFC5912 (3623)

Martin Rex — 2013-05-16T19:26:07

[ Charset UTF-8 unsupported, converting... ]

You failed to read X.509.

Look at the DEFINED purpose of the CRLNumber in X.509 again.

The stated purpose of CRLNumber is:

  It allows a CRL user to detect whether CRLS issued prior to the one being
  processed were also seen and processed.

This is _not_ about a human doing research!

A CA starting at a number > 0 or a that creates holes in the CRLNumber
space would preclude (and enforce) the "were also seen an processed"
for the CRL user, so both would be formally provable incompatible with
the one and only explicitly stated purpose of CRLNumber.

That there is no "shall" language on both issues in X.509 is a
formally provable defect of X.509 -- of which there are *many*.

-Martin








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

Re: [Technical Errata Reported] RFC5912 (3623)

Erwann Abalea — 2013-05-16T19:14:09

2013/5/16 Martin Rex <mrex< at >sap.com>:
[...]

{0, 2, 4, 5, 10, 35, 42} is a monotonically increasing sequence. Each
term is greater than the previous one, the "no hole" property isn't
wanted.
If it was, then the sequence number would be issued from an arithmetic
progression with common difference of 1 (I'm not sure of the
translation, we call it "suite arithmétique de raison 1" in french).

The first CRL does not need to be numbered 0 either.

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