Главная
Как оформить электронный ресурс в списке литературы по госту: Как в списке литературы оформлять интернет-источники

Как оформить электронный ресурс в списке литературы по госту: Как в списке литературы оформлять интернет-источники

RFC 5933 — Использование алгоритмов подписи ГОСТ в записях ресурсов DNSKEY и RRSIG для DNSSEC

(Форматы: ТХТ)

(обновлено: RFC 6944) 

 
 Инженерная рабочая группа Интернета (IETF) В. Долматов, изд.
Запрос комментариев: 5933 Чуприна А.В.
Категория: Трек стандартов И. Устинов
ISSN: 2070-1721 Cryptocom Ltd.
                                                               июль 2010 

               Использование алгоритмов подписи ГОСТ в DNSKEY
                 и записи ресурсов RRSIG для DNSSEC
Абстрактный
   В этом документе описывается, как создавать цифровые подписи и хеш-коды.
   функции по алгоритмам ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94
   для записей ресурсов DNSKEY, RRSIG и DS для использования в домене
   Расширения безопасности системы имен (DNSSEC).
Статус этого меморандума
   Это документ для отслеживания стандартов Интернета.
   Этот документ является продуктом Инженерной группы Интернета.
   (IETF).  Он представляет собой консенсус сообщества IETF. Оно имеет
   получил общественное мнение и был одобрен для публикации
   Руководящая группа по разработке Интернет-технологий (IESG). Дополнительная информация о
   Интернет-стандарты доступны в разделе 2 RFC 5741.
   Информация о текущем статусе этого документа, любых опечатках,
   и как предоставить отзыв о нем можно получить на
   http://www.rfc-editor.org/info/rfc5933.
Уведомление об авторских правах
   Copyright (c) 2010 IETF Trust и лица, указанные в качестве
   авторы документа. Все права защищены.
   Этот документ регулируется BCP 78 и юридическими документами IETF Trust.
   Положения, касающиеся документов IETF
   (http://trustee.ietf.org/license-info) действует на дату
   публикации этого документа. Пожалуйста, ознакомьтесь с этими документами
   внимательно, так как они описывают ваши права и ограничения в отношении
   к этому документу. Компоненты кода, извлеченные из этого документа, должны
   включить текст упрощенной лицензии BSD, как описано в Разделе 4.
 
 
 e
   Доверительные юридические положения и предоставляются без гарантии, поскольку
   описан в Упрощенной лицензии BSD.
Долматов и др. Трек стандартов [Страница 1]
RFC 5933 Использование подписей ГОСТ в DNSSEC, июль 2010 г.
Оглавление
   1. Введение  . . . . . . . . . . . . . . . . . . . . . . . . . 2
     1.1. Терминология. . . . . . . . . . . . . . . . . . . . . . . . 3
   2. Ресурсные записи DNSKEY. . . . . . . . . . . . . . . . . . . . 3
     2.1. Использование открытого ключа с существующей криптографией
           Библиотеки. . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.2. Пример записи ГОСТ DNSKEY . . . . . . . . . . . . . . . . . . 4
   3. Ресурсные записи RRSIG. . . . . . . . . . . . . . . . . . . . 4
     3.1. Пример RRSIG RR . . . . . . . . . . . . . . . . . . . . . 5
   4. Ресурсные записи DS. . . . . . . . . . . . . . . . . . . . . . 5
     4.1. Пример DS RR. . . . . . . . . . . . . . . . . . . . . . . 5
   5. Рекомендации по развертыванию. . . . . . . . . . . .
 
 
  . . . . . . . 6
     5.1. Размеры ключей. . . . . . . . . . . . . . . . . . . . . . . . . 6
     5.2. Размеры подписи. . . . . . . . . . . . . . . . . . . . . . 6
     5.3. Размеры дайджеста. . . . . . . . . . . . . . . . . . . . . . . 6
   6. Вопросы реализации. . . . . . . . . . . . . . . . . 6
     6.1. Поддержка подписей ГОСТ. . . . . . . . . . . . . . . . 6
     6.2. Поддержка отказа от существования NSEC3. . . . . . . . . . . 6
   7. Вопросы безопасности. . . . . . . . . . . . . . . . . . . . 6
   8. Соображения IANA. . . . . . . . . . . . . . . . . . . . . . 7
   9. Благодарности. . . . . . . . . . . . . . . . . . . . . . . . 7
   10. Ссылки. . . . . . . . . . . . . . . . . . . . . . . . . . 7
     10.1. Нормативные ссылки  . . . . . . . . . . . . . . . . . . . 7
     10.2. Информативные ссылки. . . . . . . . . . . . . . . . . . 8
1. Введение
   Система доменных имен (DNS) — это глобальная иерархическая распределенная
   база данных для интернет-именования. DNS был расширен для использования
   криптографические ключи и цифровые подписи для проверки
   достоверность и целостность его данных.
 
  RFC 4033 [RFC4033], RFC 4034
   [RFC4034] и RFC 4035 [RFC4035] описывают эти меры безопасности DNS.
   Расширения, называемые DNSSEC.
   RFC 4034 описывает, как хранить записи ресурсов DNSKEY и RRSIG,
   и указывает список используемых криптографических алгоритмов. Этот
   документ расширяет этот список с помощью алгоритмов подписи и хеширования
   ГОСТ Р 34.10-2001 ([ГОСТ3410], [RFC5832]) и ГОСТ Р 34.11-94
   ([GOST3411], [RFC5831]) и указывает, как хранить данные DNSKEY и
   как создавать записи ресурсов RRSIG с помощью этих алгоритмов.
   Знакомство с DNSSEC, а также с алгоритмами подписи и хеширования ГОСТ.
   предполагается в этом документе.
   Термин «ГОСТ» официально не определен, но обычно используется для
   обратитесь к сборнику российских криптографических алгоритмов
   ГОСТ Р 34.10-2001 [RFC5832], ГОСТ Р 34.11-94 [RFC5831] и
Долматов и др. Трек стандартов [Страница 2]
RFC 5933 Использование подписей ГОСТ в DNSSEC, июль 2010 г.
   ГОСТ 28147-89 [RFC5830]. Поскольку ГОСТ 28147-89 не используется в DNSSEC,
   «ГОСТ» будет относиться только к ГОСТ Р 34.
 
 
 10-2001 и ГОСТ Р 34.11-94 в
   этот документ.
1.1. Терминология
   Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН»,
   "СЛЕДУЕТ", "НЕ СЛЕДУЕТ", "РЕКОМЕНДУЕТСЯ", "МОЖЕТ" и "ДОПОЛНИТЕЛЬНО" в этом
   document должны интерпретироваться, как описано в [RFC2119].
2. Ресурсные записи DNSKEY
   Формат DNSKEY RR можно найти в RFC 4034 [RFC4034].
   Открытые ключи ГОСТ Р 34.10-2001 хранятся по алгоритму
   номер 12.
   Проводной формат открытого ключа совместим с RFC 449.1
   [RFC4491]:
   Согласно [GOST3410] и [RFC5832], открытый ключ — это точка на
   эллиптическая кривая Q = (x,y).
   Электронное представление открытого ключа ДОЛЖНО содержать 64 октета, где
   первые 32 октета содержат представление с прямым порядком байтов x и
   вторые 32 октета содержат прямое представление y.
   Соответствующие параметры открытого ключа определяются
   id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357],
   а параметры дайджеста определяются
   id-GostR3411-94-CryptoProParamSet (1.
 
 
 2.643.2.2.30.1) [RFC4357].
2.1. Использование открытого ключа с существующими криптографическими библиотеками
   На момент написания этой статьи существующие криптографические
   библиотеки способны читать открытые ключи ГОСТ через общий X509
   API, если ключ закодирован в соответствии с RFC 4491 [RFC4491],
   Раздел 2.3.2.
   Чтобы сделать эту кодировку из проводного формата открытого ключа ГОСТ с
   к параметрам, используемым в этом документе, добавьте 64 октета ключа
   данные со следующей 37-байтовой последовательностью:
      0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30
      0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a
      0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40
Долматов и др. Трек стандартов [Страница 3]
RFC 5933 Использование подписей ГОСТ в DNSSEC, июль 2010 г.
2.2. Пример записи ГОСТ DNSKEY
   Учитывая закрытый ключ со следующим значением (значение
   Поле GostAsn1 разделено здесь на две строки для упрощения чтения; в
   файл закрытого ключа, он должен быть в одну строку):
      Формат закрытого ключа: v1.
 
 2
      Алгоритм: 12 (ECC-ГОСТ)
      GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAWICHgeEEIgQg/9M
                iXtXKg9FDXDN/R9CmVhJDyuzRAIgh5tPwCu4NHIs=
   Следующая DNSKEY RR хранит ключ зоны DNS для примера.net:
      пример.net. 86400 В DNSKEY 256 3 12 (
                                   ARS/DcPWGQj2wVJydT8EcAVoC0kXn5pDVm2I
                                   MvDDPXeD32dsSKcmq8KNVzigjL4OXZTV+t/6
                                   w4X1gpNrZiC01g==
                                   ) ; идентификатор ключа = 59732
3. Ресурсные записи RRSIG
   Значение поля подписи в RRSIG RR соответствует RFC 4490.
   [RFC4490] и рассчитывается следующим образом. Значения для RDATA
   поля, предшествующие данным подписи, указаны в RFC 4034.
   [RFC4034].
   хеш = ГОСТ3411(данные)
   где «данные» — это данные формата передачи набора записей ресурсов,
   подписывается, как указано в RFC 4034 [RFC4034].
   Хеш ДОЛЖЕН рассчитываться с параметрами ГОСТ Р 34.11-94
   определяется id-GostR3411-94-CryptoProParamSet [RFC4357].
 
 
 
   Подпись вычисляется из хэша в соответствии с
   ГОСТ Р 34.10-2001, а его формат провода совместим с
   RFC 4490 [RFC4490].
   Цитирую RFC 4490:
   «Алгоритм подписи ГОСТ Р 34.10-2001 формирует цифровой
   подпись в виде двух 256-битных чисел, r и s. Его октет
   строковое представление состоит из 64 октетов, где первый
   32 октета содержат представление s с обратным порядком байтов и второе
   32 октета содержат представление r с обратным порядком байтов.
Долматов и др. Трек стандартов [Страница 4]
RFC 5933 Использование подписей ГОСТ в DNSSEC, июль 2010 г.
3.1. Пример RRSIG RR
   С помощью закрытого ключа из Раздела 2.2 подпишите следующий RRSet,
   состоящая из одной записи A:
      www.example.net. 3600 ДЮЙМОВ 192.0.2.1
   Установка даты начала на 2000-01-01 00:00:00 UTC и
   срок действия до 2030-01-01 00:00:00 UTC, следующая подпись
   РР будет действительным:
     www.example.net. 3600 IN RRSIG A 12 3 3600 20300101000000 (
                                    20000101000000 59732 пример.
 
 net.
                                    7vzzz6iLOmvtjs5FjVjSHT8XnRKFY15ki6Kp
                                    kNPkUnS8iIns0Kv4APT+D9ibmHhGri6Sfbyy
                                    zi67+wBbbW/jrA== )
   Примечание. Алгоритм подписи ECC-GOST использует случайные данные, поэтому
   фактическое вычисленное значение подписи будет отличаться для подписи
   расчеты.
4. Ресурсные записи DS
   ГОСТ Р 34.11-94 алгоритм дайджеста обозначается в DS RR символом
   тип дайджеста 3. Проводной формат значения дайджеста совместим с
   RFC 4490 [RFC4490], то есть дайджест имеет обратный порядок байтов.
   представление.
   Дайджест ДОЛЖЕН всегда рассчитываться с параметрами ГОСТ Р 34.11-94
   определяется id-GostR3411-94-CryptoProParamSet [RFC4357].
4.1. Пример DS RR
   Для ключа подписи ключей (KSK):
      пример.net. 86400 DNSKEY 257 3 12 (
                                   LMgXRHzSbIJGn6i16K+sDjaDf/k1o9DbxScO
                                   geYqYS/rlh3Mf+BRAY3QHPbwoPh3fkDKBroF
                                   SRGR7ZYcx+YIQw==
                                   ) ; идентификатор ключа = 40692
   DS RR будет
      пример. net. 3600 В ДС 40692 12 3 (
                22261A8B0E0D799183E35E24E2AD6BB58533CBA7E3B14D659E9CA09B
                2071398F )
Долматов и др. Трек стандартов [Страница 5]
RFC 5933 Использование подписей ГОСТ в DNSSEC, июль 2010 г.
5. Рекомендации по развертыванию
5.1. Ключевые размеры
   Согласно RFC 4357 [RFC4357], размер открытых ключей ГОСТ
   ДОЛЖЕН быть 512 бит.
5.2. Размеры подписи
   По алгоритму ЭЦП ГОСТ Р 34.10-2001
   спецификация ([GOST3410], [RFC5832]), размер подписи ГОСТ
   составляет 512 бит.
5.3. Размеры дайджеста
   По ГОСТ Р 34.11-94 ([ГОСТ3411], [RFC5831]), размер
   Дайджест ГОСТ составляет 256 бит.
6. Вопросы реализации
6.1. Поддержка подписей ГОСТ
   Реализации, поддерживающие DNSSEC, МОГУТ поддерживать RRSIG и DNSKEY.
   записи ресурсов, созданные с помощью алгоритмов ГОСТ, как определено в этом
   документ.
6.2. Поддержка отказа от существования NSEC3
   Любая реализация DNSSEC-GOST ДОЛЖНА поддерживать как NSEC [RFC4035], так и
   NSEC3 [RFC5155].
7. Вопросы безопасности
   В настоящее время криптостойкость ГОСТ Р 34. 10-2001
   алгоритм цифровой подписи оценивается как 2**128 операций
   вычисление нескольких точек эллиптической кривой по простому модулю порядка
   2**256.
   В настоящее время криптостойкость ГОСТ Р 34.11-94 хеш
   алгоритм оценивается как 2**128 операций вычисления шага
   хэш-функция. (Известен способ сведения этой оценки к
   2**105 операций, но это требует дополнения конфликтующего сообщения
   1024 случайных битовых блока по 256 бит каждый; таким образом, не может быть
   используется в любой практической реализации).
Долматов и др. Трек стандартов [Страница 6]
RFC 5933 Использование подписей ГОСТ в DNSSEC, июль 2010 г.
8. Соображения IANA
   Этот документ обновляет реестр IANA «Алгоритм безопасности DNS».
   Номера" [RFC4034]. Следующие записи были добавлены в
   реестр:
                                      Зона транс.
    Алгоритм значения Мнемоника подписи Sec. Статус ссылок
     12 ГОСТ Р 34.10-2001 ЕСС-ГОСТ Y * RFC 5933 ДОПОЛНИТЕЛЬНО
   Этот документ обновляет назначение типов дайджеста RFC 4034. 
   ([RFC4034], раздел A.2), добавив значение и статус для
   Алгоритм ГОСТ Р 34.11-94:
      Значение Алгоритм Статус
        3 ГОСТ Р 34.11-94 ДОПОЛНИТЕЛЬНО
9. Благодарности
   Этот документ является небольшим расширением RFC 4034 [RFC4034]. Кроме того, мы
   пытался следовать документам RFC 3110 [RFC3110], RFC 4509 [RFC4509],
   и RFC 4357 [RFC4357] для согласованности. Авторы и
   авторы этих документов выражают благодарность за их
   тяжелая работа.
   Следующие люди предоставили дополнительные отзывы, текст и ценные
   ассистенты: Дмитрий Бурков, Яап Аккерхейс, Олафур Гундмундссон,
   Йелте Янсен и Воутер Вейнгаардс.
10. Ссылки
10.1. Нормативные ссылки
   [ГОСТ3410] «Информационные технологии. Криптографическая защита данных.
               Процессы подписания и проверки [электронных]
               электронная подпись.», ГОСТ Р 34.10-2001, Государственный
               Стандарт Российской Федерации, Государственный комитет
               Россия для стандартов, 2001. (на русском языке). 
   [ГОСТ3411] «Информационные технологии. Криптографическая защита данных.
               Хеш-функция.», ГОСТ Р 34.11-94, Государственный
               Стандарт Российской Федерации, Государственный комитет
               Россия для стандартов, 1994. (на русском языке).
   [RFC2119] Брэднер, С., «Ключевые слова для использования в RFC для указания
               Уровни требований», BCP 14, RFC 2119, март 1997 г.
Долматов и др. Трек стандартов [Страница 7]
RFC 5933 Использование подписей ГОСТ в DNSSEC, июль 2010 г.
   [RFC3110] Eastlake 3rd, D., «RSA/SHA-1 SIG и RSA KEYs в
               Система доменных имен (DNS)», RFC 3110, май 2001 г.
   [RFC4033] Арендс Р., Остайн Р., Ларсон М., Мэсси Д. и С.
               Роуз, «Введение и требования безопасности DNS»,
               RFC 4033, март 2005 г.
   [RFC4034] Арендс Р., Остайн Р., Ларсон М., Мэсси Д. и С.
               Роуз, «Ресурсные записи для расширений безопасности DNS»,
               RFC 4034, март 2005 г.
   [RFC4035] Арендс Р. , Остайн Р., Ларсон М., Мэсси Д. и С.
               Роуз, «Модификации протокола для безопасности DNS».
               Расширения», RFC 4035, март 2005 г.
   [RFC4357] Попов В., Курепкин И., Леонтьев С., "Дополнительные
               Криптографические алгоритмы для использования с ГОСТ 28147-89,
               ГОСТ Р 34.10-94, ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94
               Алгоритмы», RFC 4357, январь 2006 г.
   [RFC4490] Леонтьев С., изд. и Чудов Г., ред., "Использование
               ГОСТ 28147-89, ГОСТ Р 34.11-94, ГОСТ Р 34.10-94 и
               ГОСТ Р 34.10-2001 Алгоритмы с криптографическим сообщением.
               Синтаксис (CMS)», RFC 4490, май 2006 г.
   [RFC4491] Леонтьев С., изд. и Д. Шефановский, изд., "Использование
               ГОСТ Р 34.10-94, ГОСТ Р 34.10-2001 и ГОСТ Р 34.11-94
               Алгоритмы с открытым ключом Интернета X.509
               Сертификат инфраструктуры и профиль CRL», RFC 4491,
               май 2006 г.
   [RFC5155] Лори Б., Сиссон Г., Арендс Р.  и Д. Блэка, DNS
               Безопасность (DNSSEC) Хэшированный аутентифицированный отказ от
               Существование», RFC 5155, март 2008 г.
10.2. Информативные ссылки
   [RFC4509] Хардакер, В., «Использование SHA-256 в подписчике делегирования DNSSEC».
               (DS) Ресурсные записи (RR)», RFC 4509, май 2006 г.
   [RFC5830] Долматов В., Ред., «ГОСТ 28147-89: Шифрование,
               Расшифровка и код аутентификации сообщений (MAC)
               Алгоритмы», RFC 5830, март 2010 г.
   [RFC5831] Долматов В., Ред., «ГОСТ Р 34.11-94: Хеш-функция
               Алгоритм», RFC 5831, март 2010 г.
Долматов и др. Трек стандартов [Страница 8]
RFC 5933 Использование подписей ГОСТ в DNSSEC, июль 2010 г.
   [RFC5832] Долматов В., Ред., «ГОСТ Р 34.10-2001: Электронная подпись
               Алгоритм», RFC 5832, март 2010 г.
Адреса авторов
   Василий Долматов (редактор)
   ООО Криптоком.
   ул. Кедрова, 14/2
   Москва, 117218
   Российская Федерация
   Телефон: +7 499 124 6226
   Электронная почта: dol@cryptocom. ru
   Артем Чуприна
   ООО Криптоком.
   ул. Кедрова, 14/2
   Москва, 117218
   Российская Федерация
   Телефон: +7 499 124 6226
   Электронная почта: [email protected]
   Игорь Устинов
   ООО Криптоком.
   ул. Кедрова, 14/2
   Москва, 117218
   Российская Федерация
   Телефон: +7 499 124 6226
   Электронная почта: [email protected]
Долматов и др. Трек стандартов [Страница 9]

Показать RFC

Номер RFC

Ссылки на электронные источники. Ссылки

Основы цитирования электронных источников

Большинство источников, на которые ссылаются студенты Уолдена, будут электронными, поскольку вы в основном используете онлайн-библиотеку. Записи ссылок на электронные источники часто содержат дополнительные компоненты (например, электронную поисковую информацию):

Автор. (Дата публикации). Название документа. Публикация информации или электронного поиска информации.

См. подстраницы для получения подробной информации о том, как цитировать каждый вид электронного источника.

DOI, другой URL-адрес или нет электронной информации для поиска?

Номер DOI или «цифровой идентификатор объекта» — это уникальная буквенно-цифровая строка, которая идентифицирует содержимое и обеспечивает постоянную ссылку на его местоположение в Интернете. DOI — это номер, относящийся к определенному фрагменту и идентифицирующий его среди других цифровых источников. Журнальные статьи обычно имеют DOI, связанный с этой конкретной статьей. В зависимости от того, где можно найти статью, вам может потребоваться указать URL-адрес вместо DOI. Рекомендации по включению DOI или URL-адреса можно найти в APA 7, раздел 9..34.

Вот общие рекомендации:

  • Включайте DOI для всех работ, у которых есть DOI, независимо от того, используете ли вы онлайн-версию или версию для печати.
  • Если у печатной работы нет DOI, не указывайте DOI или URL в ссылке.
  • Если произведение имеет и DOI, и URL-адрес, укажите только DOI.
  • Если онлайн-работа имеет URL-адрес, но не имеет DOI, включите URL-адрес в ссылку следующим образом:
    • Для работ без DOI с веб-сайтов (не включенных в базы данных) укажите URL в ссылке.
    • Для работ без DOI из академических баз данных не включайте URL-адрес или информацию о базе данных в ссылку, поскольку эти работы широко доступны. Ссылка должна быть такой же, как ссылка на печатную версию работы.
  • Другие буквенно-цифровые идентификаторы, такие как Международный стандартный номер книги (ISBN) и Международный стандартный серийный номер (ISSN), не включены в ссылки на стиль APA.

Используйте эту пошаговую блок-схему, чтобы определить, следует ли использовать DOI, другой URL-адрес или не использовать электронную информацию для поиска в качестве источника журнальной статьи.

 

Вы видите DOI в статье?

Часто издатели включают номер в верхний или нижний колонтитул статьи. Он может отображаться в немного другом формате, начиная с http://dx.doi.org, https://doi.org, DOI: или каким-либо другим способом идентификации номера как DOI. Многие номера DOI начинаются с 10.

 

Да      Нет

Форматирование DOI и URL-адресов

  • В APA 7 указывайте как DOI, так и URL-адреса в виде гиперссылок (т. е. начиная с «https://» или «http://»).
  • Используйте параметры отображения по умолчанию в Microsoft Word для гиперссылок (синий шрифт, подчеркивание и гиперссылка). Также допустимо представлять DOI или URL-адрес простым черным текстом без подчеркивания. Будьте последовательны в том, как вы форматируете гиперссылки во всем списке литературы.
  • Ссылки должны быть активными, если работа будет опубликована или прочитана в Интернете.
  • В соответствии с рекомендациями APA 7 и International DOI Foundation отформатируйте DOI следующим образом: https://doi. org/xxxx
  • Не добавляйте точку после DOI или URL-адреса, так как это может помешать работе ссылки
  • См. также наш краткий ответ на часто задаваемые вопросы: «Могу ли я использовать формат DOI, предоставляемый библиотечными базами данных?»

Статья (с DOI)

Альварес. Э. и Типпинс С. (2019). Агенты социализации, которых студенты Пуэрто-Рико используют для принятия финансовых решений. Журнал социальных изменений , 11 (1), 75–85. https://doi.org/10.5590/JOSC.2019.11.1.07

Лапланте, Дж. П., и Нолин, К. (2014). Consultas и социально ответственное инвестирование в Гватемале: тематическое исследование, посвященное взглядам майя на право коренных народов на свободное, предварительное и осознанное согласие. Общество и природные ресурсы , 27 , 231–248. https://doi.org/10.1080/08941920.2013.861554

Укажите номер DOI, если он есть. DOI означает «цифровой идентификатор объекта», номер, характерный для статьи, который может помочь другим найти источник. Используйте CrossRef.org , чтобы найти информацию DOI. Это правило применяется независимо от того, как был осуществлен доступ к источнику (например, в Интернете, на бумаге и т. д.; см. APA 7, Раздел 9)..34).

В APA 7 отформатируйте DOI как веб-адрес. Активные гиперссылки для DOI и URL-адресов следует использовать для документов, предназначенных для чтения с экрана. Представьте эти гиперссылки синим и подчеркнутым текстом (форматирование по умолчанию в Microsoft Word), хотя обычный черный текст также приемлем. Будьте последовательны в выборе форматирования для DOI и URL-адресов во всем списке литературы. (Обратите внимание, что это руководство изменилось по сравнению с APA 6, в котором все форматирование гиперссылок было удалено и активные ссылки не были включены. В APA 6 URL-адреса отображались простым черным шрифтом и не содержали ссылок из документа.)

См. также наш краткий ответ на часто задаваемые вопросы «Могу ли я использовать формат DOI, предоставляемый библиотечными базами данных?»

Джеррентруп А. , Мюллер Т., Гловалла У., Гердер М., Хенрихс Н., Нойбауэр А. и Шефер Дж. Р. (2018). Обучение медицине с помощью «Dr. Дом.” PLoS ONE , 13 (3), артикул e0193972. https://doi.org/10.1371/journal.pone.0193972

Для журнальных статей, которым присвоены номера статей, а не диапазоны страниц, укажите номер статьи вместо диапазона страниц.

Дополнительные сведения о цитировании электронных ресурсов см. в разделе Ссылки на электронные источники.

Статья (без DOI)

Найдено в Общей базе данных академических исследований или в печати

Casler , T. (2020). Улучшение опыта медсестер для выпускников за счет поддержки на платформе социальных сетей. МЕДСУРГ Сестринское дело , 29 (2), 83–87.

Если статья не имеет DOI и вы получили ее из общей базы данных академических исследований через университетскую библиотеку, нет необходимости включать какую-либо дополнительную информацию для электронного поиска. Запись в списке литературы выглядит как запись для печатной копии статьи. (Этот формат отличается от рекомендаций APA 6, которые рекомендовали включать URL-адрес домашней страницы журнала, когда DOI был недоступен.)

Обратите внимание, что в APA 7 есть дополнительные рекомендации по записям списка литературы для статей, которые можно найти только в определенных базах данных или архивах, таких как Кокрановская база данных систематических обзоров, UpToDate, ProQuest Dissertations и Thes Global, а также в университетских архивах. Дополнительную информацию см. в APA 7, раздел 9.30.

 

Найдено на веб-сайте открытого доступа

Eaton, T. V., & Akers, MD (2007). Информирование о нарушениях и хорошее управление. Журнал CPA , 77 (6), 66–71. http://archives.cpajournal.com/2007/607/essentials/p58.htm

Укажите прямой веб-адрес/URL журнальной статьи, найденной в открытом Интернете, часто на веб-сайте журнала с открытым доступом.

Оставить комментарий