GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5011

Network Working Group M. StJohns Request for Comments: 5011 Independent Category: Standards Track September 2007

      Automated Updates of DNS Security (DNSSEC) Trust Anchors

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Abstract

 This document describes a means for automated, authenticated, and
 authorized updating of DNSSEC "trust anchors".  The method provides
 protection against N-1 key compromises of N keys in the trust point
 key set.  Based on the trust established by the presence of a current
 anchor, other anchors may be added at the same place in the
 hierarchy, and, ultimately, supplant the existing anchor(s).
 This mechanism will require changes to resolver management behavior
 (but not resolver resolution behavior), and the addition of a single
 flag bit to the DNSKEY record.

StJohns Standards Track [Page 1] RFC 5011 Trust Anchor Update September 2007

Table of Contents

 1. Introduction ....................................................2
    1.1. Compliance Nomenclature ....................................3
 2. Theory of Operation .............................................3
    2.1. Revocation .................................................4
    2.2. Add Hold-Down ..............................................4
    2.3. Active Refresh .............................................5
    2.4. Resolver Parameters ........................................6
         2.4.1. Add Hold-Down Time ..................................6
         2.4.2. Remove Hold-Down Time ...............................6
         2.4.3. Minimum Trust Anchors per Trust Point ...............6
 3. Changes to DNSKEY RDATA Wire Format .............................6
 4. State Table .....................................................6
    4.1. Events .....................................................7
    4.2. States .....................................................7
 5. Trust Point Deletion ............................................8
 6. Scenarios - Informative .........................................9
    6.1. Adding a Trust Anchor ......................................9
    6.2. Deleting a Trust Anchor ....................................9
    6.3. Key Roll-Over .............................................10
    6.4. Active Key Compromised ....................................10
    6.5. Stand-by Key Compromised ..................................10
    6.6. Trust Point Deletion ......................................10
 7. IANA Considerations ............................................11
 8. Security Considerations ........................................11
    8.1. Key Ownership vs. Acceptance Policy .......................11
    8.2. Multiple Key Compromise ...................................12
    8.3. Dynamic Updates ...........................................12
 9. Normative References ...........................................12
 10. Informative References ........................................12

1. Introduction

 As part of the reality of fielding DNSSEC (Domain Name System
 Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has
 come to the realization that there will not be one signed name space,
 but rather islands of signed name spaces each originating from
 specific points (i.e., 'trust points') in the DNS tree.  Each of
 those islands will be identified by the trust point name, and
 validated by at least one associated public key.  For the purpose of
 this document, we'll call the association of that name and a
 particular key a 'trust anchor'.  A particular trust point can have
 more than one key designated as a trust anchor.
 For a DNSSEC-aware resolver to validate information in a DNSSEC
 protected branch of the hierarchy, it must have knowledge of a trust
 anchor applicable to that branch.  It may also have more than one

StJohns Standards Track [Page 2] RFC 5011 Trust Anchor Update September 2007

 trust anchor for any given trust point.  Under current rules, a chain
 of trust for DNSSEC-protected data that chains its way back to ANY
 known trust anchor is considered 'secure'.
 Because of the probable balkanization of the DNSSEC tree due to
 signing voids at key locations, a resolver may need to know literally
 thousands of trust anchors to perform its duties (e.g., consider an
 unsigned ".COM").  Requiring the owner of the resolver to manually
 manage these many relationships is problematic.  It's even more
 problematic when considering the eventual requirement for key
 replacement/update for a given trust anchor.  The mechanism described
 herein won't help with the initial configuration of the trust anchors
 in the resolvers, but should make trust point key
 replacement/rollover more viable.
 As mentioned above, this document describes a mechanism whereby a
 resolver can update the trust anchors for a given trust point, mainly
 without human intervention at the resolver.  There are some corner
 cases discussed (e.g., multiple key compromise) that may require
 manual intervention, but they should be few and far between.  This
 document DOES NOT discuss the general problem of the initial
 configuration of trust anchors for the resolver.

1.1. Compliance Nomenclature

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in BCP 14, [RFC2119].

2. Theory of Operation

 The general concept of this mechanism is that existing trust anchors
 can be used to authenticate new trust anchors at the same point in
 the DNS hierarchy.  When a zone operator adds a new SEP key (i.e., a
 DNSKEY with the Secure Entry Point bit set) (see [RFC4034], Section
 2.1.1) to a trust point DNSKEY RRSet, and when that RRSet is
 validated by an existing trust anchor, then the resolver can add the
 new key to its set of valid trust anchors for that trust point.
 There are some issues with this approach that need to be mitigated.
 For example, a compromise of one of the existing keys could allow an
 attacker to add their own 'valid' data.  This implies a need for a
 method to revoke an existing key regardless of whether or not that
 key is compromised.  As another example, assuming a single key
 compromise, we need to prevent an attacker from adding a new key and
 revoking all the other old keys.

StJohns Standards Track [Page 3] RFC 5011 Trust Anchor Update September 2007

2.1. Revocation

 Assume two trust anchor keys A and B.  Assume that B has been
 compromised.  Without a specific revocation bit, B could invalidate A
 simply by sending out a signed trust point key set that didn't
 contain A.  To fix this, we add a mechanism that requires knowledge
 of the private key of a DNSKEY to revoke that DNSKEY.
 A key is considered revoked when the resolver sees the key in a
 self-signed RRSet and the key has the REVOKE bit (see Section 7
 below) set to '1'.  Once the resolver sees the REVOKE bit, it MUST
 NOT use this key as a trust anchor or for any other purpose except to
 validate the RRSIG it signed over the DNSKEY RRSet specifically for
 the purpose of validating the revocation.  Unlike the 'Add' operation
 below, revocation is immediate and permanent upon receipt of a valid
 revocation at the resolver.
 A self-signed RRSet is a DNSKEY RRSet that contains the specific
 DNSKEY and for which there is a corresponding validated RRSIG record.
 It's not a special DNSKEY RRSet, just a way of describing the
 validation requirements for that RRSet.
 N.B.: A DNSKEY with the REVOKE bit set has a different fingerprint
 than one without the bit set.  This affects the matching of a DNSKEY
 to DS records in the parent [RFC3755], or the fingerprint stored at a
 resolver used to configure a trust point.
 In the given example, the attacker could revoke B because it has
 knowledge of B's private key, but could not revoke A.

2.2. Add Hold-Down

 Assume two trust point keys A and B.  Assume that B has been
 compromised.  An attacker could generate and add a new trust anchor
 key C (by adding C to the DNSKEY RRSet and signing it with B), and
 then invalidate the compromised key.  This would result in both the
 attacker and owner being able to sign data in the zone and have it
 accepted as valid by resolvers.
 To mitigate but not completely solve this problem, we add a hold-down
 time to the addition of the trust anchor.  When the resolver sees a
 new SEP key in a validated trust point DNSKEY RRSet, the resolver
 starts an acceptance timer, and remembers all the keys that validated
 the RRSet.  If the resolver ever sees the DNSKEY RRSet without the
 new key but validly signed, it stops the acceptance process for that
 key and resets the acceptance timer.  If all of the keys that were

StJohns Standards Track [Page 4] RFC 5011 Trust Anchor Update September 2007

 originally used to validate this key are revoked prior to the timer
 expiring, the resolver stops the acceptance process and resets the
 timer.
 Once the timer expires, the new key will be added as a trust anchor
 the next time the validated RRSet with the new key is seen at the
 resolver.  The resolver MUST NOT treat the new key as a trust anchor
 until the hold-down time expires AND it has retrieved and validated a
 DNSKEY RRSet after the hold-down time that contains the new key.
 N.B.: Once the resolver has accepted a key as a trust anchor, the key
 MUST be considered a valid trust anchor by that resolver until
 explicitly revoked as described above.
 In the given example, the zone owner can recover from a compromise by
 revoking B and adding a new key D and signing the DNSKEY RRSet with
 both A and B.
 The reason this does not completely solve the problem has to do with
 the distributed nature of DNS.  The resolver only knows what it sees.
 A determined attacker who holds one compromised key could keep a
 single resolver from realizing that the key had been compromised by
 intercepting 'real' data from the originating zone and substituting
 their own (e.g., using the example, signed only by B).  This is no
 worse than the current situation assuming a compromised key.

2.3. Active Refresh

 A resolver that has been configured for an automatic update of keys
 from a particular trust point MUST query that trust point (e.g., do a
 lookup for the DNSKEY RRSet and related RRSIG records) no less often
 than the lesser of 15 days, half the original TTL for the DNSKEY
 RRSet, or half the RRSIG expiration interval and no more often than
 once per hour.  The expiration interval is the amount of time from
 when the RRSIG was last retrieved until the expiration time in the
 RRSIG.  That is, queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL,
 1/2*RRSigExpirationInterval))
 If the query fails, the resolver MUST repeat the query until
 satisfied no more often than once an hour and no less often than the
 lesser of 1 day, 10% of the original TTL, or 10% of the original
 expiration interval.  That is, retryTime = MAX (1 hour, MIN (1 day,
 .1 * origTTL, .1 * expireInterval)).

StJohns Standards Track [Page 5] RFC 5011 Trust Anchor Update September 2007

2.4. Resolver Parameters

2.4.1. Add Hold-Down Time

 The add hold-down time is 30 days or the expiration time of the
 original TTL of the first trust point DNSKEY RRSet that contained the
 new key, whichever is greater.  This ensures that at least two
 validated DNSKEY RRSets that contain the new key MUST be seen by the
 resolver prior to the key's acceptance.

2.4.2. Remove Hold-Down Time

 The remove hold-down time is 30 days.  This parameter is solely a key
 management database bookeeping parameter.  Failure to remove
 information about the state of defunct keys from the database will
 not adversely impact the security of this protocol, but may end up
 with a database cluttered with obsolete key information.

2.4.3. Minimum Trust Anchors per Trust Point

 A compliant resolver MUST be able to manage at least five SEP keys
 per trust point.

3. Changes to DNSKEY RDATA Wire Format

 Bit 8 of the DNSKEY Flags field is designated as the 'REVOKE' flag.
 If this bit is set to '1', AND the resolver sees an RRSIG(DNSKEY)
 signed by the associated key, then the resolver MUST consider this
 key permanently invalid for all purposes except for validating the
 revocation.

4. State Table

 The most important thing to understand is the resolver's view of any
 key at a trust point.  The following state table describes this view
 at various points in the key's lifetime.  The table is a normative
 part of this specification.  The initial state of the key is 'Start'.
 The resolver's view of the state of the key changes as various events
 occur.
 This is the state of a trust-point key as seen from the resolver.
 The column on the left indicates the current state.  The header at
 the top shows the next state.  The intersection of the two shows the
 event that will cause the state to transition from the current state
 to the next.

StJohns Standards Track [Page 6] RFC 5011 Trust Anchor Update September 2007

                           NEXT STATE
         --------------------------------------------------
  FROM   |Start  |AddPend |Valid  |Missing|Revoked|Removed|
 ----------------------------------------------------------
 Start   |       |NewKey  |       |       |       |       |
 ----------------------------------------------------------
 AddPend |KeyRem |        |AddTime|       |       |       |
 ----------------------------------------------------------
 Valid   |       |        |       |KeyRem |Revbit |       |
 ----------------------------------------------------------
 Missing |       |        |KeyPres|       |Revbit |       |
 ----------------------------------------------------------
 Revoked |       |        |       |       |       |RemTime|
 ----------------------------------------------------------
 Removed |       |        |       |       |       |       |
 ----------------------------------------------------------
                         State Table

4.1. Events

 NewKey   The resolver sees a valid DNSKEY RRSet with a new SEP key.
          That key will become a new trust anchor for the named trust
          point after it's been present in the RRSet for at least 'add
          time'.
 KeyPres  The key has returned to the valid DNSKEY RRSet.
 KeyRem   The resolver sees a valid DNSKEY RRSet that does not contain
          this key.
 AddTime  The key has been in every valid DNSKEY RRSet seen for at
          least the 'add time'.
 RemTime  A revoked key has been missing from the trust-point DNSKEY
          RRSet for sufficient time to be removed from the trust set.
 RevBit   The key has appeared in the trust anchor DNSKEY RRSet with
          its "REVOKED" bit set, and there is an RRSig over the DNSKEY
          RRSet signed by this key.

4.2. States

 Start    The key doesn't yet exist as a trust anchor at the resolver.
          It may or may not exist at the zone server, but either
          hasn't yet been seen at the resolver or was seen but was
          absent from the last DNSKEY RRSet (e.g., KeyRem event).

StJohns Standards Track [Page 7] RFC 5011 Trust Anchor Update September 2007

 AddPend  The key has been seen at the resolver, has its 'SEP' bit
          set, and has been included in a validated DNSKEY RRSet.
          There is a hold-down time for the key before it can be used
          as a trust anchor.
 Valid    The key has been seen at the resolver and has been included
          in all validated DNSKEY RRSets from the time it was first
          seen through the hold-down time.  It is now valid for
          verifying RRSets that arrive after the hold-down time.
          Clarification: The DNSKEY RRSet does not need to be
          continuously present at the resolver (e.g., its TTL might
          expire).  If the RRSet is seen and is validated (i.e.,
          verifies against an existing trust anchor), this key MUST be
          in the RRSet, otherwise a 'KeyRem' event is triggered.
 Missing  This is an abnormal state.  The key remains a valid trust-
          point key, but was not seen at the resolver in the last
          validated DNSKEY RRSet.  This is an abnormal state because
          the zone operator should be using the REVOKE bit prior to
          removal.
 Revoked  This is the state a key moves to once the resolver sees an
          RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet
          contains this key with its REVOKE bit set to '1'.  Once in
          this state, this key MUST permanently be considered invalid
          as a trust anchor.
 Removed  After a fairly long hold-down time, information about this
          key may be purged from the resolver.  A key in the removed
          state MUST NOT be considered a valid trust anchor.  (Note:
          this state is more or less equivalent to the "Start" state,
          except that it's bad practice to re-introduce previously
          used keys -- think of this as the holding state for all the
          old keys for which the resolver no longer needs to track
          state.)

5. Trust Point Deletion

 A trust point that has all of its trust anchors revoked is considered
 deleted and is treated as if the trust point was never configured.
 If there are no superior configured trust points, data at and below
 the deleted trust point are considered insecure by the resolver.  If
 there ARE superior configured trust points, data at and below the
 deleted trust point are evaluated with respect to the superior trust
 point(s).
 Alternately, a trust point that is subordinate to another configured
 trust point MAY be deleted by a resolver after 180 days, where such a

StJohns Standards Track [Page 8] RFC 5011 Trust Anchor Update September 2007

 subordinate trust point validly chains to a superior trust point.
 The decision to delete the subordinate trust anchor is a local
 configuration decision.  Once the subordinate trust point is deleted,
 validation of the subordinate zone is dependent on validating the
 chain of trust to the superior trust point.

6. Scenarios - Informative

 The suggested model for operation is to have one active key and one
 stand-by key at each trust point.  The active key will be used to
 sign the DNSKEY RRSet.  The stand-by key will not normally sign this
 RRSet, but the resolver will accept it as a trust anchor if/when it
 sees the signature on the trust point DNSKEY RRSet.
 Since the stand-by key is not in active signing use, the associated
 private key may (and should) be provided with additional protections
 not normally available to a key that must be used frequently (e.g.,
 locked in a safe, split among many parties, etc).  Notionally, the
 stand-by key should be less subject to compromise than an active key,
 but that will be dependent on operational concerns not addressed
 here.

6.1. Adding a Trust Anchor

 Assume an existing trust anchor key 'A'.
 1.  Generate a new key pair.
 2.  Create a DNSKEY record from the key pair and set the SEP and Zone
     Key bits.
 3.  Add the DNSKEY to the RRSet.
 4.  Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
     'A'.
 5.  Wait for various resolvers' timers to go off and for them to
     retrieve the new DNSKEY RRSet and signatures.
 6.  The new trust anchor will be populated at the resolvers on the
     schedule described by the state table and update algorithm -- see
     Sections 2 and 4 above.

6.2. Deleting a Trust Anchor

 Assume existing trust anchors 'A' and 'B' and that you want to revoke
 and delete 'A'.

StJohns Standards Track [Page 9] RFC 5011 Trust Anchor Update September 2007

 1.  Set the revocation bit on key 'A'.
 2.  Sign the DNSKEY RRSet with both 'A' and 'B'.  'A' is now revoked.
     The operator should include the revoked 'A' in the RRSet for at
     least the remove hold-down time, but then may remove it from the
     DNSKEY RRSet.

6.3. Key Roll-Over

 Assume existing keys A and B. 'A' is actively in use (i.e. has been
 signing the DNSKEY RRSet).  'B' was the stand-by key. (i.e. has been
 in the DNSKEY RRSet and is a valid trust anchor, but wasn't being
 used to sign the RRSet).
    1.  Generate a new key pair 'C'.
    2.  Add 'C' to the DNSKEY RRSet.
    3.  Set the revocation bit on key 'A'.
    4.  Sign the RRSet with 'A' and 'B'.
 'A' is now revoked, 'B' is now the active key, and 'C' will be the
 stand-by key once the hold-down expires.  The operator should include
 the revoked 'A' in the RRSet for at least the remove hold-down time,
 but may then remove it from the DNSKEY RRSet.

6.4. Active Key Compromised

 This is the same as the mechanism for Key Roll-Over (Section 6.3)
 above, assuming 'A' is the active key.

6.5. Stand-by Key Compromised

 Using the same assumptions and naming conventions as Key Roll-Over
 (Section 6.3) above:
    1.  Generate a new key pair 'C'.
    2.  Add 'C' to the DNSKEY RRSet.
    3.  Set the revocation bit on key 'B'.
    4.  Sign the RRSet with 'A' and 'B'.
 'B' is now revoked, 'A' remains the active key, and 'C' will be the
 stand-by key once the hold-down expires.  'B' should continue to be
 included in the RRSet for the remove hold-down time.

6.6. Trust Point Deletion

 To delete a trust point that is subordinate to another configured
 trust point (e.g., example.com to .com) requires some juggling of the
 data.  The specific process is:

StJohns Standards Track [Page 10] RFC 5011 Trust Anchor Update September 2007

 1.  Generate a new DNSKEY and DS record and provide the DS record to
     the parent along with DS records for the old keys.
 2.  Once the parent has published the DSs, add the new DNSKEY to the
     RRSet and revoke ALL of the old keys at the same time, while
     signing the DNSKEY RRSet with all of the old and new keys.
 3.  After 30 days, stop publishing the old, revoked keys and remove
     any corresponding DS records in the parent.
 Revoking the old trust-point keys at the same time as adding new keys
 that chain to a superior trust prevents the resolver from adding the
 new keys as trust anchors.  Adding DS records for the old keys avoids
 a race condition where either the subordinate zone becomes unsecure
 (because the trust point was deleted) or becomes bogus (because it
 didn't chain to the superior zone).

7. IANA Considerations

 The IANA has assigned a bit in the DNSKEY flags field (see Section 7
 of [RFC4034]) for the REVOKE bit (8).

8. Security Considerations

 In addition to the following sections, see also Theory of Operation
 above (Section 2) and especially Section 2.2 for related discussions.
 Security considerations for trust anchor rollover not specific to
 this protocol are discussed in [RFC4986].

8.1. Key Ownership vs. Acceptance Policy

 The reader should note that, while the zone owner is responsible for
 creating and distributing keys, it's wholly the decision of the
 resolver owner as to whether to accept such keys for the
 authentication of the zone information.  This implies the decision to
 update trust-anchor keys based on trusting a current trust-anchor key
 is also the resolver owner's decision.
 The resolver owner (and resolver implementers) MAY choose to permit
 or prevent key status updates based on this mechanism for specific
 trust points.  If they choose to prevent the automated updates, they
 will need to establish a mechanism for manual or other out-of-band
 updates, which are outside the scope of this document.

StJohns Standards Track [Page 11] RFC 5011 Trust Anchor Update September 2007

8.2. Multiple Key Compromise

 This scheme permits recovery as long as at least one valid trust-
 anchor key remains uncompromised, e.g., if there are three keys, you
 can recover if two of them are compromised.  The zone owner should
 determine their own level of comfort with respect to the number of
 active, valid trust anchors in a zone and should be prepared to
 implement recovery procedures once they detect a compromise.  A
 manual or other out-of-band update of all resolvers will be required
 if all trust-anchor keys at a trust point are compromised.

8.3. Dynamic Updates

 Allowing a resolver to update its trust anchor set based on in-band
 key information is potentially less secure than a manual process.
 However, given the nature of the DNS, the number of resolvers that
 would require update if a trust anchor key were compromised, and the
 lack of a standard management framework for DNS, this approach is no
 worse than the existing situation.

9. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
            Signer (DS)", RFC 3755, May 2004.
 [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
            Rose, "DNS Security Introduction and Requirements", RFC
            4033, March 2005.
 [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
            Rose, "Resource Records for the DNS Security Extensions",
            RFC 4034, March 2005.
 [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
            Rose, "Protocol Modifications for the DNS Security
            Extensions", RFC 4035, March 2005.

10. Informative References

 [RFC4986]  Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy,
            "Requirements Related to DNS Security (DNSSEC) Trust
            Anchor Rollover", RFC 4986, August 2007.

StJohns Standards Track [Page 12] RFC 5011 Trust Anchor Update September 2007

Author's Address

 Michael StJohns
 Independent
 EMail: mstjohns@comcast.net

StJohns Standards Track [Page 13] RFC 5011 Trust Anchor Update September 2007

Full Copyright Statement

 Copyright (C) The IETF Trust (2007).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at
 ietf-ipr@ietf.org.

StJohns Standards Track [Page 14]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5011.txt · Last modified: 2007/09/04 21:31 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki