Знак 4.2.1 Объезд препятствия справа
Типоразмер – это набор геометрических параметров дорожных знаков в зависимости от области их применения. Типоразмеры изображений знаков стандартной формы в зависимости от условий применения должны выбираться в соответствии с таблицей:
ГОСТ 32945-2014
| Типоразмер знака | Условия применения знаков |
| 1 | Автомобильные дороги с расчетной скоростью движения до 60 км/ч включительно (без усовершенствованного покрытия) |
| 2 | Автомобильные дороги с расчетной скоростью движения более 60 км/ч до 100 км/ч включительно (с усовершенствованного покрытия) |
| 3 | Автомобильные дороги с расчетной скоростью движения 120 км/ч и двумя полосами движения |
| 4 | Автомобильные дороги с расчетной скоростью движения 120 км/ч и более и четырьмя и более полосами движения |
| 5 | Места производства работ на автомобильных дорогах с расчетной скоростью движения 140 км/ч и более |
ГОСТ Р 52290-2004
| Типоразмер знака | Вне населенных пунктов | В населенных пунктах |
| I | Дороги с одной полосой | Дороги местного значения |
| II | Дороги с двумя и тремя полосами | Магистральные дороги |
| III | Дороги с четырьмя и более полосами и автомагистрали | Скоростные дороги |
| IV | Ремонтные работы на автомагистралях, опасные участки на других дорогах при обосновании целесообразности применения. | |
Знак 4.2.2 Объезд препятствия слева
Типоразмер – это набор геометрических параметров дорожных знаков в зависимости от области их применения. Типоразмеры изображений знаков стандартной формы в зависимости от условий применения должны выбираться в соответствии с таблицей:
ГОСТ 32945-2014
| Типоразмер знака | Условия применения знаков |
| 1 | Автомобильные дороги с расчетной скоростью движения до 60 км/ч включительно (без усовершенствованного покрытия) |
| 2 | Автомобильные дороги с расчетной скоростью движения более 60 км/ч до 100 км/ч включительно (с усовершенствованного покрытия) |
| 3 | Автомобильные дороги с расчетной скоростью движения 120 км/ч и двумя полосами движения |
| 4 | Автомобильные дороги с расчетной скоростью движения 120 км/ч и более и четырьмя и более полосами движения |
| 5 | Места производства работ на автомобильных дорогах с расчетной скоростью движения 140 км/ч и более |
ГОСТ Р 52290-2004
| Типоразмер знака | Вне населенных пунктов | В населенных пунктах |
| I | Дороги с одной полосой | Дороги местного значения |
| II | Дороги с двумя и тремя полосами | Магистральные дороги |
| III | Дороги с четырьмя и более полосами и автомагистрали | Скоростные дороги |
| IV | Ремонтные работы на автомагистралях, опасные участки на других дорогах при обосновании целесообразности применения. | |
Тема 3.4. Дорожные знаки. Предписывающие знаки — Учебник
В отличие от запрещающих знаков, которые мы рассматривали в предыдущей главе, все, что находится внутри голубого круга, делать не запрещено, а даже нужно.
Несмотря на свой добродушный вид, предписывающие знаки довольно строгие.
Знаками 4.1.1 «Движение прямо», 4.1.2 «Движение направо», 4.1.3 «Движение налево», 4.1.4 «Движение прямо или направо», 4.1.5 «Движение прямо или налево», 4.1.6 «Движение направо или налево» разрешается движение
Вы, конечно, можете свернуть и в другую сторону. Только за проезд вне правил придется заплатить. Если успеете. Ведь часто подобные знаки устанавливают, чтобы водитель случайно не выехал на полосу встречного движения…
Если один из этих знаков установлен перед пересечением дорог, то после выезда с перекрестка он утрачивает свою силу. Чтобы стало понятнее, разберем следующую экзаменационную задачу:
Как следует поступить, если Вам необходимо развернуться?
1. Развернуться на этом перекрёстке при отсутствии на нём других транспортных средств.
2. Проехать прямо и развернуться за перекрёстком.
3. Проехать прямо и развернуться только на следующем перекрёстке.
Перед перекрестком установлен знак , а значит он действует только на зону перекрестка. Знак разрешает движение только прямо, поэтому пересечение дорог придется проехать в прямом направлении, даже, если кроме вас на пересечении дорог никого нет. Поэтому первый вариант ответа отпадает.
Конечно, можно ехать дальше, как предписывает нам третий вариант ответа, но за одним перекрестком может оказаться и другой, запрещающий разворот. А потом и третий. Так легко и за городом оказаться. Но нам-то надо в другую сторону. К тому же знак после перекрестка свое действие утратил. Выходит, правильный ответ – 2.
Впрочем, не нарушая Правил, развернуться можно было бы и на самом перекрестке, если бы он имел два пересечения проезжих частей. Если перекресток имеет разделительную полосу (которая делит проезжую часть на две смежные), то в этом случае знак действует только на первое пересечение. После разделительной полосы, действие знака заканчивается.
Если какой-то из знаков 4.1.1-4.1.6 установлен в начале улицы, то он действует до следующего перекрестка, однако не запрещает въезд направо во двор, поскольку водитель не создаст таким маневром помех другим участникам дорожного движения.
Про категоричность данной группы знаков нужно обязательно помнить, решая задачи ПДД.
Например, если знак предписывает движение направо, то нужно категорично ехать направо. Прямо нельзя не на метр!
Вам можно продолжить движение:
1. Только по траектории А.
2. Только по траектории Б.
3. По любой траектории из указанных.
Верный ответ – только по траектории А, ведь чтобы повернуть на дорогу Б, вам придется немного проехать прямо, а знак делать это запрещает.
Впрочем, есть исключения. Первое касается разворота.
Знаки, разрешающие движение налево, разрешают и разворот. А что, вполне логично: сходил налево, погулял и обратно вернулся :)
Второе исключение: действие знаков 4.1.1-4.1.6 не распространяется на маршрутные транспортные средства.
Следующая группа знаков указывает, как нужно объезжать препятствия, встречающиеся на дороге.
Знаки 4.2.1 «Объезд препятствия справа» и 4.2.2 «Объезд препятствия слева» разрешают объезд только с той стороны, на которую указывает стрелка.
При этом вас не должен смущать выезд на «встречку» или проезд по тротуару. В зоне действия этих знаков вас не накажут, так как знаки главнее разметки, а временные знаки главнее постоянных.
Знак 4.2.3 «Объезд препятствия справа или слева» разрешает объезд с любой стороны.
Обычно такие знаки применяются временно – для объезда ремонтных работ на проезжей части. Но иногда они устанавливаются на постоянной основе для указания направлений объезда ограждений, установленных по оси проезжей части, или в начале разделительной полосы.
После объезда препятствия действие данных знаков прекращается.
Знаком 4.3 «Круговое движение» обозначается перекресток, на котором движение имеет отличительную особенность: оно совершается по направлению стрелок на знаке. При правостороннем движении, как в России, ехать придется против часовой стрелки.
С конца 2017 года движение по кругу на перекрестке, обозначенным знаком , стало считаться главной дорогой. Так что подъезжая к перекрестку с круговым движением, уступи дорогу тем, кто уже крутится.
До постановления Правительства РФ от 08.11.2017 года схемы движения разнились от региона к региону. И даже в одном городе – от перекрестка к перекрестку. Но с введением единой схемы путаницу удастся избежать.
Въезжать на круговой перекресток можно с любой полосы, а выезжать – только с правой.
Пешеход всегда прав, пока жив. Велосипедист по своей прочности уступает даже пешеходу, так что прав он еще меньше.
Впрочем, велосипедистов нынче много. Чтобы они не путались под ногами и колесами чиновники создают специально для них отдельные дороги (или отделяют кусок от проезжей части), обозначая их знаком 4.4.1 «Велосипедная дорожка».
Велодорожки имеют ряд преимуществ. Туда запрещено въезжать на механических транспортных средствах, в том числе использовать дорожки для остановки или стоянки. Пешеходы, правда, имеют право использовать велосипедную дорожку, но лишь при отсутствии тротуара или пешеходной дорожки и если они не будут создавать помехи движению велосипедов.
Кстати, на мопедах по велодорожке кататься нельзя. Не стоит путать знак со знаком 5.14.2 «Полоса для велосипедистов» , который мы подробно рассмотрим в следующей главе. Последний действительно разрешает движение мопедов по полосе, а первый – нет.
Чтобы закрепить эту информацию, давайте решим следующую экзаменационную задачу:
Какие из указанных знаков запрещают движение водителям мопедов?
1. Только А.
2. Только Б.
3. В и Г.
4. Все.
Верный вариант – 4. Знаки «А», «В» и «Г» разрешают дальнейшее передвижение только пешеходам или велосипедистам. Знак «Б» (о нем мы подробно расскажем в следующей главе) обозначает полосу для маршрутных транспортных средств.
Знак 4.4.2 «Конец велосипедной дорожки» утверждает, что лафа кончилась – «выделенки» для спортсменов на двух колесах дальше нет. Увы.
В зоне действия знака 4.5.1. «Пешеходная дорожка» разрешается движение только пешеходам. А еще велосипедистам, водителям мопедов, скутеров и мотоциклов. Правда им придется спешиться – тогда по Правилам они мгновенно превратятся в тыкву пешеходов.
Возможен и совмещенный вариант дорожки для велосипедистов и пешеходов. Ее называют велопешеходной. Знаки 4.5.2 и 4.5.3 указывает на то, что дорожка с совмещенным движением начинается или заканчивается. Остальные четыре знака отделили котлеты от мух пешеходов от велосипедистов.
Следующий знак взбодрит тех, кто не торопится.
На знаке 4.6 «Ограничение минимальной скорости» прописана нижняя граница скорости, с которой необходимо продолжать движение.
Обычно вывешивая данный знак со стрелочкой под ним, водителей машин-тихоходов просят сдвинуться поправее, освобождая левую полосу для тех, кто в состоянии ехать быстрее вместо того, чтобы плестись в «пробке» за грузовиками.
В данном случае водители, которые могут ехать более 50 км/ч, выскакивают на левую полосу и разряжают «пробку».
На то, что феличита закончилась, указывает знак 4.7 «Конец зоны ограничения минимальной скорости».
С российскими ухабами на дорогах и водителями-разгильдяями за рулем любой перевозимый груз может стать опасным. Особенно, если его неправильно упаковать.
Чтобы автомобилисты, перевозящие опасные грузы, не сошли с маршрута, для них придумали предписывающие знаки 4.8.1- 4.8.3 «Направление движения транспортных средств с опасными грузами», определяющие, куда им ехать – прямо, направо или налево.
Знак 4.1.2 — Движение направо
Какие знаки обязывают водителя грузового автомобиля с разрешенной максимальной массой до 3,5 т повернуть направо?
| 1. | Только А. | |
| 2. | Только Б. | |
| 3. | А и Б. | |
| 4. | Б и В. |
Ответ.
| Только предписывающий знак Б «Движение направо» всегда обязывает водителя повернуть направо. Его действие не распространяется только на маршрутные ТС. | |
| Знак А «Выезд на дорогу с односторонним движением» не обязывает вас ехать в указанном направлении — можно пересечь перекресток в прямом направлении или развернуться. | |
| Знак В «Направление движения для грузовых автомобилей» показывает рекомендуемое направление движения для грузовых автомобилей, тракторов и самоходных механизмов в случаях запрещения их движения в одном из направлений. |
Правильный ответ — Только Б.
Обязаны ли Вы включить указатели поворота в данной ситуации?
| 1. | Да, но только при наличии на перекрестке других транспортных средств. | |
| 2. | Да. | |
| 3. | Нет. |
На данном перекрестке, руководствуясь знаком «Движение направо» , Вы можете продолжить движение только направо. При этом Вы обязаны включить соответствующие этому маневру правые световые указатели поворота.
По какой траектории Вы можете продолжить движение?
| 1. | Только по А. | |
| 2. | Только по Б. | |
| 3. | По любой. |
На этом перекрестке на пересекаемой дороге три проезжие части. Знак «Движение направо» распространяет свое действие только на первое пересечение проезжих частей, перед которым он установлен, предписывая всем ТС поворот направо на первую проезжую часть, т.е. только по траектории А.
По какой траектории Вы можете выполнить правый поворот?
| 1. | Только по А. | |
| 2. | Только по Б. | |
| 3. | По любой. |
Поворачивая направо, вы должны двигаться ближе к правому краю проезжей части, т.е. по траектории А.
Вам разрешено продолжить движение:
Вы можете продолжить движение только по траектории Б, так как, повернув по траектории А, вы не выполните требование двигаться по возможности ближе к правому краю проезжей части, а продолжать дальнейшее движение по полосе для маршрутных ТС по траектории В запрещено.
Каким транспортным средствам разрешается продолжить движение только направо?
| 1. | Транспортным средствам с разрешенной максимальной массой более 10 т. | |
| 2. | Только транспортным средствам, перевозящим груз массой более 10 т. | |
| 3. | Только транспортным средствам с фактической массой более 10 т. |
Под знаком 4.1.2 «Движение направо» размещена табличка 8.11 «Ограничение разрешенной максимальной массы» , которая указывает, что действие знака распространяется на ТС с разрешенной массой более 10 т, которые и должны повернуть направо.
особенности каждого, какой из них главнее
В данной статье рассмотрим очень актуальные вопросы, касаемо дорожных знаков и правила использования указателей поворотов. В частности, вопросы о приоритете символов «Уступи дорогу» и «Стоп».
Также нужно ли показывать свой манёвр при изменении траектории движения, а также изменения в направлении главной дороги. Темы и ситуации, которые волнуют многих начинающих водителей, а так же водителей с большим стажем вождения.
Что такое знак «Уступи дорогу» 2.4
Как правило, он устанавливается перед перекрестком, а также перед местом пересечения проезжих дорог. Имеет форму перевернутого треугольника, с белым фоном и красной рамкой по периметру.
Первостепенная задача знака «Уступи дорогу», согласно ПДД 2017 года, заключается в регулировании приоритетности проезда при нерегулируемых пересечениях проезжий частей, а также при неработающем светофоре.
Что делать, если установлены два знака: Уступи дорогу и Стоп? Смотрите видео:
Автомобилист обязан уступить автомобилям, идущим по пересекаемой дороге. Водитель, который попадает под действие символа 2.4, обязан не принуждать автомобилиста, идущим по главной дороге изменять свою траекторию движения.
Автомобиль, съезжающий со второстепенной дороги при необходимости должен снижать свою скорость вплоть до полной останови – чтобы не создавать помеху транспорта по главной дороге. (пп. 1.2, 13.9 ПДД РФ).
Пункт 13. ПДД. Проезд перекрестков
13.9. На перекрестке неравнозначных дорог водитель транспортного средства, движущегося по второстепенной дороге, должен уступить дорогу транспортным средствам, приближающимся по главной, независимо от направления их дальнейшего движения.
На таких перекрестках трамвай имеет преимущество перед безрельсовыми транспортными средствами, движущимися в попутном или встречном направлении по равнозначной дороге, независимо от направления его движения.
Данный знак имеет силу, как в населенном пункте, так и за его пределами.
«Движение без остановки запрещено» 2.5
Если вы подъезжаете к данному символу, в зоне его действия необходимо остановиться. Данный знак изображается в виде красного восьмиугольника с белой каемкой, в центре которого написано «STOP».
Данный знак располагается в местах, где движение не слишком интенсивное, например, перед железнодорожными переездами, или в местах, где приоритетность проезда контролируется знаком, а не дорожным покрытием.
Знаки Стоп и Уступи дорогу. Фото: myshared.ru
Так же знак устанавливается в местах повышенной опасности, в связи с плохой видимостью из-за географических, или техногенных объектов.
Как совершить разворот не нарушив ПДД? Смотрите здесь.
Является более строгим, нежели символ 2.4 «Уступи дорогу», так как заставляет автомобилиста остановиться пред линией стоп-движения (если она есть), или в местах прямого перекрещиванием проезжих путей (если ее нет).
Какой символ является приоритетным: 2,4 или 2,5
При пересечении, или совершении маневра для поворота или разворота на перекрестке, в местах где установлены оба символа 2.5 и 2.4 руководствоваться правилом «помеха с правой стороны». Или по обоюдному согласию водителей, путем световых индикаций.
Что говорят знаки Стоп и Уступи дорогу? Фото: uslide.ru
Нужно ли сигнализировать, если главная дорога меняет вектор движения
Если главная дорога меняет вектор движения при подъезде к перекрестку, тогда при совершении поворота влево или вправо требуется показать сигнал в сторону совершения маневра. Если при подъезде к перекрестку, вам нужно двигаться прямо, то показывать сигнал поворота не нужно, т.к. можно обмануть остальных участников движения.
Как правильно совершать обгон? Читайте по ссылке.
Если проезжая часть НЕ изменяет направление
При угловом соединении на местности второстепенной дороги с главной, водителю требуется обозначить свой маневр при съезде на второстепенную дорогу. В случае с продолжением движения по доминирующей дороге, указывать маневр не нужно. Данная инструкция не зависит от угла присоединения дорог друг к другу.
Нужно ли останавливаться перед знаком Стоп? Смотрите видео:
Заключение
Соблюдайте скоростной режим, а также правила переезда нерегулируемых перекрестков. В любом случае, нужно учиться читать дорогу заранее. От этого зависит не только ваша безопасность, но и жизнь других участников движения.
Позвоните по телефону +7 (495) 725-58-91 или задайте вопрос и получите ответ юриста через 5 минут. Консультация бесплатная!
ГОСТ Р 52289-2019 Технические средства организации дорожного движения. Правила применения дорожных знаков, разметки, светофоров, дорожных ограждений и направляющих устройств (с Поправкой)
ГОСТ Р 52289-2019
____________________________________________________________________
Текст Сравнения ГОСТ Р 52289-2019 с ГОСТ Р 52289-2004 см. по ссылке.
— Примечание изготовителя базы данных.
__________________________________________________________________
ОКС 93.080.30
Дата введения 2020-04-01
Предисловие
1 РАЗРАБОТАН Федеральным автономным учреждением «Российский дорожный научно-исследовательский институт» (ФАУ «РОСДОРНИИ») Министерства транспорта Российской Федерации
2 ВНЕСЕН Техническим комитетом по стандартизации ТК 278 «Безопасность дорожного движения»
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 20 декабря 2019 г. N 1425-ст
4 ВЗАМЕН ГОСТ Р 52289-2004
5 Стандарт полностью соответствует требованиям Конвенции о дорожных знаках и сигналах (Вена, 1968 г.) и Европейского соглашения, дополняющего эту Конвенцию* (Женева, 1971 г.), с учетом поправок (1995 г.)
________________
* Доступ к международным и зарубежным документам, упомянутым в тексте, можно получить, обратившись в Службу поддержки пользователей. — Примечание изготовителя базы данных.
Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты«, а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты«. В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты«. Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)
ВНЕСЕНА поправка, опубликованная в ИУС N 10, 2020 год
Поправка внесена изготовителем базы данных
1 Область применения
Настоящий стандарт устанавливает правила применения технических средств организации дорожного движения: дорожных знаков, дорожной разметки, дорожных светофоров, а также боковых дорожных ограждений и направляющих устройств на автомобильных дорогах общего пользования, улицах и дорогах городов и сельских поселений (далее, кроме раздела 8, — дорогах).
Примечание — Настоящий стандарт распространяется на прилегающие территории по [1], кроме 5.1.4, 5.1.6, 5.1.14, 5.4.22, 5.7.19.
2 Нормативные ссылки
В настоящем стандарте использованы нормативные ссылки на следующие документы:
ГОСТ 19433 Грузы опасные. Классификация и маркировка
ГОСТ 23407 Ограждения инвентарные строительных площадок и участков производства строительно-монтажных работ. Технические условия
ГОСТ 32757 Дороги автомобильные общего пользования. Временные технические средства организации дорожного движения. Классификация
ГОСТ 32758 Дороги автомобильные общего пользования. Временные технические средства организации дорожного движения. Технические требования и правила применения
ГОСТ 32759 Дороги автомобильные общего пользования. Дорожные тумбы. Технические требования
ГОСТ 32843 Дороги автомобильные общего пользования. Столбики сигнальные дорожные. Технические требования
ГОСТ 32846 Дороги автомобильные общего пользования. Элементы обустройства. Классификация
ГОСТ 32865 Дороги автомобильные общего пользования. Знаки переменной информации. Технические требования
ГОСТ 32866 Дороги автомобильные общего пользования. Световозвращатели дорожные. Технические требования
ГОСТ 32945 Дороги автомобильные общего пользования. Знаки дорожные. Технические требования
ГОСТ 32948 Дороги автомобильные общего пользования. Опоры дорожных знаков. Технические требования
ГОСТ 32952 Дороги автомобильные общего пользования. Разметка дорожная. Методы контроля
ГОСТ 32953 Дороги автомобильные общего пользования. Разметка дорожная. Технические требования
ГОСТ 32964 Дороги автомобильные общего пользования. Искусственные неровности сборные. Технические требования. Методы контроля
ГОСТ 33062 Дороги автомобильные общего пользования. Требования к размещению объектов дорожного и придорожного сервиса
ГОСТ 33078 Дороги автомобильные общего пользования. Методы измерения сцепления колеса автомобиля с покрытием
ГОСТ 33127 Дороги автомобильные общего пользования. Ограждения дорожные. Классификация
ГОСТ 33128 Дороги автомобильные общего пользования. Ограждения дорожные. Технические требования
ГОСТ 33129 Дороги автомобильные общего пользования. Ограждения дорожные. Методы контроля
ГОСТ 33151 Дороги автомобильные общего пользования. Элементы обустройства. Технические требования. Правила применения
ГОСТ 33153 Дороги автомобильные общего пользования. Проектирование тоннелей. Общие требования
ГОСТ 33220 Дороги автомобильные общего пользования. Требования к эксплуатационному состоянию
ГОСТ 33385 Дороги автомобильные общего пользования. Дорожные светофоры. Технические требования
ГОСТ Р 50597 Автомобильные дороги и улицы. Требования к эксплуатационному состоянию, допустимому по условиям обеспечения безопасности дорожного движения. Методы контроля
ГОСТ Р 50970 Технические средства организации дорожного движения. Столбики сигнальные дорожные. Общие технические требования. Правила применения
ГОСТ Р 50971 Технические средства организации дорожного движения. Световозвращатели дорожные. Общие технические требования. Правила применения
ГОСТ Р 51256 Технические средства организации дорожного движения. Разметка дорожная. Классификация. Технические требования
ГОСТ Р 52282 Технические средства организации дорожного движения. Светофоры дорожные. Типы и основные параметры. Общие технические требования. Методы испытаний
ГОСТ Р 52290 Технические средства организации дорожного движения. Знаки дорожные. Общие технические требования
ГОСТ Р 52605 Технические средства организации дорожного движения. Искусственные неровности. Общие технические требования. Правила применения
ГОСТ Р 52721 Технические средства организации дорожного движения. Методы испытаний дорожных ограждений
ГОСТ Р 52766 Дороги автомобильные общего пользования. Элементы обустройства. Общие требования
ГОСТ Р 55691/ISO/TS 15624 Системы управления и информации на транспорте. Системы оповещения о дорожных происшествиях (TIWS). Требования к системе
ГОСТ Р 58350 Автомобильные дороги общего пользования. Технические средства организации дорожного движения в местах производства работ. Технические требования. Правила применения
ГОСТ Р 58351 Дороги автомобильные общего пользования. Ограждения дорожные фронтальные, удерживающие боковые комбинированные и удерживающие пешеходные. Общие технические требования. Методы испытаний и контроля. Правила применения
ГОСТ Р ИСО 23600 Вспомогательные технические средства для лиц с нарушением функций зрения и лиц с нарушением функций зрения и слуха. Звуковые и тактильные сигналы дорожных светофоров
СП 34.13330 «СНиП 2.05.02-85* Автомобильные дороги»
СП 42.13330 «СНиП 2.07.01-89* Градостроительство. Планировка и застройка городских и сельских поселений»
Примечание — При пользовании настоящим стандартом целесообразно проверить действие ссылочных стандартов (сводов правил) в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет или по ежегодному информационному указателю «Национальные стандарты», который опубликован по состоянию на 1 января текущего года, и по выпускам ежемесячного информационного указателя «Национальные стандарты» за текущий год. Если заменен ссылочный документ, на который дана недатированная ссылка, то рекомендуется использовать действующую версию этого документа с учетом всех внесенных в данную версию изменений. Если заменен ссылочный документ, на который дана датированная ссылка, то рекомендуется использовать версию этого документа с указанным выше годом утверждения (принятия). Если после утверждения настоящего стандарта в ссылочный документ, на который дана датированная ссылка, внесено изменение, затрагивающее положение, на которое дана ссылка, то это положение рекомендуется применять без учета данного изменения. Если ссылочный документ отменен без замены, то положение, в котором дана ссылка на него, рекомендуется применять в части, не затрагивающей эту ссылку. Сведения о действии сводов правил целесообразно проверить в Федеральном информационном фонде стандартов.
3 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1
временные технические средства организации дорожного движения: Комплекс устройств, применяемых на дорогах для обеспечения безопасности дорожного движения и повышения пропускной способности дороги в течение периода, вызвавшего необходимость временного изменения организации дорожного движения. |
3.2
дорожный знак (знак): Техническое средство организации движения с обозначениями и/или надписями, информирующими участников дорожного движения о дорожных условиях и режимах движения, расположении населенных пунктов и других объектах. |
3.3 знак основной: Знак, необходимость установки которого определяется дорожными условиями в соответствии с требованиями настоящего стандарта.
3.4 знак дублирующий: Знак, установленный в том же поперечном сечении дороги, что и основной знак, служащий для повышения надежности восприятия информации участниками движения.
3.5 знак предварительный: Знак, установленный до основного знака и предупреждающий водителей о предстоящем изменении режима движения или объекте, информация о которых содержится на основном знаке.
3.6 знак повторный: Знак, установленный за основным знаком и подтверждающий его информацию.
3.7 знак дополнительной информации (табличка): Знак, уточняющий или ограничивающий действие знаков, с которыми он применен, либо содержащий иную информацию для участников дорожного движения.
3.8
знак переменной информации; ЗПИ: Техническое средство организации дорожного движения, предназначенное для отображения дорожных знаков, за исключением знаков индивидуального проектирования. |
3.9
разметка дорожная: Линии, надписи и другие обозначения на проезжей части автомобильной дороги, искусственных сооружениях и элементах обустройства дорог, информирующие участников дорожного движения об условиях и режимах движения на участке дороги. |
3.10 островок безопасности: Элемент обустройства дороги, разделяющий полосы движения (в том числе полосы для велосипедистов), а также полосы движения и трамвайные пути, конструктивно выделенный бордюрным камнем над проезжей частью дороги или обозначенный техническими средствами организации дорожного движения и предназначенный для остановки пешеходов при переходе проезжей части дороги.
Примечание — К островку безопасности может относиться часть разделительной полосы, через которую проложен пешеходный переход.
3.11
островок направляющий: Островок, расположенный в одном уровне с проезжей частью, либо приподнятый над ней и обеспечивающий благоприятные условия разделения и слияния транспортных потоков. |
3.12
светофор дорожный: Светосигнальное устройство, применяемое для регулирования очередности пропуска транспортных средств и пешеходов. |
3.13 светофорный объект: Группа дорожных светофоров (далее — светофоров), установленных на участке улично-дорожной сети, очередность движения по которому конфликтующих транспортных средств или транспортных средств и пешеходов регулируется светофорной сигнализацией, работающей в едином цикле.
3.14
дорожное ограждение: Устройство, предназначенное для обеспечения движения транспорта с наименьшими рисками столкновений и съездов с дорог, предотвращения переезда через разделительную полосу, столкновения со встречным транспортным средством, наезда на массивные препятствия и сооружения, расположенные на обочине в полосе отвода дороги, на разделительной полосе, снижения риска возможности падения пешеходов с дороги или мостового сооружения, а также для упорядочения движения пешеходов и предотвращения выхода животных на проезжую часть. |
3.15 высота ограждения: Расстояние в вертикальной плоскости от наиболее высокой точки ограждения до уровня обочины, покрытия на мостовом сооружении, разделительной полосе или проезжей части (при установке ограждения на тротуаре или газоне), измеренное у края ограждения со стороны проезжей части.
Примечание — Для пешеходного ограждения высотой является расстояние от наиболее высокой точки ограждения до уровня покрытия тротуара (разделительной полосы).
3.16 конструктивно выделенная разделительная полоса: элемент дороги, разделяющий смежные проезжие части и не предназначенный для движения и остановки транспортных средств, выделенный с помощью одного или нескольких следующих элементов обустройства: дорожными ограждениями, бордюрным камнем, направляющими устройствами, противоослепляющими экранами, а также газоном и обозначенный линиями разметки 1.2*.
_______________
* Здесь и далее указаны номера разметки по ГОСТ Р 51256-2018.
3.17
динамический прогиб дорожного удерживающего бокового ограждения (прогиб): Наибольшее горизонтальное смещение лицевой поверхности ограждения в поперечном направлении относительно лицевой поверхности недеформированного ограждения при наезде на него транспортного средства (автомобиля). |
3.18
рабочая ширина дорожного ограждения: Максимальное динамическое боковое смещение кузова транспортного средства или фрагмента дорожного ограждения (в зависимости от места установки дорожного ограждения) относительно лицевой поверхности недеформированного дорожного ограждения. |
3.19
направляющие устройства: Технические средства, предназначенные для зрительного ориентирования участников дорожного движения. |
4 Общие положения
4.1 Технические средства организации дорожного движения допускается применять в случаях, не предусмотренных настоящим стандартом, если их применение необходимо для целей обеспечения безопасности и организации дорожного движения.
4.2 В полосе отвода дороги, в том числе на разделительной полосе и обочинах, не допускается размещать посторонние предметы, не являющиеся элементами обустройства и не имеющие отношения к организации движения, а также наносить на проезжую часть и элементы обустройства дороги изображения, которые могут быть приняты за дорожные знаки или иные технические средства организации дорожного движения, либо могут снижать их видимость или эффективность, либо ослеплять участников движения или отвлекать их внимание, создавая тем самым опасность для дорожного движения.
Не допускается размещать на знаках, на их оборотной стороне, светофорах и опорах, на которых они расположены, на путепроводах и надземных пешеходных переходах наружную рекламу, средства наружной рекламы и другие приспособления (устройства), не имеющие отношения к организации движения и не относящиеся к специальным техническим средствам, которые работают в автоматическом режиме и имеют функции фото- и киносъемки, видеозаписи, для обеспечения контроля за дорожным движением.
4.3 Знаки и светофоры (условные обозначения — по таблице А.1 приложения А) размещают таким образом, чтобы они воспринимались только участниками движения, для которых они предназначены, и не были закрыты какими-либо препятствиями (наружной рекламой, средствами ее размещения, зелеными насаждениями, опорами наружного освещения и т.п.), другими знаками и (или) светофорами, иными элементами обустройства, обеспечивали удобство эксплуатации и уменьшали вероятность их повреждения.
4.4 Временные и стационарные знаки и светофоры, не предназначенные для действующей схемы организации движения, допускается закрывать чехлами, исключающими возможность прочтения изображения знаков, сигналов светофора.
Временную разметку наносят и демаркируют в соответствии с ГОСТ Р 58350.
4.5 Владельцы автомобильных дорог по разрешению подразделения Госавтоинспекции на федеральном уровне могут применять в экспериментальных целях технические средства организации дорожного движения, не предусмотренные действующими стандартами.
При этом владельцами автомобильных дорог предоставляется следующая информация:
— цели и задачи эксперимента;
— сроки и перечень мест проведения эксперимента;
— ожидаемый результат;
— методика оценки эффективности технических средств организации дорожного движения и их восприятия участниками дорожного движения;
— техническая документация на техническое решение (изделие).
Для информирования участников дорожного движения о назначении такого технического средства устанавливают транспаранты, разъясняющие смысл проводимого эксперимента.
5 Правила применения дорожных знаков
5.1 Общие требования
5.1.1 Номера, наименования и изображения дорожных знаков приведены в приложении Б.
5.1.2 Знаки, в том числе временные, устанавливаемые на дороге, должны соответствовать требованиям ГОСТ 32945 или ГОСТ Р 52290, размещаться на опорах по ГОСТ 32948 и в процессе эксплуатации отвечать требованиям ГОСТ 33220 и ГОСТ Р 50597.
Допускается размещать знаки на опорах освещения при соблюдении расстояний по 5.1.7.
5.1.3 Действие знаков распространяется на проезжую часть, тротуар, обочину, трамвайные пути, велосипедную, велопешеходную или пешеходную дорожки, у которых или над которыми они установлены.
5.1.4 Расстояние видимости знака должно быть не менее 100 м.
В населенных пунктах* при ограничении скорости 40 км/ч и менее допускается обеспечивать расстояние видимости знака не менее 50 м.
_______________
* Здесь и далее под населенным пунктом понимается участок улично-дорожной сети, обозначенный знаками 5.23.1 или 5.23.2.
5.1.5 Знаки устанавливают справа от проезжей части или над нею, вне обочины (при ее наличии) так, чтобы их лицевая поверхность была обращена в сторону прямого направления движения, за исключением случаев, оговоренных настоящим стандартом.
Опоры дорожных знаков не должны мешать передвигаться лицам в инвалидных колясках.
5.1.6 На дорогах с двумя и более полосами движения в данном направлении знаки 1.1, 1.2, 1.20.1-1.20.3, 1.25, 2.4, 2.5, 3.24**, установленные справа от проезжей части, должны дублироваться. Знаки 3.20 и 3.22 дублируются на дорогах с одной полосой для движения в каждом направлении, знак 5.15.6 — на дорогах с тремя полосами для движения в обоих направлениях.
_______________
** Здесь и далее указаны номера знаков по ГОСТ Р 52290-2004.
Дублирующие знаки устанавливают на конструктивно выделенной разделительной полосе.
На дорогах с разделительной полосой, выделенной только разметкой 1.2, или без разделительной полосы дублирующие знаки устанавливают:
— слева от проезжей части в случаях, когда встречное движение осуществляется по одной или двум полосам;
— над проезжей частью в случаях, когда встречное движение осуществляется по трем или более полосам.
При необходимости допускается дублировать таким же образом и другие знаки.
На дорогах с тремя и более полосами для движения во встречном направлении допускается дублирование временных дорожных знаков на разделительной полосе, выделенной только разметкой 1.2, при ее отсутствии временные знаки дублируются слева от проезжей части.
В населенных пунктах на дорогах с двухсторонним движением с двумя и более полосами для движения в данном направлении***, а также на дорогах с односторонним движением с тремя и более полосами, и вне населенных пунктов на всех дорогах знак 5.19.1 дублируют над проезжей частью. Знак 5.19.1 над проезжей частью размещают не ближе оси крайней правой полосы движения относительно края проезжей части.
_______________
*** Здесь и далее учитываются переходно-скоростные полосы, дополнительные полосы на подъеме, полосы для маршрутных транспортных средств и т.п.
5.1.7 Расстояние от края проезжей части (при наличии обочины — от бровки земляного полотна) до ближайшего к ней края знака, установленного сбоку от проезжей части, должно быть от 0,5 до 2,5 м (рисунки В.1а, б приложения В), до края знаков особых предписаний 5.23.1, 5.24.1, 5.25, 5.26 и информационных знаков 6.9.1, 6.9.2, 6.10.1-6.12, 6.17 — от 0,5 до 5,0 м.
Расстояние от края проезжей части до ближайшего к ней края знака, установленного на конструктивно выделенной разделительной полосе шириной 6 м и более, должно быть не менее 2,0 м, шириной от 6 до 3 м — не менее 1,0 м.
5.1.8 Расстояние от нижнего края знака (без учета знаков 1.4.1-1.4.6, а в ненаселенных пунктах и табличек) до поверхности дорожного покрытия (высота установки), кроме случаев, специально оговоренных настоящим стандартом, должно быть:
— от 1,5 до 3,0 м — при установке сбоку от проезжей части вне населенных пунктов (рисунок В.1а), от 2,0 до 4,0 м — в населенных пунктах (рисунок В.1б), от 3,0 до 4,0 м — на конструктивно выделенной разделительной полосе шириной менее 3 м;
— от 0,6 до 1,5 м — при установке на конструктивно выделенных направляющих островках или островках безопасности, а также на проезжей части или обочине на переносных опорах по ГОСТ Р 58350 или на переносных передвижных комплексах по ГОСТ 32758;
— от 5,0 до 6,0 м — при размещении над проезжей частью. Допускается увеличивать это расстояние с учетом требований 5.1.15. Знаки, размещенные на пролетных строениях искусственных сооружений, расположенных на высоте менее 5,0 м от поверхности дорожного покрытия, не должны выступать за их нижний край.
Высоту установки знаков, расположенных сбоку от проезжей части, определяют от поверхности дорожного покрытия на краю проезжей части.
Очередность размещения знаков разных групп на одной опоре (сверху вниз, слева направо), кроме случаев, оговоренных настоящим стандартом, должна быть следующей:
— знаки приоритета;
— предупреждающие знаки;
— предписывающие знаки;
— знаки особых предписаний;
— запрещающие знаки;
— информационные знаки;
— знаки сервиса.
На протяжении одной дороги высота установки знаков должна быть по возможности одинаковой.
5.1.9 Знаки устанавливают непосредственно перед перекрестком, пересечением проезжих частей, местом разворота, объектом сервиса и т.д., а при необходимости — на расстоянии не более 25 м в населенных пунктах и 50 м — вне населенных пунктов перед ними, кроме случаев, оговоренных настоящим стандартом.
Знаки, вводящие ограничения и режимы, устанавливают в начале участков, где это необходимо, а отменяющие ограничения и режимы — в конце, кроме случаев, оговоренных настоящим стандартом.
5.1.10 Установка знаков на обочинах, оградах, фасадах домов и объектов капитального строительства допустима в стесненных условиях (у обрывов, выступов скал, парапетов, в исторических частях городов и т.п.). При этом расстояние между краем проезжей части и ближайшим к ней краем знака должно быть не менее 1 м, а высота установки — от 2 до 3 м вне населенных пунктов (рисунок В.1в), от 2 до 4 м — в населенных пунктах.
5.1.11 Знаки, устанавливаемые на конструктивно выделенных разделительной полосе, островках безопасности и направляющих островках или обочине в случае отсутствия дорожных ограждений размещают на травмобезопасных опорах по ГОСТ 32948. Верхний обрез фундамента опоры знака выполняют в одном уровне с поверхностью разделительной полосы, островка безопасности и направляющего островка, обочины или присыпной бермы.
5.1.12 В местах проведения работ на дороге и при временных оперативных изменениях организации движения знаки на переносных опорах, переносных или передвижных комплексах допускается устанавливать на проезжей части, обочинах и разделительной полосе.
5.1.13 Расстояние между ближайшими краями соседних знаков, размещенных на одной опоре и распространяющих свое действие на одну и ту же проезжую часть, должно быть от 50 до 200 мм.
Знаки на одной опоре, распространяющие свое действие на разные проезжие части одного направления движения, располагают над соответствующими проезжими частями или максимально приближают к ним с учетом технических возможностей и требований настоящего стандарта.
5.1.14 В одном поперечном сечении дороги устанавливают не более трех знаков без учета знаков 5.15.2, дублирующих знаков, знаков дополнительной информации, а также знаков 1.34.1-1.34.3 в местах производства работ, вне населенных пунктов — на одной опоре не более двух временных знаков и не более одного знака дополнительной информации (таблички).
Изображения знаков сервиса допускается размещать на одном щите прямоугольной формы с фоном синего цвета с учетом требований ГОСТ 32945 и ГОСТ Р 52290, при этом один щит с изображениями знаков сервиса принимают за один знак.
Знаки, кроме установленных на перекрестках, остановочных пунктах маршрутных транспортных средств, в местах устройства искусственных неровностей и производства дорожных работ, а также кроме знака 6.4, установленного совместно с табличками 8.6.1-8.6.9 и 8.17, располагают вне населенных пунктов на расстоянии не менее 50 м, в населенных пунктах — не менее 15 м друг от друга, с учетом обеспечения видимости.
(Поправка. ИУС N 10-2020).
5.1.15 Знаки устанавливают на расстоянии не менее 1 м от проводов воздушных линий электропередачи напряжением не более 1 кВ включительно, более 1 кВ — по согласованию с сетевой организацией. В пределах охранной зоны воздушных линий размещение знаков на тросах-растяжках запрещается.
5.1.16 Типоразмеры знаков по ГОСТ Р 52290 принимают по таблице 1, кроме случаев, оговоренных настоящим стандартом. Допускается по этой же таблице принимать типоразмеры знаков по ГОСТ 32945. При необходимости допускается применять знаки большего типоразмера.
На одной дороге предпочтительно применять знаки одного типоразмера, соответствующего одному из вышеуказанных стандартов.
Высоту прописной буквы на информационных знаках индивидуального проектирования выбирают в соответствии с таблицей 2.
Таблица 1 — Типоразмеры знаков
Типоразмер | Типоразмер | Применение знаков | |
знака по ГОСТ Р 52290 | знака по ГОСТ 32945 | вне населенных пунктов | в населенных пунктах |
I | 1 | Дороги с одной полосой | Улицы и дороги местного значения, парковые дороги, проезды, улицы и дороги сельских поселений |
II | 3 | Дороги с двумя и тремя полосами | Магистральные городские дороги (кроме скоростного движения), магистральные улицы |
III | 4 | Дороги с четырьмя и более полосами и автомагистрали | Магистральные городские дороги скоростного движения |
IV | 5 | Места производства работ на автомобильных дорогах IА и IБ технической категории, опасные участки на других дорогах при обосновании целесообразности применения | Места производства работ на магистральных городских дорогах скоростного движения |
Знаки типоразмера 1 по ГОСТ 32945 применяют в населенных пунктах на улицах и дорогах с одной полосой для движения в каждом направлении. Допускается применение знаков квадратной формы со стороной 500 мм. Примечание — Классификация дорог вне населенных пунктов — по СП 34.13330. Классификация улиц и дорог в населенных пунктах — по СП 42.13330. | |||
Таблица 2 — Высота прописной буквы на знаках индивидуального проектирования
Высота прописной | Знаки 5.23.1, 5.24.1, 5.25, 5.26, 6.9.1, 6.9.2, 6.10.1-6.12 | |
буквы, мм | вне населенных пунктов | в населенных пунктах |
75, 100 или 150 | Дороги с одной полосой | Улицы и дороги местного значения, парковые дороги, проезды, улицы и дороги сельских поселений |
150, 200 или 250 | — | Магистральные дороги (кроме скоростного движения), магистральные улицы |
200, 250 или 300 | Дороги с двумя и тремя полосами | Магистральные городские дороги скоростного движения |
300 или 400 | Дороги с четырьмя и более полосами | — |
400 или 500 | Автомагистрали | — |
Примечания 1 Классификация дорог вне населенных пунктов — по СП 34.13330. Классификация улиц и дорог в населенных пунктах — по СП 42.13330. 2 Высота прописной буквы на знаках 6.14.1 и 6.14.2 — 150 мм, на знаке 6.17 — 200 мм вне населенных пунктов, 100 мм — в населенных пунктах. | ||
5.1.17 Знаки, изготовленные с использованием пленки типа Б или В по ГОСТ Р 52290 применяют на дорогах (участках дорог) с числом полос четыре и более, на кривых в плане с радиусом менее допустимого, на пересечениях с железными дорогами в одном уровне, пересечениях и примыканиях дорог в одном уровне, участках дорог с расстояниями видимости в плане или профиле менее минимальных значений (таблица 4), на мостовых сооружениях с шириной проезжей части, равной или менее ширины проезжей части дороги, в местах проведения дорожных работ.
Знаки, изготовленные с использованием световозвращающей пленки типа В, следует применять:
— на дорогах (участках дорог) в населенных пунктах с числом полос шесть и более;
— автомагистралях;
— участках дорог с искусственным освещением вне населенных пунктов.
При установке над проезжей частью или сбоку от нее на высоте более 3 м предпочтительно применять знаки с использованием световозвращающей пленки типа В.
На участках одной дороги с одинаковым числом полос движения следует применять знаки, изготовленные с использованием световозвращающей пленки одного типа.
Не допускается применять дорожные знаки, изготовленные с использованием световозвращающей пленки типа А, на автомобильных дорогах федерального значения.
На щитах со световозвращающей флуоресцентной пленкой желто-зеленого цвета применяют знаки 1.1, 1.2, 1.22, 1.23, 5.19.1 и 5.19.2. Другие знаки (кроме знаков по 5.1.19 и знаков 2.1, 2.2, 2.4, 2.5) допускается применять на таких щитах в местах концентрации дорожно-транспортных происшествий (ДТП) и для профилактики их возникновения на опасных участках.
5.1.18 Фотометрические параметры ЗПИ выбирают в зависимости от классов по ГОСТ 32865 в соответствии с таблицей 3.
Таблица 3 — Фотометрические параметры ЗПИ
Категория дороги | Фотометрический параметр | |
Яркость | Ширина светового пучка | |
Автомагистрали, скоростные дороги и магистральные городские дороги | L2 — L3, L3*, | В1-В3 |
Другие дороги и улицы | L1, L1 (Т) | В4-В7 |
Примечания 1 L3* — при особых условиях эксплуатации по ГОСТ 32865. 2 L1 (Т) — L3 (Т) — классы для тоннелей. В тоннелях используют значения яркости цветов ЗПИ, соответствующие освещенности не более 400 лк. | ||
5.1.19 Временные дорожные знаки 1.8, 1.15, 1.16, 1.18-1.21, 1.33, 2.6, 3.11-3.16, 3.18.1-3.25, 8.23 с желтым фоном, применяют в течение периода, вызвавшего необходимость временного изменения организации дорожного движения. При этом знаки 1.8, 1.15, 1.16, 1.18-1.21, 1.33, 2.6, 3.11-3.16, 3.18.1-3.25, выполненные на белом фоне, закрывают чехлами, исключающими возможность прочтения изображения знаков, или демонтируют.
5.2 Предупреждающие знаки
5.2.1 Предупреждающие знаки применяют для информирования водителей о характере опасности и приближении к опасному участку дороги, движение по которому требует принятия мер, соответствующих обстановке.
5.2.2 Предупреждающие знаки, кроме знаков 1.3.1-1.4.6, 1.34.1-1.34.3, устанавливают вне населенных пунктов на расстоянии от 150 до 300 м, а в населенных пунктах — на расстоянии от 50 до 100 м до начала опасного участка в зависимости от разрешенной максимальной скорости движения, условий видимости и возможности размещения.
Допускается устанавливать предупреждающие знаки на ином расстоянии, указываемом в этом случае на табличке 8.1.1.
5.2.3 Повторные предупреждающие знаки с табличкой 8.1.1, кроме знаков 1.4.1-1.4.6, допускается устанавливать между перекрестком и началом опасного участка в случаях, если расстояние между ними составляет от 20 до 150 м вне населенных пунктов и от 20 до 50 м — в населенных пунктах (рисунок В.2а). Повторные знаки 1.1, 1.2, 1.5, 1.9, 1.10, 1.23, 1.25 устанавливают обязательно.
Предупреждающий знак с табличкой 8.1.3 или 8.1.4 при расстоянии между перекрестком и началом опасного участка менее 20 м допускается устанавливать на пересекающей дороге на расстоянии от 50 до 60 м от перекрестка (рисунок В.2б), в этом случае знаки 1.1, 1.2, 1.5, 1.9, 1.10, 1.23, 1.25 устанавливают обязательно.
5.2.4 Знаки 1.1, 1.2, 1.9, 1.10, 1.21, 1.23, 1.25 устанавливают повторно вне населенных пунктов, а знаки 1.23, 1.25 — и в населенных пунктах. Повторный знак вне населенных пунктов устанавливают на расстоянии от 50 до 100 м до начала опасного участка, а в населенных пунктах — по 5.2.25 и 5.2.27.
5.2.5 Знаки 1.1 «Железнодорожный переезд со шлагбаумом» и 1.2 «Железнодорожный переезд без шлагбаума» устанавливают перед всеми железнодорожными переездами, соответственно оборудованными или не оборудованными шлагбаумами. Знаки дублируют на дорогах с двумя или более полосами для движения в одном направлении, а на дорогах с одной полосой, если расстояние видимости переезда вне населенных пунктов менее 300 м, а в населенных пунктах — менее 100 м.
При расстоянии между железнодорожными переездами 50 м и менее знаки устанавливают перед первым переездом, а при расстоянии более 50 м — перед каждым переездом.
5.2.6 Знаки 1.3.1 «Однопутная железная дорога» и 1.3.2 «Многопутная железная дорога» устанавливают перед всеми железнодорожными переездами соответственно через железную дорогу с одним или двумя и более путями. При наличии на переезде светофорной сигнализации знаки устанавливают на одной опоре со светофорами, а при ее отсутствии — на расстоянии от 6 до 10 м до ближнего рельса (рисунок В.18).
(Поправка. ИУС N 10-2020).
5.2.7 Знаки 1.4.1-1.4.6 «Приближение к железнодорожному переезду» устанавливают перед каждым железнодорожным переездом.
Знаки 1.4.1-1.4.3 устанавливают с правой стороны дороги, а знаки 1.4.4-1.4.6 — с левой. Знаки 1.4.1 и 1.4.4 устанавливают с первым (основным и дублирующим) по ходу движения знаком 1.1 или 1.2, знаки 1.4.3 и 1.4.6 — с повторным знаком 1.1 или 1.2, а знаки 1.4.2 и 1.4.5 — самостоятельно, на равном расстоянии между первым и повторным знаком 1.1 или 1.2 (рисунок В.3).
Знаки 1.4.1, 1.4.3, 1.4.4 и 1.4.6 размещают под знаком 1.1 или 1.2, знаки 1.4.2 и 1.4.5 — на высоте, равной высоте установки знаков 1.4.1, 1.4.3, 1.4.4 и 1.4.6.
5.2.8 Знак 1.5 «Пересечение с трамвайной линией» устанавливают перед пересечением дороги с трамвайными путями вне перекрестка, а также перед перекрестками (площадями), через которые проходят трамвайные пути, при расстоянии видимости путей менее 50 м.
5.2.9 Знак 1.6 «Пересечение равнозначных дорог» устанавливают перед перекрестками равнозначных дорог, на подъездах к которым расстояние видимости перекрестка вне населенных пунктов менее 150 м, а в населенных пунктах — менее 50 м.
Знак устанавливают перед перекрестком, на котором отменяют очередность проезда, установленную знаками приоритета.
5.2.10 Знак 1.7 «Пересечение с круговым движением» устанавливают перед перекрестками, обозначенными знаками 4.3, вне населенных пунктов — перед каждым перекрестком, в населенных пунктах — перед перекрестками, расстояние видимости которых менее 50 м, а также перед перекрестками, на которых отсутствует искусственное освещение.
5.2.11 Знак 1.8 «Светофорное регулирование» устанавливают вне населенных пунктов перед каждым перекрестком, пешеходным переходом или участком дороги, кроме железнодорожных переездов, движение на которых регулируется светофорами, в населенных пунктах — при расстоянии видимости светофора менее 100 м, а также перед первым после въезда в населенный пункт перекрестком или пешеходным переходом со светофорным регулированием.
5.2.12 Знак 1.9 «Разводной мост» устанавливают перед всеми разводными мостами и паромными переправами.
5.2.13 Знак 1.10 «Выезд на набережную» устанавливают перед участками дорог, выходящими на набережную или берег какого-либо водоема. Знак устанавливают независимо от наличия дорожного ограждения.
5.2.14 Знаки 1.11.1 и 1.11.2 «Опасный поворот» устанавливают перед кривыми в плане, на которых значение коэффициента безопасности* 0,6 и менее, а также перед кривыми в плане, на которых расстояние видимости встречного автомобиля при скорости, характерной для предшествующего кривой участка дороги, менее минимального расстояния видимости, обеспечивающего безопасность движения (таблица 4).
_______________
* Отношение скоростей проезда опасного и предшествующего участков.
Таблица 4 — Минимальное расстояние видимости, обеспечивающее безопасность движения при данной скорости
Скорость движения, км/ч | 30 | 40 | 50 | 60 | 70 | 80 | 90 | 100 | 110 | 120 | 130 |
Минимальное расстояние видимости, м: | |||||||||||
— встречного автомобиля | 90 | 110 | 130 | 170 | 200 | 250 | 300 | 350 | 400 | 450 | Не нормируется |
— для остановки перед препятствием | 45 | 55 | 75 | 85 | 125 | 150 | 175 | 200 | 225 | 250 | 300 |
Примечания 1 Для строящихся дорог принимают скорость, соответствующую 70% расчетной скорости, а для эксплуатируемых дорог — скорость, которую на данном участке не превышают 85% транспортных средств. 2 Расстоянием видимости встречного автомобиля следует считать расстояние, на котором с высоты 1,2 м (уровень глаз водителя легкового автомобиля) можно увидеть предмет, находящийся на высоте 1,2 м над уровнем проезжей части. 3 Расстоянием видимости для остановки следует считать расстояние, которое с высоты 1,2 м (уровень глаз водителя легкового автомобиля) обеспечивает видимость любых предметов высотой не менее 0,2 м, находящихся на середине полосы движения. | |||||||||||
5.2.15 Знаки 1.12.1 и 1.12.2 «Опасные повороты» устанавливают перед двумя и более следующими друг за другом кривыми в плане, если расстояние между ними менее 300 м и если перед первой из них согласно 5.2.14 должен быть установлен соответственно знак 1.11.1 или 1.11.2.
Расстояние между соседними кривыми в плане определяют между концом и началом следующих друг за другом кривых, включая переходные кривые.
Знаки 1.12.1 и 1.12.2 с табличкой 8.2.1 устанавливают при трех и более следующих друг за другом кривых в плане.
5.2.16 Знаки 1.13 «Крутой спуск» и 1.14 «Крутой подъем» устанавливают:
— если длина участка дороги на спуске или подъеме более указанной в таблице 5 при соответствующей величине уклона;
— если на вертикальных выпуклых кривых расстояние видимости встречного автомобиля менее указанных в таблице 4 при скорости, характерной для предшествующего кривой участка дороги.
Таблица 5 — Минимальная длина участка дороги на уклоне при установке знаков 1.13 и 1.14 в зависимости от величины уклона
Уклон, ‰ (%) | Длина участка дороги на уклоне, м |
40 (4) | 600 |
50 (5) | 450 |
60 (6) | 350 |
70 (7) | 300 |
80 (8) и более | 270 |
В случае, если спуски и подъемы следуют друг за другом, знаки (без таблички 8.1.1) допускается устанавливать непосредственно перед началом спуска или подъема.
5.2.17 Знак 1.15 «Скользкая дорога» устанавливают перед участками дорог, на которых коэффициент сцепления шины с покрытием, измеренный в соответствии с ГОСТ 33078, менее 0,3, а также перед участками дорог с уплотненным снежным покровом.
5.2.18 Знак 1.16 «Неровная дорога» устанавливают перед участками дорог, имеющими повреждения покрытия (выбоины, неплавное сопряжение подходов с мостовыми сооружениями, волнистость и т.п.), затрудняющие движение транспортных средств с разрешенной скоростью по [1], а также в случаях превышения показателя ровности покрытия по ГОСТ 33220 и ГОСТ Р 50597.
5.2.19 Знак 1.17 «Искусственная неровность» устанавливают перед искусственной неровностью по ГОСТ Р 52605.
В случаях, если расстояние между последовательно расположенными неровностями составляет не более 100 м, знак устанавливают перед первой искусственной неровностью с табличкой 8.2.1.
5.2.20 Знак 1.18 «Выброс гравия» устанавливают перед участками дорог, на которых возможен выброс гравия, щебня и т.п. из-под колес транспортных средств.
5.2.21 Знак 1.19 «Опасная обочина» устанавливают перед участками дорог, на которых состояние обочин не соответствует ГОСТ 33220 или ГОСТ Р 50597.
5.2.22 Знаки 1.20.1-1.20.3 «Сужение дороги» устанавливают вне населенных пунктов перед участками дорог, на которых ширина проезжей части уменьшается более чем на 0,5 м, а в населенных пунктах — на одну полосу или более. Вне населенных пунктов знак устанавливают также перед мостовыми сооружениями и тоннелями, если ширина проезжей части в пределах искусственного сооружения равна или менее, чем на подходах к нему, а в населенных пунктах — менее, чем на подходах к нему.
Знак 1.20.2 не устанавливают в местах окончания полосы разгона и дополнительной полосы на подъеме.
Знаки 1.20.1-1.20.3 дублируют в соответствии с 5.1.6.
5.2.23 Знак 1.21 «Двустороннее движение» устанавливают перед участками дороги (проезжей части) с двусторонним движением, если им предшествует участок с односторонним движением. Знак устанавливают независимо от применения знака 5.6. Допускается не устанавливать знак перед участками дорог с односторонним движением протяженностью менее 100 м.
Знак не устанавливают, если дорога, обозначенная знаком 5.5, заканчивается на Т-образном перекрестке, перекрестке с круговым движением или на площади.
5.2.24 Знак 1.22 «Пешеходный переход» устанавливают вне населенных пунктов перед всеми нерегулируемыми наземными пешеходными переходами, а в населенных пунктах — перед первым нерегулируемым наземным пешеходным переходом и перед переходами, расстояние видимости которых менее 150 м.
Знак допускается не устанавливать перед переходами, расположенными на перекрестках при расстоянии видимости их более 150 м.
5.2.25 Знак 1.23 «Дети» устанавливают перед участками дорог, проходящими вдоль территорий детских учреждений* или часто пересекаемыми детьми независимо от наличия пешеходных переходов.
_______________
* Здесь и далее под детскими учреждениями понимают объекты социальной инфраструктуры для детей — здания, строения, сооружения, необходимые для жизнеобеспечения детей, а также организации, деятельность которых осуществляется в целях обеспечения полноценной жизни, охраны здоровья, образования, отдыха и оздоровления, развития детей, удовлетворения их общественных потребностей.
Повторный знак устанавливают с табличкой 8.2.1, на которой указывают протяженность участка дороги, проходящего вдоль территории детского учреждения или часто пересекаемого детьми.
В населенных пунктах повторный знак 1.23 устанавливают на расстоянии от 20 до 30 м от опасного участка.
5.2.26 Знак 1.24 «Пересечение с велосипедной дорожкой или велопешеходной дорожкой» устанавливают перед расположенными вне перекрестков пересечениями с велосипедными или велопешеходными дорожками, обозначенными знаками 4.4.1, 4.5.2, 4.5.4, 4.5.5, а также в местах окончания велосипедной дорожки, где велосипедисты выезжают на проезжую часть.
5.2.27 Знак 1.25 «Дорожные работы» устанавливают перед участком дороги, в пределах которого проводят любые виды работ.
Если работы осуществляются на тротуаре или велосипедной дорожке, то знак устанавливают в случае, когда пешеходы или велосипедисты вынуждены использовать для движения проезжую часть.
Знак 1.25 дублируют в соответствии с 5.1.6.
Повторный знак 1.25 в населенных пунктах, а также вне населенных пунктов, в стесненных условиях, устанавливают непосредственно у начала участка проведения работ, при этом за начало участка следует принимать первое по ходу движения направляющее или ограждающее устройство или временную дорожную разметку, отклоняющую транспортный поток перед опасным участком.
При проведении краткосрочных работ по ГОСТ 32757 на дорогах с ограничением скоростного режима 40 км/ч и менее допускается установка одного знака без таблички 8.1.1 на переносной опоре на расстоянии от 10 до 15 м от места проведения работ, при этом допускается использовать знак уменьшенного размера по ГОСТ Р 52290.
Если перед участком дороги, на котором проводят работы, применяют и другие временные знаки, знак 1.25 устанавливают первым по ходу движения, кроме случаев применения вне населенных пунктов знака 6.19.1.
5.2.28 Знак 1.26 «Перегон скота» устанавливают перед участками дорог, проходящими вдоль скотных дворов, ферм и т.п., а также перед местами постоянного перегона скота через дорогу.
5.2.29 Знак 1.27 «Дикие животные» устанавливают перед участками дорог, проходящими по территории заповедников, охотничьих хозяйств, лесных массивов, и другими участками дорог, если на них возможно появление диких животных, и применяют с табличкой 8.2.1.
5.2.30 Знак 1.28 «Падение камней» устанавливают перед участками дорог, проезжая часть которых не защищена от возможных обвалов, оползней, снежных лавин и камнепадов, и применяют с табличкой 8.2.1.
5.2.31 Знак 1.29 «Боковой ветер» устанавливают перед участками дорог, проходящими по горным перевалам, высоким насыпям, мостам, путепроводам, вдоль ущелий и рек и т.п., на которых возможен сильный боковой ветер.
5.2.32 Знак 1.30 «Низколетящие самолеты» устанавливают перед проходящими вблизи аэродромов участками дорог, над которыми самолеты или вертолеты пролетают на небольшой высоте.
5.2.33 Знак 1.31 «Тоннель» устанавливают перед тоннелями, в которых отсутствует искусственное освещение, а также перед тоннелями, въездные порталы которых из-за рельефа местности видны с расстояния менее 150 м с высоты 1,2 м* над уровнем проезжей части.
_______________
* Уровень глаз водителя легкового автомобиля.
Знак 1.31 устанавливают перед тоннелями, при въезде в которые не видны их выездные порталы, при этом непосредственно перед тоннелями устанавливают повторный знак с табличкой 8.2.1.
5.2.34 Знак 1.32 «Затор» применяют в период возникновения затора по ГОСТ Р 55691 на участке дороги или размещают на ЗПИ и устанавливают перед перекрестком, откуда возможен объезд участка дороги, на котором образовался затор.
5.2.35 Знак 1.33 «Прочие опасности» устанавливают перед опасными участками дорог, вид опасности на которых не предусмотрен предупреждающими знаками по ГОСТ Р 52290.
5.2.36 Знаки 1.34.1 и 1.34.2 «Направление поворота» устанавливают на участках дорог с кривыми в плане радиусами 600 м и менее. Знаки устанавливают с внешней стороны кривой на продолжении оси полосы (полос), по которой осуществляется движение к повороту.
На перекрестке с круговым движением знак 1.34.1 устанавливают на центральном островке, напротив соответствующего въезда.
Знаки с двумя стрелами допускается устанавливать в стесненных условиях.
Знаки с одной стрелой устанавливают на протяжении одной кривой, число их должно быть не менее четырех, а расстояние между ними — не более 20 м.
Знаки устанавливают на высоте от 1,5 до 2,0 м.
5.2.37 Знак 1.34.3 «Направление поворота» устанавливают на Т-образных перекрестках и разветвлениях дорог, если имеется опасность их проезда в прямом направлении.
На Т-образных перекрестках знак устанавливают напротив дороги, не имеющей продолжения, на разветвлениях дорог — непосредственно за местом, где разветвляются проезжие части дорог.
Знак с двумя стрелами допускается устанавливать в стесненных условиях.
Знак устанавливают на высоте от 1,5 до 2,0 м.
5.2.38 Знаки 1.34.1-1.34.3 допускается применять в местах производства работ для дополнительного указания направления объезда огороженного участка. Знаки в этом случае допускается размещать на инвентарных ограждениях по ГОСТ 23407.
Знаки типоразмера II высотой 460 мм допускается устанавливать при наличии искусственного освещения.
5.2.39 Знак 1.35 «Участок перекрестка» устанавливают перед перекрестком, на котором нанесена разметка 1.26.
5.3 Знаки приоритета
5.3.1 Знаки приоритета применяют для указания очередности проезда перекрестков, пересечений отдельных проезжих частей, а также узких участков дорог.
5.3.2 Знак 2.1 «Главная дорога» устанавливают в начале участка дороги с преимущественным правом проезда нерегулируемых перекрестков.
В населенных пунктах знак устанавливают перед каждым перекрестком на главной дороге. Перед нерегулируемыми перекрестками, на которых главная дорога проходит в прямом направлении, а пересекающая дорога имеет не более четырех полос, допускается устанавливать знак уменьшенного размера по ГОСТ Р 52290.
Знак 2.1 с табличкой 8.13 устанавливают перед перекрестками, на которых главная дорога изменяет направление, а также перед перекрестками со сложной планировкой. В населенных пунктах знак 2.1 с табличкой 8.13 устанавливают перед перекрестком, а вне населенных пунктов — предварительно на расстоянии от 150 до 300 м до перекрестка и перед перекрестком (рисунок В.4а).
На пересечениях дорог с несколькими проезжими частями знак устанавливают перед пересечениями проезжих частей, на которых возможно неоднозначное определение главенства дорог.
5.3.3 Знак 2.2 «Конец главной дороги» устанавливают в конце участка дороги, где она утрачивает статус главной.
Если дорога, обозначенная знаком 2.1, оканчивается перед пересечением с дорогой, по которой предоставлено преимущественное право проезда данного перекрестка, то знак 2.2 вне населенных пунктов размещают на одной опоре со знаком 2.4, установленным предварительно с табличкой 8.1.1 или 8.1.2, в населенных пунктах — за 25 м от перекрестка либо со знаком 2.4 или 2.5. Вне населенных пунктов знак 2.2 допускается устанавливать повторно со знаком 2.4 или 2.5, а в населенных пунктах — предварительно с табличкой 8.1.1 на расстоянии от 50 до 100 м до основного знака (рисунок В.4б).
5.3.4 Знаки 2.3.1 «Пересечение с второстепенной дорогой«, 2.3.2-2.3.7 «Примыкание второстепенной дороги» устанавливают вне населенных пунктов перед всеми перекрестками на дорогах, обозначенными знаком 2.1. Знаки не устанавливают перед перекрестками со сложной планировкой и перед перекрестками, на которых главная дорога изменяет направление. Знаки 2.3.4-2.3.7 должны быть установлены, если угол между осями главной и второстепенной дорог составляет менее 60°. Знаки 2.3.1-2.3.7 устанавливают на расстоянии от 150 до 300 м до перекрестка.
Допускается знаки 2.3.1-2.3.7 устанавливать на дорогах по СП 34.13330, проходящих через населенные пункты, в этом случае знаки устанавливают на расстоянии от 50 до 100 м до перекрестка.
При необходимости допускается устанавливать знаки 2.3.1-2.3.7 на ином расстоянии, указываемом в этом случае на табличке 8.1.1.
5.3.5 Знаки 2.3.1-2.3.7 совместно со знаками 2.4 или 2.5 допускается применять для обозначения отдельных перекрестков вне населенных пунктов, на которых необходимо установить очередность проезда, отличную от очередности проезда перекрестка равнозначных дорог.
Допускается не устанавливать знаки 2.1, 2.3.1-2.3.7 перед съездами пересечений дорог в разных уровнях, а также перед примыканиями к дороге с твердым покрытием дорог с грунтовым покрытием, перед примыканиями к дороге выездов с прилегающих территорий, если все перечисленные признаки примыкающих дорог могут однозначно распознаваться водителями транспортных средств, следующих по главной дороге в любое время суток.
5.3.6 Знак 2.4 «Уступите дорогу» применяют для указания того, что водитель должен уступить дорогу транспортным средствам, движущимся по пересекаемой дороге, а при наличии таблички 8.13 — транспортным средствам, движущимся по главной дороге.
Знак устанавливают непосредственно перед выездом на дорогу предпочтительно в начале кривой сопряжения, по которой знаками 2.1 или 2.3.1-2.3.7 предоставлено преимущественное право проезда данного перекрестка, а также перед выездами на автомагистраль.
Перед перекрестками со сложной планировкой и перед перекрестками, на которых главная дорога изменяет направление, знак устанавливают с табличкой 8.13.
Знак устанавливают перед выездами с грунтовых дорог на дорогу с твердым покрытием, а также в местах выезда на дорогу с прилегающих территорий, если признаки примыкающих дорог могут неоднозначно распознаваться водителями транспортных средств, выезжающих на главную дорогу в любое время суток. Знак 2.4 в этом случае может быть установлен при отсутствии знаков 2.1 или 2.3.1-2.3.7 на главной дороге по 5.3.5.
Знак 2.4 устанавливают предварительно с табличкой 8.1.1 на дорогах вне населенных пунктов, за исключением грунтовых дорог, на расстоянии от 150 до 300 м до перекрестка, если перед перекрестком установлен знак 2.4, или с табличкой 8.1.2, если перед перекрестком установлен знак 2.5.
При наличии полосы разгона в местах выезда на дорогу с преимущественным правом проезда перекрестков знак устанавливают перед началом этой полосы.
5.3.7 Знак 2.5 «Движение без остановки запрещено» применяют для указания водителю остановиться и уступить дорогу транспортным средствам, движущимся по пересекаемой дороге, а при наличии таблички 8.13 — транспортным средствам, движущимся по главной дороге.
Знак 2.5 устанавливают вместо знака 2.4, если не обеспечено расстояние видимости транспортных средств, движущихся по пересекаемой дороге в пределах треугольников видимости по СП 42.13330.
Знак устанавливают перед нерегулируемыми железнодорожными переездами (без дежурного, не оборудованными светофорами) совместно со знаком 6.16, на расстоянии 10 м до ближнего рельса в случаях, если на удалении 50 м от ближайшего рельса расстояние видимости поезда менее значения, указанного в таблице 6.
Временный знак 2.5 допускается устанавливать перед переездами при проведении работ на переезде.
При установке знака 2.5 перед железнодорожным переездом предварительный знак 2.4 с табличкой 8.1.2 не устанавливают.
Таблица 6 — Минимальное расстояние видимости поезда из транспортного средства, обеспечивающее безопасность движения
Скорость движения поезда, км/ч | 121-140 | 81-120 | 41-80 | 26-40 | 25 и менее |
Расстояние видимости, м, не менее | 500 | 400 | 250 | 150 | 100 |
Примечания 1 За скорость движения принимают максимальную скорость поезда, установленную на подходах к переезду. 2 При проектировании вновь строящихся и реконструируемых дорог на переездах водителю автомобиля, находящемуся на расстоянии для остановки перед переездом не менее указанного в таблице 4, должна быть обеспечена видимость приближающегося к переезду поезда, который находится на расстоянии не менее 400 м от переезда. | |||||
5.3.8 На регулируемых перекрестках знаки 2.1, 2.2, 2.4, 2.5 следует размещать предпочтительно на опоре основного светофора.
Знаки 2.4 и 2.5 следует дублировать в соответствии с 5.1.6.
5.3.9 Знаки 2.6 «Преимущество встречного движения» и 2.7 «Преимущество перед встречным движением» применяют для организации движения в местах, где невозможен или опасен встречный разъезд транспортных средств (узкие участки дорог, мостовые сооружения, тоннели и т.п.), при интенсивности движения, обеспечивающей саморегулирование встречного разъезда, и видимости всего участка и противоположного въезда на него с каждого конца узкого участка дороги.
Знаки устанавливают перед мостовыми сооружениями, по которым осуществляется двустороннее движение при ширине проезжей части менее 6 м.
На участках дорог с продольным уклоном, обозначенных знаками 1.13 и 1.14, преимущество предоставляется транспортным средствам, которые движутся на подъем.
Знаки устанавливают непосредственно перед узким участком дороги с его противоположных концов, при этом знак 2.6 с табличкой 8.1.1 размещают и предварительно на одной опоре с одним из знаков 1.20.1-1.20.3.
5.4 Запрещающие знаки
5.4.1 Запрещающие знаки применяют для введения ограничений движения или их отмены и устанавливают по 5.1.9.
5.4.2 Знак 3.1 «Въезд запрещен«* устанавливают:
_______________
* Здесь и далее действие запрещающих знаков — по [1].
— на участках дорог или проезжих частей с односторонним движением для запрещения движения транспортных средств во встречном направлении, в том числе после всех боковых выездов. Допускается не устанавливать знак у выездов с прилегающих территорий, въезд на которые осуществляется только с данных участков с односторонним движением;
— на дорогах с несколькими проезжими частями, отделенными друг от друга бульваром или разделительной полосой, знак устанавливают для каждой проезжей части с односторонним движением;
— на дорогах, обозначенных знаком 5.11.1 и 5.11.2, для предотвращения въезда транспортных средств навстречу общему потоку, а с табличкой 8.14 — на полосу, выделенную для маршрутных транспортных средств (для предотвращения выезда транспортных средств, движение которых разрешено по [1]) или велосипедистов;
— для организации раздельных въезда и выезда на площадках для стоянки транспортных средств, площадках отдыха, автозаправочных станциях и т.п.;
— для запрещения въезда на отдельную полосу движения или отдельный участок дороги, в том числе трамвайные пути.
Знак, запрещающий выезд на отдельную полосу или трамвайные пути, устанавливают с табличкой 8.14.
Знак на однополосных съездах пересечений в разных уровнях, по которым осуществляется одностороннее движение, допускается располагать слева.
Знак допускается применять с табличкой 8.23 при условиях по 5.9.30.
Если основной знак устанавливают на участке дороги между перекрестками, в начале участка размещают предварительный знак 3.1 с табличкой 8.1.1.
С другими табличками знак 3.1 применять не допускается.
5.4.3 Знак 3.2 «Движение запрещено«* применяют для запрещения движения всех транспортных средств на отдельных участках дорог.
5.4.4 Знак 3.3 «Движение механических транспортных средств запрещено«* применяют для запрещения движения всех механических транспортных средств.
5.4.5 Знак 3.4 «Движение грузовых автомобилей запрещено«* применяют для запрещения движения грузовых автомобилей и составов транспортных средств с разрешенной максимальной массой более 3,5 т (если на знаке не указана масса) или с разрешенной максимальной массой более указанной на знаке, а также тракторов и самоходных машин.
Знак 3.4 не запрещает движение грузовых автомобилей, предназначенных для перевозки людей, транспортных средств организаций федеральной почтовой связи, имеющих на боковой поверхности белую диагональную полосу на синем фоне, а также грузовых автомобилей без прицепа с разрешенной максимальной массой не более 26 тонн, которые обслуживают предприятия, находящиеся в обозначенной зоне. Такие транспортные средства должны въезжать в обозначенную зону и выезжать из нее на ближайшем к месту назначения перекрестке.
5.4.6 Знак 3.5 «Движение мотоциклов запрещено«* применяют для запрещения движения мотоциклов, знак 3.6 «Движение тракторов запрещено«* — для запрещения движения тракторов и самоходных машин, знак 3.7 «Движение с прицепом запрещено«* — для запрещения движения грузовых автомобилей и тракторов с прицепами или полуприцепами любого типа, а также всякой буксировки механических транспортных средств, знак 3.8 «Движение гужевых повозок запрещено«* — для запрещения движения гужевых повозок (саней), животных под седлом или вьюком, а также прогона скота, знак 3.9 «Движение на велосипедах и мопедах запрещено«* — для запрещения движения на велосипедах и мопедах, знак 3.34 «Движение автобусов запрещено«* — для запрещения движения автобусов.
5.4.7 Знак 3.10 «Движение пешеходов запрещено» устанавливают в местах, где движение пешеходов недопустимо по условиям их безопасности (искусственные сооружения, не имеющие тротуаров, ремонтируемые участки дорог и т.п.). Знак устанавливают на той стороне дороги, на которой вводят запрещение.
Знак применяют для запрещения перехода на регулируемых перекрестках, где какие-либо направления движения пешеходов запрещены. Знак устанавливают на краю тротуара лицевой стороной к пешеходам, движение которых следует запретить.
5.4.8 Знак 3.11 «Ограничение массы» применяют для запрещения движения транспортных средств, в том числе составов транспортных средств, общая фактическая масса которых более указанной на знаке.
Значение допустимой массы, указываемой на знаке, установленном перед мостовым сооружением (мосты, путепроводы и т.п.), определяют с учетом грузоподъемности сооружения по результатам специальных обследований и испытаний.
Значение допустимой массы на знаке, установленном перед ледовой переправой, определяют с учетом несущей способности льда по результатам обследований и испытаний.
5.4.9 Знак 3.12 «Ограничение массы, приходящейся на ось транспортного средства» применяют для запрещения движения транспортных средств, у которых фактическая масса, приходящаяся на любую ось, более указанной на знаке.
Знак 3.12 с табличкой 8.20.1 или 8.20.2 применяют для запрещения движения транспортных средств, у которых фактическая масса, приходящаяся на любую из осей тележки, более указанной на знаке.
Значение допустимой массы, указываемой на знаке, определяют по фактической несущей способности дорожной одежды и элементов мостового сооружения в данный период времени по результатам обследований.
5.4.10 Знак 3.13 «Ограничение высоты» применяют для запрещения движения транспортных средств, габаритная высота которых (с грузом или без груза) более указанной на знаке.
Знак устанавливают в случаях, если расстояние от поверхности дорожного покрытия до низа пролетного строения искусственного сооружения, инженерных коммуникаций и т.п. менее 5 м.
Вне населенных пунктов высота, указываемая на знаке, должна быть менее фактической на 1,0 м для дорог категорий I-III, а для дорог категорий IV и V — не менее 0,5 м.
В населенных пунктах высота, указываемая на знаке, должна быть менее фактической на высоту от 0,2 до 0,4 м для инженерных коммуникаций, от 0,3 до 0,4 м — для путепроводов, по которым проходят автомобильная или железная дороги.
Разницу между фактической и указываемой высотой допускается увеличивать в зависимости от ровности дорожного покрытия.
Повторный знак 3.13 допускается устанавливать на пролете искусственного сооружения, а при наличии перед ним габаритных ворот — на воротах.
5.4.11 Знак 3.14 «Ограничение ширины» применяют для запрещения движения транспортных средств, габаритная ширина которых (с грузом или без груза) более указанной на знаке.
Знак устанавливают перед проездом, если его ширина в тоннеле, между опорами мостового сооружения и т.п. менее 3,5 м.
Ширина, указываемая на знаке, должна быть менее фактической на 0,2 м.
Повторный знак 3.14 допускается устанавливать на пролете или опоре иск
RFC 8152 — Подписание и шифрование объектов CBOR (COSE)
[Документы] [txt | pdf] [draft-ietf-cose …] [Tracker] [Diff1] [Diff2] [Errata]ПРЕДЛАГАЕМЫЙ СТАНДАРТ
Есть исправления
Инженерная группа Интернета (IETF) Дж. Шаад
Запрос комментариев: 8152 August Cellars
Категория: Standards Track июль 2017
ISSN: 2070-1721 гг.
Подпись и шифрование объектов CBOR (COSE)
Аннотация
Краткое представление двоичных объектов (CBOR) - это формат данных, разработанный
для небольшого размера кода и небольшого размера сообщения.Есть потребность в
возможность определять базовые службы безопасности для этого формата данных.
Этот документ определяет подписывание и шифрование объекта CBOR (COSE)
протокол. Эта спецификация описывает, как создавать и обрабатывать
подписи, коды аутентификации сообщений и шифрование с использованием CBOR
для сериализации. Эта спецификация дополнительно описывает, как
представляют криптографические ключи с помощью CBOR.
Статус этой памятки
Это документ Internet Standards Track.
Этот документ является продуктом Инженерной группы Интернета.
(IETF).Он представляет собой консенсус сообщества IETF. Оно имеет
получил публичное рецензирование и был одобрен к публикации
Инженерная группа управления Интернетом (IESG). Дополнительная информация о
Интернет-стандарты доступны в разделе 2 RFC 7841.
Информация о текущем статусе этого документа, исправлениях,
а как оставить отзыв о нем можно узнать на
http://www.rfc-editor.org/info/rfc8152.
Уведомление об авторских правах
Авторские права (c) 2017 IETF Trust и лица, указанные как
авторы документа.Все права защищены.
Этот документ регулируется BCP 78 и Правовой нормой IETF Trust.
Положения, касающиеся документов IETF
(http://trustee.ietf.org/license-info) действует на дату
публикация этого документа. Просмотрите эти документы
внимательно, поскольку они уважительно описывают ваши права и ограничения
к этому документу. Компоненты кода, извлеченные из этого документа, должны
включить упрощенный текст лицензии BSD, как описано в разделе 4.e
Правовые положения Trust и предоставляются без гарантии, как
описана в упрощенной лицензии BSD.Schaad Standards Track [Страница 1]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
Содержание
1. Введение ............................................... ..... 4
1.1. Изменения в дизайне по сравнению с JOSE ................................... 5
1.2. Терминология требований ................................... 6
1.3. CBOR Грамматика ............................................... 6
1.4. Терминология, связанная с CBOR................................... 7
1.5. Терминология документа ....................................... 8
2. Базовая структура COSE ............................................ 8
3. Параметры заголовка .............................................. 10
3.1. Общие параметры заголовков COSE ............................ 12
4. Подписание объектов .............................................. ..16
4.1. Подписание с одним или несколькими подписывающими сторонами .......................... 16
4.2. Подписание с одним подписывающим лицом................................... 18
4.3. Данные, предоставленные извне .................................. 19
4.4. Процесс подписания и проверки .......................... 20
4.5. Вычисление подписей счетчиков .............................. 22
5. Объекты шифрования ............................................. 22
5.1. Огибающая структура COSE .................................. 23
5.1.1. Методы распространения ключей содержимого ................... 24
5.2. Единый получатель зашифрован................................ 25
5.3. Как зашифровать и расшифровать алгоритмы AEAD ............ 26
5.4. Как зашифровать и расшифровать алгоритмы AE .............. 28
6. Объекты MAC .............................................. ...... 29
6.1. MACed-сообщение с получателями ............................. 30
6.2. Сообщения MAC с неявным ключом ......................... 31
6.3. Как вычислить и проверить MAC ........................... 32
7. Ключевые объекты .................................................... 33
7.1. Общие параметры ключа COSE ................................ 34
8. Алгоритмы подписи ........................................... 37
8.1. ECDSA ................................................. .... 38
8.1.1. Соображения безопасности ............................ 40
8.2. Алгоритмы цифровой подписи по кривой Эдвардса (EdDSA) ....... 40
8.2.1. Соображения безопасности ............................ 41
9. Алгоритмы кода аутентификации сообщения (MAC)................... 42
9.1. Коды аутентификации сообщений на основе хэша (HMAC) ........... 42
9.1.1. Соображения безопасности ............................ 44
9.2. Код аутентификации сообщения AES (AES-CBC-MAC) ............. 44
9.2.1. Соображения безопасности ............................ 45
10. Алгоритмы шифрования контента ................................. 45
10.1. AES GCM ................................................ ..46
10.1.1. Соображения безопасности........................... 47
10.2. AES CCM ................................................ ..47
10.2.1. Соображения безопасности ........................... 50
10.3. ChaCha20 и Poly1305 .................................... 50
10.3.1. Соображения безопасности ........................... 51
11. Ключевые деривационные функции (KDF) ............................... 51
Schaad Standards Track [Страница 2]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
11.1. Получение ключа извлечения и расширения на основе HMAC
Функция (HKDF) .......................................... 52
11.2. Структура контекстной информации ........................... 54
12. Методы распространения ключей контента .............................. 60
12.1. Прямое шифрование ........................................ 60
12.1.1. Прямой ключ ........................................ 61
12.1.2. Прямой ключ с KDF ............................... 61
12.2. Обертка для ключей................................................ 63
12.2.1. Перенос ключей AES ...................................... 64
12.3. Ключевой транспорт ........................................... 65
12.4. Прямое ключевое соглашение .................................... 65
12.4.1. ECDH .............................................. 66
12.4.2. Соображения безопасности ........................... 69
12.5. Ключевое соглашение с Key Wrap .............................. 69
12.5.1. ECDH .............................................. 70
13. Параметры ключевых объектов ......................................... 72
13.1. Клавиши эллиптических кривых ..................................... 73
13.1.1. Двухкоординатные кривые .......................... 73
13.2. Пара октетных ключей ........................................... 74
13.3. Симметричные клавиши ........................................... 75
14. Ограничения кодировщика CBOR ..................................... 76
15.Рекомендации по профилированию приложений .......................... 76
16. Вопросы IANA ........................................... 78
16.1. Назначение тега CBOR ...................................... 78
16.2. Реестр параметров заголовка COSE .......................... 78
16.3. Реестр параметров алгоритма заголовка COSE ................ 79
16.4. Реестр алгоритмов COSE ................................. 79
16.5. Реестр общих параметров ключа COSE .....................0,81
16.6. Реестр параметров типа ключа COSE ........................ 81
16.7. Реестр типов ключей COSE .................................. 82
16.8. Реестр эллиптических кривых COSE ............................ 83
16.9. Регистрация типов носителя ................................. 84
16.9.1. Сообщение безопасности COSE ............................. 84
16.9.2. Тип носителя для ключей COSE ............................... 85
16.10. Реестр форматов содержимого CoAP ........................... 87
16.11. Инструкции по экспертизе .............................. 87
17. Соображения безопасности ....................................... 88
18. Ссылки ............................................... ..... 90
18.1. Нормативные ссылки ..................................... 90
18.2. Информационные ссылки ................................... 92
Приложение A. Рекомендации по аутентификации внешних данных
Алгоритмы ............................................ 96
А.1. Идентификация алгоритма .................................. 96
А.2. Встречная подпись без заголовков ......................... 99
Приложение B. Два уровня информации о получателе .................. 100
Приложение C. Примеры ............................................. 102
C.1. Примеры подписанных сообщений .............................. 103
C.1.1. Единая подпись .................................. 103
Стандарты Schaad Track [Страница 3]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
С.1.2. Несколько подписантов .................................. 103
C.1.3. Контрподпись ................................. 104
C.1.4. Подпись с критичностью ........................ 105
С.2. Примеры единой подписывающей стороны ................................... 106
C.2.1. Единая подпись ECDSA ........................... 106
С.3. Примеры сообщений в конвертах ........................... 107
C.3.1. Прямой ECDH ....................................... 107
С.3.2. Вывод ключей Direct Plus ........................ 108
C.3.3. Контрподпись на зашифрованном содержимом ............ 109
C.3.4. Зашифрованный контент с внешними данными .............. 111
С.4. Примеры зашифрованных сообщений ........................... 111
C.4.1. Простое зашифрованное сообщение .......................... 111
C.4.2. Зашифрованное сообщение с частичным IV ............... 112
C.5. Примеры сообщений с MAC-адресами ............................... 112
С.5.1. Общий секретный прямой MAC .......................... 112
C.5.2. ECDH Direct MAC ................................... 113
C.5.3. Упакованный MAC ....................................... 114
C.5.4. Сообщение с MAC-адресом нескольких получателей ..................... 115
С.6. Примеры сообщений MAC0 ................................ 117
C.6.1. Общий секретный прямой MAC-адрес .......................... 117
С.7. Ключи COSE ................................................ 117
С.7.1. Открытые ключи ....................................... 117
C.7.2. Частные ключи ...................................... 119
Благодарности ................................................. .121
Адрес автора ................................................ .121
1. Введение
Особое внимание уделяется небольшим устройствам с ограниченными возможностями, которые
составляют Интернет вещей (IoT). Один из стандартов,
выходят из этого процесса "Краткое представление двоичного объекта"
(CBOR) "[RFC7049].CBOR расширил модель данных JavaScript
Нотация объектов (JSON) [RFC7159], позволяющая использовать двоичные данные, в том числе
другие изменения. CBOR внедряется несколькими работающими IETF
группы, имеющие дело с миром Интернета вещей как с кодированием данных
конструкции. CBOR был разработан специально, чтобы быть маленьким
транспорта сообщений и размера реализации и не иметь схемы
декодер. Существует потребность в предоставлении услуг безопасности сообщений для IoT,
и использование CBOR в качестве формата кодирования сообщений имеет смысл.Рабочая группа JOSE подготовила набор документов [RFC7515]
[RFC7516] [RFC7517] [RFC7518] с использованием JSON, в котором указано, как
шифрование процесса, подписи и код аутентификации сообщения (MAC)
операций и как кодировать ключи с помощью JSON. Этот документ определяет
стандарт CBOR Object Signing and Encryption (COSE), который
то же самое и для формата кодирования CBOR. Пока есть сильная
Schaad Standards Track [Страница 4]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
попытаться сохранить аромат оригинальной подписи объекта JSON и
Документы с шифрованием (JOSE) следует учитывать по двум причинам.
Счет:
o CBOR имеет возможности, которых нет в JSON и которые
подходит для использования.Одним из примеров этого является тот факт, что CBOR имеет
метод кодирования двоичного файла напрямую без его предварительного преобразования
в строку в кодировке base64.
o COSE не является прямой копией спецификации JOSE. в
процесс создания COSE, решения, которые были приняты для JOSE, были
пересмотрел. Во многих случаях разные результаты принимались как
критерии не всегда были одинаковыми.
1.1. Изменения в дизайне от JOSE
o Определите единую верхнюю структуру сообщения, чтобы зашифрованные, подписанные,
и сообщения с MAC-адресами могут быть легко идентифицированы и по-прежнему имеют
последовательный взгляд.o Подписанные сообщения различают защищенные и незащищенные
параметры, относящиеся к содержанию, от тех, которые относятся к
подпись.
o Сообщения с MAC-адресами отделяются от подписанных сообщений.
o MAC-сообщения могут использовать один и тот же набор получателей.
алгоритмы в виде обернутых сообщений для получения MAC
ключ аутентификации.
o Используйте двоичную кодировку для двоичных данных, а не base64url
кодировки.
o Объедините тег аутентификации для алгоритмов шифрования с
зашифрованный текст.o Набор криптографических алгоритмов был расширен в некоторых
направлениях и обрезаны в других.
Schaad Standards Track [Страница 5]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
1.2. Терминология требований
Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «НЕ ДОЛЖНЫ»,
«ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и
«НЕОБЯЗАТЕЛЬНО» в этом документе следует толковать, как описано в BCP.
14 [RFC2119] [RFC8174] когда и только когда они появляются во всех
столицы, как показано здесь.Когда слова написаны в нижнем регистре, эта интерпретация не
применять.
1.3. CBOR Грамматика
В настоящее время нет стандартной грамматики CBOR, доступной для использования
технические характеристики. Поэтому структуры CBOR описаны в
проза.
Документ был разработан, сначала работая над грамматикой, а затем
развитие прозы, чтобы пойти с ней. Артефактом этого является то, что
проза была написана с использованием строк примитивного типа, определенных CBOR
Язык определения данных (CDDL) [CDDL].В этой спецификации
Используются следующие примитивные типы:
any - неспецифическое значение, которое позволяет всем значениям CBOR быть
размещен здесь.
bool - логическое значение (true: основной тип 7, значение 21; false:
основной тип 7, значение 20).
bstr - байтовая строка (старший тип 2).
int - беззнаковое целое или отрицательное целое число.
nil - нулевое значение (основной тип 7, значение 22).
nint - отрицательное целое число (основной тип 1).
tstr - текстовая строка UTF-8 (основной тип 3).uint - целое число без знака (основной тип 0).
Два синтаксиса CDDL представлены в этом документе как сокращенные. Эти
находятся:
FOO / BAR - указывает, что здесь может отображаться либо FOO, либо BAR.
[+ FOO] - указывает, что тип FOO встречается один или несколько раз
в массиве.
Стандарты Schaad Track [Страница 6]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
Помимо описания прозы, есть версия грамматики CBOR.
представлены в CDDL.Поскольку CDDL не был опубликован в RFC, это
грамматика может не работать с окончательной версией CDDL. CDDL
грамматика информационная; Прозаическое описание является нормативным.
Собранный CDDL можно извлечь из XML-версии этого
документ через следующее выражение XPath ниже. (В зависимости от
Один из оценщиков XPath, возможно, придется разобраться с & gt;
как целое.)
// произведение искусства [@ type = 'CDDL'] / text ()
CDDL ожидает, что начальный нетерминальный символ будет первым символом
в файле.По этой причине первый фрагмент CDDL является
представлен здесь.
start = COSE_Messages / COSE_Key / COSE_KeySet / Internal_Types
; Это определено, чтобы сделать инструмент тише:
Internal_Types = Sig_structure / Enc_structure / MAC_structure /
COSE_KDF_Context
Нетерминальные Internal_Types определены для работы с
инструменты автоматической проверки, использованные при написании этого документа.
Он ссылается на те нетерминалы, которые используются для обеспечения безопасности.
вычислений, но не отправляются на транспорт.1.4. Терминология, связанная с CBOR
В JSON карты называются объектами и имеют только один вид ключа карты: a
строка. В COSE мы используем строки, отрицательные целые числа и беззнаковые
целые числа как ключи карты. Целые числа используются для компактности
кодирование и простое сравнение. Включение строк позволяет
также будет использоваться дополнительный диапазон коротких кодированных значений. поскольку
слово «ключ» в основном используется в другом значении, как
криптографический ключ, мы используем термин «метка» для этого использования в качестве карты
ключ.Наличие метки на карте COSE, которая не является строкой или
целое число - ошибка. Приложения могут либо не обрабатываться, либо
обрабатывать сообщения с неверными ярлыками; однако они НЕ ДОЛЖНЫ создавать
сообщения с неправильными ярлыками.
Фрагмент грамматики CDDL определяет нетерминальную 'метку', как в
предыдущий абзац и «значения», который позволяет использовать любое значение.
метка = int / tstr
значения = любые
Стандарты Schaad [Страница 7]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
1.5. Терминология документа
В этом документе мы используем следующую терминологию:
Байт - это синоним октета.
Протокол ограниченного приложения (CoAP) - это специализированная веб-передача.
протокол для использования в системах с ограничениями. Он определен в [RFC7252].
Алгоритмы аутентифицированного шифрования (AE) [RFC5116]:
алгоритмы шифрования, обеспечивающие проверку подлинности
алгоритм содержимого с сервисом шифрования.
Аутентифицированное шифрование с аутентифицированными данными (AEAD) [RFC5116]
алгоритмы предоставляют ту же службу аутентификации контента, что и AE
алгоритмов, но они дополнительно обеспечивают аутентификацию не-
зашифрованные данные.2. Базовая структура COSE
Структура объекта COSE спроектирована таким образом, чтобы можно было
количество общего кода при разборе и обработке разных типов
сообщений безопасности. Все структуры сообщений построены на
Тип массива CBOR. Первые три элемента массива всегда
содержат ту же информацию:
1. Набор параметров защищенного заголовка, заключенный в bstr.
2. Набор незащищенных параметров заголовка в виде карты.
3. Содержание сообщения.Содержимое - это либо открытый текст
или зашифрованный текст в зависимости от обстоятельств. Контент может быть отключен,
но место все еще используется. Контент заключен в bstr
если присутствует, а при отсоединении - нулевое значение.
Элементы после этой точки зависят от конкретного типа сообщения.
Сообщения COSE также построены с использованием концепции слоев для разделения
различные типы криптографических концепций. В качестве примера того, как это
работает, рассмотрите сообщение COSE_Encrypt (раздел 5.1). Это сообщение
шрифт разбит на два уровня: уровень содержимого и получатель
слой. На уровне содержимого открытый текст зашифрован и
размещается информация о зашифрованном сообщении. В получателе
слой, ключ шифрования содержимого (CEK) зашифрован, а информация
о том, как он зашифрован для каждого получателя размещается. Один
версия уровня сообщения шифрования COSE_Encrypt0 (раздел 5.2)
предоставляется для случаев, когда CEK используется заранее.
Стандарты Schaad Track [Страница 8]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
Идентификация того, какой тип сообщения было представлено, выполняется
следующие методы:
1.Конкретный тип сообщения известен из контекста. Это может быть
определяется маркером в содержащей структуре или
ограничения, указанные в протоколе приложения.
2. Тип сообщения определяется тегом CBOR. Сообщения с
Тег CBOR известен в этой спецификации как помеченные сообщения,
сообщения без тега CBOR известны как немаркированные сообщения.
Этот документ определяет тег CBOR для каждого сообщения.
конструкции. Эти теги можно найти в таблице 1.3. Когда COSE-объект переносится в медиа-типе «приложение /
cose ', необязательный параметр' cose-type 'может использоваться для идентификации
встроенный объект. Параметр НЕОБЯЗАТЕЛЬНЫЙ, если помеченный
версия конструкции используется. Параметр НЕОБХОДИМ, если
используется немаркированная версия структуры. Значение для использования
с параметром для каждой из структур можно найти в
Таблица 1.
4. Когда объект COSE переносится как полезная нагрузка CoAP, CoAP
Параметр Content-Format может использоваться для идентификации сообщения
содержание.Значения формата содержимого CoAP можно найти в
Таблица 26. Тег CBOR для структуры сообщения не требуется
поскольку каждое сообщение безопасности уникально идентифицируется.
+ ------- + --------------- + --------------- + --------- ------------------ +
| CBOR | уютный тип | Элемент данных | Семантика |
| Тег | | | |
+ ------- + --------------- + --------------- + --------- ------------------ +
| 98 | косо-знак | COSE_Sign | Подписанный объект данных COSE |
| 18 | cose-sign1 | COSE_Sign1 | Данные единого подписывающего лица COSE |
| | | | Объект |
| 96 | cose-encrypt | COSE_Encrypt | COSE зашифрованные данные |
| | | | Объект |
| 16 | cose-encrypt0 | COSE_Encrypt0 | COSE Единый получатель |
| | | | Зашифрованный объект данных |
| 97 | cose-mac | COSE_Mac | Объект данных COSE MACed |
| 17 | cose-mac0 | COSE_Mac0 | COSE Mac без получателей |
| | | | Объект |
+ ------- + --------------- + --------------- + --------- ------------------ +
Таблица 1: Идентификация сообщения COSE
Стандарты Schaad Track [Страница 9]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
Следующий фрагмент CDDL идентифицирует все самые популярные сообщения.
определено в этом документе.Отдельные нетерминалы определены для
помеченные и немаркированные версии сообщений.
COSE_Messages = COSE_Untagged_Message / COSE_Tagged_Message
COSE_Untagged_Message = COSE_Sign / COSE_Sign1 /
COSE_Encrypt / COSE_Encrypt0 /
COSE_Mac / COSE_Mac0
COSE_Tagged_Message = COSE_Sign_Tagged / COSE_Sign1_Tagged /
COSE_Encrypt_Tagged / COSE_Encrypt0_Tagged /
COSE_Mac_Tagged / COSE_Mac0_Tagged
3. Параметры заголовка
Структура COSE была разработана таким образом, чтобы иметь две группы
информация, которая не считается частью самой полезной нагрузки,
но используются для хранения информации о контенте, алгоритмах, ключах,
или оценочные подсказки для обработки слоя.Эти двое
ковши доступны для использования во всех конструкциях, кроме
ключи. Хотя эти ведра присутствуют, они могут не все использоваться в
все экземпляры. Например, в то время как защищенный сегмент определяется как
часть структуры получателя, некоторые алгоритмы, используемые для
структуры получателя не обеспечивают аутентифицированные данные. Если это
В этом случае защищенное ведро остается пустым.
Оба сегмента реализованы как карты CBOR. Ключ карты - это метка
(Секция 1.4). Часть стоимости зависит от определения для
ярлык. Обе карты используют одинаковый набор пар метка / значение. В
целочисленные и строковые значения для меток разделены на несколько
разделы, включая стандартный диапазон, частный диапазон и диапазон
это зависит от выбранного алгоритма. Определенные метки могут
можно найти в реестре IANA «Параметры заголовка COSE»
(Раздел 16.2).
Для каждого слоя предусмотрено два ведра:
protected: содержит параметры текущего уровня, которые необходимо
быть криптографически защищенным.Это ведро ДОЛЖНО быть пустым, если оно
не будет включаться в криптографические вычисления. Этот
bucket кодируется в сообщении как двоичный объект. Это значение
получается путем CBOR-кодирования защищенной карты и ее упаковки в
объект bstr. Отправителям СЛЕДУЕТ кодировать карту нулевой длины как карту нулевой длины.
строка длины, а не как карта нулевой длины (закодированная как h'a0 ').
Двоичное кодирование нулевой длины является предпочтительным, потому что оно одновременно
короче и версия, используемая в структурах сериализации для
криптографические вычисления.После кодирования карты значение равно
Schaad Standards Track [Страница 10]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
завернутый в двоичный объект. Получатели ДОЛЖНЫ принять как ноль-
двоичное значение длины и карта нулевой длины, закодированная в двоичном
значение. Обертка позволяет кодировать защищенную карту.
транспортироваться с большей вероятностью, что это не будет
переделал в пути.(Плохо функционирующие промежуточные звенья могут декодировать и
перекодировать, но это приведет к невозможности проверки, если
перекодированная байтовая строка идентична декодированной байтовой строке.)
Это позволяет избежать проблемы, когда все стороны должны иметь возможность
обычная каноническая кодировка.
незащищенный: содержит параметры текущего слоя, которые
не защищен криптографически.
Только параметры, относящиеся к текущему слою, должны быть помещены в
этот слой. Например, параметр "тип содержимого"
описывает содержание сообщения, передаваемого в сообщении.Таким образом, этот параметр размещается только на уровне содержимого и
не помещается в слои получателя или подписи. В принципе, один
должен иметь возможность обрабатывать любой данный слой без ссылки на какие-либо
другой слой. За исключением структуры COSE_Sign, единственный
данные, которые должны пересекать уровни, - это криптографический ключ.
Корзины присутствуют во всех объектах безопасности, определенных в
этот документ. Поля в указанном порядке - это "защищенная" корзина (как
CBOR 'bstr' type), а затем 'незащищенный' сегмент (как CBOR 'map'
тип).Наличие обоих ковшей обязательно. Параметры
которые попадают в сегменты, берутся из "параметров заголовка COSE" IANA
реестр (раздел 16.2). Некоторые общие параметры определены в
следующий раздел, но в нем определяется ряд параметров
документ.
Метки на каждой из карт ДОЛЖНЫ быть уникальными. При обработке сообщений
если метка появляется несколько раз, сообщение ДОЛЖНО быть отклонено как
уродливый. Приложения ДОЛЖНЫ проверять, что один и тот же ярлык не
встречаются как в защищенных, так и в незащищенных заголовках.Если сообщение
не отклоняется как некорректный, атрибуты ДОЛЖНЫ быть получены из
защищенное ведро, прежде чем они будут получены из незащищенного
ведро.
Schaad Standards Track [Страница 11]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
Следующий фрагмент CDDL представляет два сегмента заголовка. А
группа «Заголовки» определена в CDDL и представляет собой два сегмента в
какие атрибуты размещены.Эта группа используется для предоставления этих двух
поля последовательно во всех местах. Также определяется тип, который
представляет собой карту общих заголовков.
Заголовки = (
защищенный: empty_or_serialized_map,
незащищенный: header_map
)
header_map = {
Generic_Headers,
* label => значения
}
empty_or_serialized_map = bstr .cbor header_map / bstr .size 0
3.1. Общие параметры заголовков COSE
В этом разделе определяется набор общих параметров заголовка. Резюме
эти параметры можно найти в таблице 2.Эта таблица должна быть
проконсультировались, чтобы определить значение метки и тип значения.
В этом разделе определены следующие параметры заголовка:
alg: этот параметр используется для указания алгоритма, используемого для
безопасность обработки. Этот параметр ДОЛЖЕН быть аутентифицирован там, где
возможность сделать это существует. Эта поддержка предоставляется AEAD
алгоритмы или конструкции (COSE_Sign, COSE_Sign0, COSE_Mac и
COSE_Mac0). Эту аутентификацию можно выполнить, поместив
заголовок в сегменте защищенного заголовка или как часть внешнего
предоставленные данные.Значение взято из «Алгоритмов COSE».
реестр (см. Раздел 16.4).
крит: параметр используется, чтобы указать, какой защищенный заголовок
отмечает, что приложение, обрабатывающее сообщение, должно
понять. Параметры, определенные в этом документе, не должны быть
включены, как их следует понимать во всех реализациях.
Если этот параметр присутствует, он ДОЛЖЕН быть помещен в защищенный
ковш жатки. В массиве ДОЛЖНО быть хотя бы одно значение.
Не все ярлыки нужно включать в параметр "крит".В
правила для определения, какие метки заголовков помещать в массив
находятся:
* Целочисленные метки в диапазоне от 0 до 8 СЛЕДУЕТ опускать.
Стандарты Schaad Track [Страница 12]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
* Целочисленные метки в диапазоне от -1 до -128 можно не указывать, так как они
зависят от алгоритма. Если приложение может правильно
обработать алгоритм, можно предположить, что он будет правильно
обрабатывать все общие параметры, связанные с этим
алгоритм.Целочисленные метки в диапазоне от -129 до -65536 ДОЛЖНЫ
будут включены, поскольку это будут менее распространенные параметры, которые могут
не поддерживаться в целом.
* Ярлыки параметров, необходимых для приложения, МОГУТ быть
опущено. В приложениях должно быть указано, может ли этикетка
опускаться.
Значения параметров заголовка, указанные как "крит", могут быть обработаны.
кодом библиотеки безопасности или приложением, использующим
библиотека безопасности; единственное требование - параметр
обработанный.Если список значений "крит" включает значение, для которого
параметр не находится в защищенном ведре, это фатальный
ошибка при обработке сообщения.
тип содержимого: этот параметр используется для указания типа содержимого
данные в полях полезной нагрузки или зашифрованного текста. Целые числа от
таблица реестра IANA «Content-Formats CoAP» [COAP.Formats].
Текстовые значения, следующие синтаксису "<имя-типа> / <имя-подтипа>"
где <имя-типа> и <имя-подтипа> определены в разделе 4.2 из
[RFC6838]. Начальные и конечные пробелы также опускаются.
Значения текстового содержимого вместе с параметрами и подпараметрами могут
быть размещенным с помощью реестра IANA «Типы носителей». Приложения
СЛЕДУЕТ предоставить этот параметр, если структура содержимого
потенциально неоднозначно.
kid: этот параметр определяет один фрагмент данных, который можно использовать как
ввод, чтобы найти необходимый криптографический ключ. Ценность этого
параметр может быть сопоставлен с элементом kid в COSE_Key
структура.Другие методы распределения ключей могут определять
эквивалентное поле для сопоставления. Приложения НЕ ДОЛЖНЫ предполагать, что
«Детские» ценности уникальны. Может быть несколько ключей с
одинаковое значение kid, поэтому все ключи, связанные с этим словом kid
может потребоваться проверка. Внутренняя структура «детских» ценностей такова:
не определен и не может использоваться приложениями. Ключ
значения идентификаторов - это подсказки о том, какой ключ использовать. Это не
критически важная для безопасности область.По этой причине его можно поместить в
ведро незащищенных заголовков.
IV: этот параметр содержит значение вектора инициализации (IV). За
некоторые симметричные алгоритмы шифрования, это можно назвать
nonce. IV может быть помещен в незащищенный заголовок как
изменение IV приведет к тому, что расшифровка даст открытый текст, который
легко распознается как искаженный.
Стандарты Schaad Track [Страница 13]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
Частичный IV: этот параметр содержит часть значения IV.Когда используешь
структура COSE_Encrypt0, часть IV может быть частью
контекст, связанный с ключом. Это поле используется для переноса
значение, которое вызывает изменение IV для каждого сообщения. IV
может быть помещен в незащищенный заголовок, поскольку изменение IV приведет к
заставляют расшифровку давать открытый текст, который легко обнаруживается
как искажено. Вектор инициализации и частичный
Оба параметра вектора инициализации НЕ ДОЛЖНЫ присутствовать в
тот же уровень безопасности.Сообщение IV генерируется следующими шагами:
1. Слева дополните частичную IV нулями до длины IV.
2. Выполните XOR для дополненного фрагмента IV с контекстом IV.
подпись счетчика: этот параметр содержит один или несколько счетчиков
значения подписи. Встречные подписи обеспечивают способ получения
вторая сторона подписывает некоторые данные. Параметр подписи счетчика может
встречаются как незащищенный атрибут в любом из следующих
структуры: COSE_Sign1, COSE_Signature, COSE_Encrypt,
COSE_recipient, COSE_Encrypt0, COSE_Mac и COSE_Mac0.Эти
все структуры имеют одинаковые начальные элементы, так что
может быть вычислен согласованный расчет подписи счетчика.
Подробная информация о вычислении встречных подписей приведена в разделе 4.5.
Стандарты Schaad Track [Страница 14]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
+ ----------- + ------- + ---------------- + ------------ - + ---------------- +
| Имя | Этикетка | Тип значения | Значение | Описание |
| | | | Реестр | |
+ ----------- + ------- + ---------------- + ------------ - + ---------------- +
| alg | 1 | int / tstr | COSE | Криптографический |
| | | | Алгоритмы | алгоритм |
| | | | реестр | использование |
| крит | 2 | [+ ярлык] | Заголовок COSE | Критический |
| | | | Параметры | заголовки быть |
| | | | реестр | понял |
| содержание | 3 | tstr / uint | CoAP | Тип контента |
| тип | | | Content- | полезной нагрузки |
| | | | Форматы или | |
| | | | Типы СМИ | |
| | | | реестры | |
| малыш | 4 | bstr | | Идентификатор ключа |
| IV | 5 | bstr | | Полный |
| | | | | Инициализация |
| | | | | Вектор |
| Частично | 6 | bstr | | Частично |
| IV | | | | Инициализация |
| | | | | Вектор |
| счетчик | 7 | COSE_Signature | | CBOR-кодирование |
| подпись | | / [+ | | подпись |
| | | COSE_Signature | | структура |
| | | ] | | |
+ ----------- + ------- + ---------------- + ------------ - + ---------------- +
Таблица 2: Общие параметры заголовка
Фрагмент CDDL, представляющий набор заголовков, определенных в этом
раздел приведен ниже.Каждый заголовок помечен как необязательный
потому что они не обязательно должны быть на каждой карте; заголовки требуются в
конкретные карты обсуждаются выше.
Generic_Headers = (
? 1 => int / tstr,; идентификатор алгоритма
? 2 => [+ метка],; критичность
? 3 => tstr / int,; Тип содержимого
? 4 => bstr,; ключевой идентификатор
? 5 => bstr,; IV
? 6 => bstr,; Частичный IV
? 7 => COSE_Signature / [+ COSE_Signature]; Встречная подпись
)
Стандарты Schaad [Страница 15]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
4.Подписание объектов
COSE поддерживает две разные структуры подписи. COSE_Sign позволяет
для применения одной или нескольких подписей к одному и тому же контенту.
COSE_Sign1 ограничен одной подписывающей стороной. Структуры не могут
преобразовываться друг в друга; как вычисление подписи
включает параметр, определяющий, какая структура используется,
преобразованная структура не пройдет проверку подписи.
4.1. Подписание с одним или несколькими подписывающими сторонами
Структура COSE_Sign позволяет использовать одну или несколько подписей.
применяется к полезной нагрузке сообщения.Параметры, относящиеся к содержанию и
параметры, относящиеся к подписи, переносятся вместе с
сама подпись. Эти параметры могут быть подтверждены
подпись или просто присутствовать. Пример параметра о
контент - это тип контента. Примеры параметров о
подпись - это алгоритм и ключ, используемые для создания подписи.
и встречные подписи.
RFC 5652 указывает, что:
Если присутствует более одной подписи, успешная проверка
одной подписи, связанной с данным подписывающим лицом, обычно рассматривается
как успешная подпись этой подписывающей стороны.Однако есть некоторые
среды приложений, в которых необходимы другие правила. An
приложение, которое использует правило, отличное от одной действительной подписи для
каждая подписывающая сторона должна указать эти правила. Также, где простое соответствие
идентификатора подписывающей стороны недостаточно, чтобы определить,
подписи были созданы одной и той же подписывающей стороной, приложение
спецификация должна описывать, как определить, какие подписи были
генерируется той же подписывающей стороной. Поддержка разных сообществ
получателей - это основная причина, по которой подписавшие предпочитают включать
более одной подписи.Например, структура COSE_Sign может включать подписи
генерируется с помощью алгоритма цифровой подписи по кривой Эдвардса (EdDSA)
[RFC8032] и с алгоритмом цифровой подписи на эллиптической кривой
(ECDSA) [DSS]. Это позволяет получателям проверить подпись
связаны с тем или иным алгоритмом. Более подробный
информацию о множественных оценках подписи можно найти в
[RFC5752].
Стандарты Schaad Track [Страница 16]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
Структура подписи может быть закодирована как с тегами, так и без тегов.
в зависимости от контекста, в котором он будет использоваться.Помеченный COSE_Sign
структура определяется тегом CBOR 98. Фрагмент CDDL, который
представляет это:
COSE_Sign_Tagged = # 6.98 (COSE_Sign)
Подписанное сообщение COSE состоит из двух частей. CBOR возражает, что
несет тело, и информация о теле называется
COSE_Sign структура. Объект CBOR, содержащий подпись и
информация о подписи называется COSE_Signature
структура. Примеры подписанных сообщений COSE можно найти в
Приложение C.1.
Структура COSE_Sign - это массив CBOR. Поля массива в
порядок:
protected: Это описано в разделе 3.
незащищенный: это описано в разделе 3.
полезная нагрузка: это поле содержит сериализованный контент, который нужно подписать.
Если полезных данных в сообщении нет, приложение
требуется поставлять полезную нагрузку отдельно. Полезная нагрузка завернута
в bstr, чтобы гарантировать, что он транспортируется без изменений. Если
полезная нагрузка транспортируется отдельно («отдельный контент»), затем
nil CBOR объект помещается в это место, и это
ответственность приложения за то, чтобы оно было
перевезен без изменений.Примечание: когда используется подпись с алгоритмом восстановления сообщения
(Раздел 8) максимальное количество байтов, которое можно восстановить, составляет
длина полезной нагрузки. Размер полезной нагрузки уменьшен на
количество байтов, которые будут восстановлены. Если все байты
полезной нагрузки потребляются, то полезная нагрузка кодируется как
двоичная строка нулевой длины, а не отсутствующая.
подписи: это поле представляет собой массив подписей. Каждая подпись
представлен в виде структуры COSE_Signature.Стандарты Schaad Track [Страница 17]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
Фрагмент CDDL, представляющий приведенный выше текст для COSE_Sign
следует.
COSE_Sign = [
Заголовки,
полезная нагрузка: bstr / nil,
подписи: [+ COSE_Signature]
]
Структура COSE_Signature - это массив CBOR. Поля
массив по порядку:
protected: Это описано в разделе 3.незащищенный: это описано в разделе 3.
подпись: это поле содержит вычисленное значение подписи. В
тип поля - bstr. Алгоритмы ДОЛЖНЫ указывать заполнение, если
значение подписи не кратно 8 битам.
Фрагмент CDDL, представляющий приведенный выше текст для COSE_Signature
следует.
COSE_Signature = [
Заголовки,
подпись: bstr
]
4.2. Подписание с одним подписывающим лицом
Структура подписи COSE_Sign1 используется, когда только одна подпись
будет размещено в сообщении.Параметры, относящиеся к
содержимое и подпись помещаются в одну пару корзин
вместо разделения COSE_Sign.
Структура может быть закодирована как с тегами, так и без тегов в зависимости от
в контексте, в котором он будет использоваться. Помеченная структура COSE_Sign1
идентифицируется тегом CBOR 18. Фрагмент CDDL, который представляет
это:
COSE_Sign1_Tagged = # 6.18 (COSE_Sign1)
Объект CBOR, содержащий тело, подпись и
информация о теле и подписи называется COSE_Sign1
структура.Примеры сообщений COSE_Sign1 можно найти в
Приложение C.2.
Стандарты Schaad [Страница 18]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
Структура COSE_Sign1 - это массив CBOR. Поля массива в
порядок:
protected: Это описано в разделе 3.
незащищенный: это описано в разделе 3.
полезная нагрузка: это описано в разделе 4.1.
подпись: это поле содержит вычисленное значение подписи.В
тип поля - bstr.
Фрагмент CDDL, представляющий приведенный выше текст для COSE_Sign1
следует.
COSE_Sign1 = [
Заголовки,
полезная нагрузка: bstr / nil,
подпись: bstr
]
4.3. Данные, предоставленные извне
Одна из функций, предлагаемых в документе COSE, - это возможность
приложения для предоставления дополнительных данных для аутентификации, но это
не переносится как часть объекта COSE. Основная причина
подтверждение этого можно увидеть, посмотрев на структуру сообщения CoAP.
[RFC7252], где существует возможность переноса опций до
полезная нагрузка.Примеры данных, которые можно разместить в этом месте
будет код CoAP или варианты CoAP. Если данные есть в заголовке
раздел, тогда он доступен для прокси, чтобы помочь в выполнении его
операции. Например, параметр «Принять» может использоваться прокси для
определить, находится ли соответствующее значение в кеше прокси. Но
отправитель может запретить прокси-серверу изменять набор значений, которые он
примет, включив это значение в результирующую аутентификацию
тег. Однако также может быть желательно защитить эти значения, чтобы
если они изменяются в пути, это может быть обнаружено.В этом документе описывается процесс использования байтового массива
предоставленные извне аутентифицированные данные; однако метод
построение байтового массива - это функция приложения.
Приложения, использующие эту функцию, должны определить, как
предоставленные аутентифицированные данные должны быть построены. Такой
При строительстве необходимо учитывать следующие моменты:
o Если включено несколько элементов, приложения должны гарантировать, что
одна и та же байтовая строка не создается, если есть разные
входы.Это могло произойти, добавив строки «AB» и «CDE».
Стандарты Schaad Track [Страница 19]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
или добавив строки «ABC» и «DE». Обычно это
решается путем создания полей фиксированной ширины и / или кодирования
длина поля как части вывода. Использование опций из
CoAP [RFC7252] в качестве примера, эти поля используют структуру TLV, поэтому
их можно без проблем соединить.o Если включено несколько позиций, необходимо, чтобы их заказ был
определено. Используя в качестве примера параметры из CoAP, приложение
может указать, что поля должны быть упорядочены по опции
количество.
o Приложения должны гарантировать, что поток байтов будет
то же самое с обеих сторон. Использование опций CoAP может дать
проблема, если сохраняется та же относительная нумерация. Промежуточный
узел мог вставлять или удалять параметр, изменяя способ
номер готов.В приложении необходимо указать, что
относительное число необходимо перекодировать, чтобы оно относилось только к
параметры, которые есть во внешних данных.
4.4. Процесс подписания и проверки
Для создания подписи необходим четко определенный поток байтов.
Sig_structure используется для создания канонической формы. Это подписание
и процесс проверки принимает информацию о теле (COSE_Sign или
COSE_Sign1), информацию о подписавшем (COSE_Signature) и
данные приложения (внешний источник).Sig_structure - это массив CBOR.
Поля Sig_structure по порядку:
1. Текстовая строка, определяющая контекст подписи. В
строка контекста:
«Подпись» для подписей с использованием структуры COSE_Signature.
«Подпись1» для подписей, использующих структуру COSE_Sign1.
«CounterSignature» для подписей, используемых в качестве встречной подписи
атрибуты.
2. Защищенные атрибуты из структуры тела, закодированной в
Тип bstr.Если нет защищенных атрибутов, bstr из
используется нулевая длина.
3. Защищенные атрибуты из подписывающей структуры, закодированные в
Тип bstr. Если нет защищенных атрибутов, bstr из
используется нулевая длина. Это поле опущено для COSE_Sign1
структура подписи.
Стандарты Schaad Track [Страница 20]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
4. Защищенные атрибуты из приложения, закодированные в bstr
тип.Если это поле не указано, по умолчанию оно равно нулю.
длина двоичной строки. (См. Раздел 4.3 для руководства по применению.
о построении этого поля.)
5. Полезные данные, которые должны быть подписаны, закодированы в типе bstr. Полезная нагрузка
размещается здесь независимо от того, как он транспортируется.
Фрагмент CDDL, который описывает приведенный выше текст:
Sig_structure = [
контекст: «Подпись» / «Подпись1» / «КонтрПодпись»,
body_protected: empty_or_serialized_map,
? sign_protected: empty_or_serialized_map,
external_aad: bstr,
полезная нагрузка: bstr
]
Как вычислить подпись:
1.Создайте Sig_structure и заполните ее соответствующими
поля.
2. Создайте значение ToBeSigned путем кодирования Sig_structure в
байтовая строка с использованием кодировки, описанной в разделе 14.
3. Вызвать алгоритм создания подписи, передавая K (ключ к
подписать с помощью), alg (алгоритм подписания) и ToBeSigned (
значение для подписи).
4. Поместите полученное значение подписи в поле "подпись"
массив.
Шаги для проверки подписи:
1.Создайте объект Sig_structure и заполните его
соответствующие поля.
2. Создайте значение ToBeSigned путем кодирования Sig_structure в
байтовая строка с использованием кодировки, описанной в разделе 14.
3. Вызвать алгоритм проверки подписи, передающий K (ключ
для проверки), alg (используемый алгоритм подписывается с помощью), ToBeSigned
(значение для подписи) и sig (проверяемая подпись).
Schaad Standards Track [Страница 21] RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г. Помимо проверки подписи, приложение может также выполнить соответствующие проверки, чтобы убедиться, что ключ правильно в паре с удостоверением подписи и что подпись личность авторизуется перед выполнением действий.4.5. Вычисление подписей счетчиков Встречные подписи позволяют связать разные подпись, созданная разными подписывающими сторонами, с некоторым содержанием. Обычно это используется для предоставления подписи на подписи, позволяющей для доказательства того, что подпись существовала в данный момент (т.е. Отметка времени). В этом документе мы разрешаем встречные подписи существуют в большем количестве сред. Например, это можно поставить встречную подпись в незащищенных атрибутах объекта COSE_Encrypt.Это позволит посреднику либо убедитесь, что зашифрованный поток байтов не был изменен, не имея возможности его расшифровать, или утверждать, что зашифрованный байт поток либо существовал в данный момент, либо прошел через него в терминах маршрутизации (то есть подпись прокси). Пример встречной подписи на подписи можно найти в Приложение C.1.3. Пример встречной подписи в шифровании объект можно найти в Приложении C.3.3. Создание и проверка встречных подписей на разных items полагается на то, что объекты имеют одинаковую структуру.Элементы представляют собой набор защищенных атрибутов, набор незащищенных атрибуты и тело в указанном порядке. Это означает, что Sig_structure может использоваться единообразно для получения байтового потока для обработки подписи. Если встречная подпись будет вычисляется по структуре COSE_Encrypt, body_protected и элементы полезной нагрузки могут быть отображены в Sig_structure таким же образом как из структуры COSE_Sign. Следует отметить, что только алгоритм подписи с приложением (см. Раздел 8) может использоваться для встречных подписей.Это потому, что тело должно быть обработано без необходимости оценивать встречная подпись, и это невозможно для схем подписи с восстановлением сообщений. 5. Объекты шифрования COSE поддерживает две разные структуры шифрования. COSE_Encrypt0 - это используется, когда структура получателя не нужна, потому что ключ должен быть Используемый известен неявно. COSE_Encrypt используется все остальное время. Сюда входят случаи, когда есть несколько получателей или используется алгоритм получателя, отличный от прямого.Schaad Standards Track [Страница 22]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
5.1. Обволакивающая структура COSE
Обернутая структура позволяет одному или нескольким получателям
сообщение. Существуют положения о параметрах содержания и
параметры информации о получателе, которая будет передаваться в
сообщение. Защищенные параметры, связанные с контентом:
аутентифицировано алгоритмом шифрования контента.Защищенный
параметры, связанные с получателем, аутентифицируются
алгоритм получателя (если алгоритм его поддерживает). Примеры
параметры контента - это тип контента и
алгоритм шифрования контента. Примеры параметров о
получатель - это ключевой идентификатор получателя и получатель
алгоритм шифрования.
Те же методы и структуры используются для шифрования как
открытый текст и ключи. Это отличается от подхода, используемого
как "Синтаксис криптографических сообщений (CMS)" [RFC5652], так и "JSON Web
Шифрование (JWE) "[RFC7516], где разные структуры используются для
уровень содержимого и уровень получателя.Две структуры
определено: COSE_Encrypt для хранения зашифрованного содержимого и
COSE_recipient для хранения зашифрованных ключей для получателей. Примеры
зашифрованных сообщений можно найти в Приложении C.3.
Структура COSE_Encrypt может быть закодирована как тегированная, так и
без тегов в зависимости от контекста, в котором он будет использоваться.
Структура COSE_Encrypt идентифицируется тегом 96 CBOR. CDDL
фрагмент, который представляет это:
COSE_Encrypt_Tagged = # 6.96 (COSE_Encrypt)
Структура COSE_Encrypt - это массив CBOR.Поля массива
по порядку:
protected: Это описано в разделе 3.
незащищенный: это описано в разделе 3.
ciphertext: это поле содержит зашифрованный текст, закодированный как bstr.
Если зашифрованный текст должен передаваться независимо от
контролировать информацию о процессе шифрования (т.е.
content), то поле кодируется как нулевое значение.
получатели: это поле содержит массив информации о получателе.
конструкции.Типом информационной структуры получателя является
COSE_recipient.
Стандарты Schaad Track [Страница 23]
RFC 8152 CBOR Object Signing and Encryption (COSE) июль 2017 г.
Фрагмент CDDL, который соответствует приведенному выше тексту:
COSE_Encrypt = [
Заголовки,
зашифрованный текст: bstr / nil,
получатели: [+ COSE_recipient]
]
Структура COSE_recipient представляет собой массив CBOR. Поля
массив по порядку:
protected: Это описано в разделе 3.незащищенный: это описано в разделе 3.
ciphertext: это поле содержит зашифрованный ключ, закодированный как bstr.
Все закодированные ключи являются симметричными ключами; двоичное значение ключа
это содержание. Если нет зашифрованного ключа, то это поле
кодируется как нулевое значение.
получатели: это поле содержит массив информации о получателе.
конструкции. Типом информационной структуры получателя является
COSE_recipient (пример этого можно найти в Приложении B).Если нет информационных структур получателя, этот элемент
отсутствует.
Фрагмент CDDL, соответствующий приведенному выше тексту для
COSE_recipient:
COSE_recipient = [
Заголовки,
зашифрованный текст: bstr / nil,
? получатели: [+ COSE_recipient]
]
5.1.1. Методы распространения ключей контента
Зашифрованное сообщение состоит из зашифрованного содержимого и
зашифрованный CEK для одного или нескольких получателей. CEK зашифрован для
каждого получателя, используя ключ, свойственный этому получателю.Детали
этого шифрования зависит от того, какого класса алгоритм получателя
падает в. Конкретные подробности по каждому из классов можно найти в
S Примеры полного процесса подписания подписи версии 4 (Python)
В этом разделе показаны примеры программ, написанных на Python, которые иллюстрируют, как работать с участием Подпись версии 4 в AWS.Мы сознательно написали эти примеры программ, чтобы они были простыми. (использовать несколько специфичных для Python функций), чтобы облегчить понимание всего процесса подписания Запросы AWS.
Если вы используете один из AWS SDK (включая SDK для C ++, SDK для Go, SDK для Java, AWS SDK для JavaScript, AWS SDK для.NET, SDK для PHP, SDK для Python (Boto3) или SDK для Ruby), вам не нужно вручную выполнять шаги по созданию ключ подписи и добавление информации для аутентификации в запрос. SDK выполняют это работать на вас. Вам нужно вручную подписывать запросы только в том случае, если вы напрямую делаете HTTP или же HTTPS-запросы.
Для работы с этими примерами программ вам потребуется следующее:
Python 2.x, установленный на вашем компьютере, который вы можете получить с сайта Python. Эти программы были протестированы используя Python 2.7 и 3.6.
Python запрашивает библиотеку , которая используется в примере сценария для создания веб- Запросы.Удобный способ установки пакетов Python — использовать
pip, который получает пакеты с сайта индекса пакетов Python. Затем вы можете установитьзапрашивает, запустивpip install requestsв командной строке.Ключ доступа (идентификатор ключа доступа и секретный ключ доступа) в переменных среды с именем
AWS_ACCESS_KEY_IDиAWS_SECRET_ACCESS_KEY.В качестве альтернативы, вы можете сохранить эти значения в файле учетных данных и прочитать их из этого файла. Как Лучший На практике мы рекомендуем вам вводить учетные данные в код , а не . Для получения дополнительной информации см. Рекомендации по управлению AWS. Ключи доступа в общем справочнике Amazon Web Services .
В следующих примерах используется UTF-8 для кодирования канонического запроса и строки для подписи, но Подпись версии 4 не требует использования определенной кодировки символов. Тем не мение, для некоторых сервисов AWS может потребоваться определенная кодировка.Для получения дополнительной информации обратитесь к то документация для этой услуги.
В следующем примере показано, как сделать запрос с помощью API запросов Amazon EC2 без
SDK для Python (Boto3).Запрос
делает запрос GET и передает информацию аутентификации в AWS с помощью Авторизация заголовок.
# Copyright 2010-2019 Amazon.com, Inc. или ее аффилированные лица. Все права защищены.
#
# Этот файл находится под лицензией Apache License версии 2.0 («Лицензия»).
# Вы не можете использовать этот файл, кроме как в соответствии с Лицензией.Копия
# Лицензия находится по адресу
#
# http://aws.amazon.com/apache2.0/
#
# Этот файл распространяется "КАК ЕСТЬ", БЕЗ ГАРАНТИЙ И УСЛОВИЙ.
# ЛЮБОГО ВИДА, явного или подразумеваемого. См. Лицензию для конкретных
# язык, регулирующий разрешения и ограничения по Лицензии.
#
# ОБ ЭТОМ ОБРАЗЕЦЕ PYTHON: Этот образец является частью общего справочника AWS.
# Подписание запросов API AWS вверху доступно на
# https://docs.aws.amazon.com/general/latest/gr/sigv4-signed-request-examples.html
#
# Пример подписи AWS версии 4
# EC2 API (DescribeRegions)
# См .: http://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html
# Эта версия делает запрос GET и передает подпись
# в заголовке авторизации.
импорт sys, os, base64, datetime, hashlib, hmac
запросов на импорт # запросов на установку пакетов
# ************* ЗНАЧЕНИЯ ЗАПРОСА *************
метод = 'ПОЛУЧИТЬ'
service = 'ec2'
host = 'ec2.amazonaws.com'
region = 'us-east-1'
endpoint = 'https://ec2.amazonaws.com'
request_parameters = 'Действие = DescribeRegions & Version = 2013-10-15'
# Ключевые производные функции.Видеть:
# http://docs.aws.amazon.com/general/latest/gr/signature-v4-examples.html#signature-v4-examples-python
def знак (ключ, сообщение):
вернуть hmac.new (ключ, msg.encode ('utf-8'), hashlib.sha256) .digest ()
def getSignatureKey (ключ, dateStamp, regionName, serviceName):
kDate = знак (('AWS4' + ключ) .encode ('utf-8'), dateStamp)
kRegion = знак (kDate, regionName)
kService = знак (kRegion, serviceName)
kSigning = знак (kService, 'aws4_request')
return kSigning
# Прочитать ключ доступа к AWS из env.переменные или файл конфигурации. Лучшая практика НЕ
# для вставки учетных данных в код.
access_key = os.environ.get ('AWS_ACCESS_KEY_ID')
secret_key = os.environ.get ('AWS_SECRET_ACCESS_KEY')
если access_key - None или secret_key - None:
print («Нет ключа доступа.»)
sys.exit ()
# Создайте дату для заголовков и строки учетных данных
t = datetime.datetime.utcnow ()
amzdate = t.strftime ('% Y% m% dT% H% M% SZ')
datestamp = t.strftime ('% Y% m% d') # Дата без времени, используется в области учетных данных
# ************* ЗАДАЧА 1: СОЗДАТЬ КАНОНИЧЕСКИЙ ЗАПРОС *************
# http: // docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html
# Шаг 1 - определение глагола (GET, POST и т. Д.) - уже сделано.
# Шаг 2. Создайте канонический URI - часть URI от домена для запроса
# строка (используйте '/', если нет пути)
canonical_uri = '/'
# Шаг 3. Создайте каноническую строку запроса. В этом примере (запрос GET),
# параметры запроса находятся в строке запроса. Значения строки запроса должны
# быть в кодировке URL (пробел =% 20). Параметры необходимо отсортировать по имени.
# В этом примере строка запроса предварительно отформатирована в переменной request_parameters.canonical_querystring = параметры_запроса
# Шаг 4. Создайте канонические заголовки и подписанные заголовки. Имена заголовков
# должен быть обрезан, должен быть строчным и отсортирован в порядке кодирования от
# снизу вверх. Обратите внимание, что есть завершающий \ n.
canonical_headers = 'host:' + host + '\ n' + 'x-amz-date:' + amzdate + '\ n'
# Шаг 5: Создайте список подписанных заголовков. Это список заголовков
# в списке canonical_headers, разделенные знаком ";" и в альфа-порядке.
# Примечание: запрос может включать любые заголовки; canonical_headers и
# signed_headers перечисляет те, которые вы хотите включить в
# хеш запроса."Host" и "x-amz-date" требуются всегда.
signed_headers = 'хост; x-amz-date'
# Шаг 6: Создайте хеш полезной нагрузки (хеш содержимого тела запроса). Для GET
# запросов, полезная нагрузка - это пустая строка ("").
payload_hash = hashlib.sha256 ((''). encode ('utf-8')). hexdigest ()
# Шаг 7. Объедините элементы для создания канонического запроса.
canonical_request = method + '\ n' + canonical_uri + '\ n' + canonical_querystring + '\ n' + canonical_headers + '\ n' + signed_headers + '\ n' + payload_hash
# ************* ЗАДАЧА 2: СОЗДАТЬ СТРОКУ ДЛЯ ПОДПИСИ *************
# Сопоставьте алгоритм с используемым алгоритмом хеширования, либо SHA-1, либо
# SHA-256 (рекомендуется)
алгоритм = 'AWS4-HMAC-SHA256'
credential_scope = datestamp + '/' + регион + '/' + service + '/' + 'aws4_request'
string_to_sign = алгоритм + '\ n' + amzdate + '\ n' + credential_scope + '\ n' + hashlib.sha256 (canonical_request.encode ('utf-8')). hexdigest ()
# ************* ЗАДАЧА 3: РАССЧИТАТЬ ПОДПИСЬ *************
# Создайте ключ подписи, используя функцию, определенную выше.
Signing_key = getSignatureKey (secret_key, отметка даты, регион, услуга)
# Подпишите string_to_sign с помощью signature_key
подпись = hmac.new (ключ_подписания, (строка_то_знак) .encode ('utf-8'), hashlib.sha256) .hexdigest ()
# ************* ЗАДАЧА 4: ДОБАВИТЬ ИНФОРМАЦИЮ ДЛЯ ПОДПИСИ К ЗАПРОСУ *************
# Информация для подписи может быть либо в значении строки запроса, либо в
# заголовок с именем Authorization.Этот код показывает, как использовать заголовок.
# Создать заголовок авторизации и добавить в заголовки запроса
authorization_header = алгоритм + '' + 'Credential =' + access_key + '/' + credential_scope + ',' + 'SignedHeaders =' + signed_headers + ',' + 'Signature =' + подпись
# Запрос может включать любые заголовки, но ДОЛЖЕН включать "host", "x-amz-date",
# и (для этого сценария) «Авторизация». "host" и "x-amz-date" должны
# быть включены в canonical_headers и signed_headers, как указано
# ранее. Порядок здесь не имеет значения.# Примечание для Python: заголовок host автоматически добавляется библиотекой запросов Python.
заголовки = {'x-amz-date': amzdate, 'Authorization': authorization_header}
# ************* ОТПРАВИТЬ ЗАПРОС *************
request_url = endpoint + '?' + canonical_querystring
print ('\ nНАЧАТЬ ЗАПРОС +++++++++++++++++++++++++++++++++++')
print ('URL запроса =' + request_url)
r = requests.get (request_url, заголовки = заголовки)
print ('\ nRESPONSE ++++++++++++++++++++++++++++++++++++')
print ('Код ответа:% d \ n'% r.status_code)
печать (r.текст)
Использование POST (Python)
В следующем примере показано, как сделать запрос с помощью запроса Amazon DynamoDB.
API без SDK для Python (Boto3). В
request делает POST-запрос и передает значения в AWS в теле запроса.Информация об аутентификации передается с использованием заголовка запроса Authorization .
# Copyright 2010-2019 Amazon.com, Inc. или ее аффилированные лица. Все права защищены.
#
# Этот файл находится под лицензией Apache License версии 2.0 («Лицензия»).
# Вы не можете использовать этот файл, кроме как в соответствии с Лицензией. Копия
# Лицензия находится по адресу
#
# http://aws.amazon.com / apache2.0 /
#
# Этот файл распространяется "КАК ЕСТЬ", БЕЗ ГАРАНТИЙ И УСЛОВИЙ.
# ЛЮБОГО ВИДА, явного или подразумеваемого. См. Лицензию для конкретных
# язык, регулирующий разрешения и ограничения по Лицензии.
# Пример подписи AWS версии 4
# DynamoDB API (CreateTable)
# См .: http://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html
# Эта версия делает запрос POST и передает параметры запроса
# в теле (полезной нагрузке) запроса. Информация об авторизации передается в
# Заголовок авторизации.импорт sys, os, base64, datetime, hashlib, hmac
запросов на импорт # запросов на установку пакетов
# ************* ЗНАЧЕНИЯ ЗАПРОСА *************
method = 'POST'
service = 'Dynamodb'
host = 'Dynamodb.us-west-2.amazonaws.com'
region = 'us-west-2'
endpoint = 'https://dynamodb.us-west-2.amazonaws.com/'
# POST-запросы используют заголовок типа контента. Для DynamoDB,
# контент в формате JSON.
content_type = 'приложение / x-amz-json-1.0'
# DynamoDB требуется заголовок x-amz-target в следующем формате:
# DynamoDB_ <версия API>.<имя_операции>
amz_target = 'DynamoDB_20120810.CreateTable'
# Параметры запроса для CreateTable - передаются в блоке JSON.
request_parameters = '{'
request_parameters + = '"KeySchema": [{"KeyType": "HASH", "AttributeName": "Id"}],'
request_parameters + = '"TableName": "TestTable", "AttributeDefinitions": [{"AttributeName": "Id", "AttributeType": "S"}],'
request_parameters + = '"ProvisionedThroughput": {"WriteCapacityUnits": 5, "ReadCapacityUnits": 5}'
параметры_запроса + = '}'
# Ключевые производные функции.Видеть:
# http://docs.aws.amazon.com/general/latest/gr/signature-v4-examples.html#signature-v4-examples-python
def знак (ключ, сообщение):
вернуть hmac.new (ключ, msg.encode ("utf-8"), hashlib.sha256) .digest ()
def getSignatureKey (ключ, отметка_даты, имя_региона, имя_службы):
kDate = знак (('AWS4' + ключ) .encode ('utf-8'), date_stamp)
kRegion = знак (kDate, regionName)
kService = знак (kRegion, serviceName)
kSigning = знак (kService, 'aws4_request')
return kSigning
# Прочитать ключ доступа к AWS из env.переменные или файл конфигурации. Лучшая практика НЕ
# для вставки учетных данных в код.
access_key = os.environ.get ('AWS_ACCESS_KEY_ID')
secret_key = os.environ.get ('AWS_SECRET_ACCESS_KEY')
если access_key - None или secret_key - None:
print («Нет ключа доступа.»)
sys.exit ()
# Создайте дату для заголовков и строки учетных данных
t = datetime.datetime.utcnow ()
amz_date = t.strftime ('% Y% m% dT% H% M% SZ')
date_stamp = t.strftime ('% Y% m% d') # Дата без времени, используется в области учетных данных
# ************* ЗАДАЧА 1: СОЗДАТЬ КАНОНИЧЕСКИЙ ЗАПРОС *************
# http: // docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html
# Шаг 1 - определение глагола (GET, POST и т. Д.) - уже сделано.
# Шаг 2. Создайте канонический URI - часть URI от домена для запроса
# строка (используйте '/', если нет пути)
canonical_uri = '/'
## Шаг 3. Создайте каноническую строку запроса. В этом примере запрос
# параметры передаются в теле запроса и строке запроса
# пусто.
canonical_querystring = ''
# Шаг 4. Создайте канонические заголовки. Имена заголовков должны быть обрезаны
# и строчные буквы и отсортированы в порядке кодирования от меньшего к большему.# Обратите внимание, что есть завершающий \ n.
canonical_headers = 'content-type:' + content_type + '\ n' + 'host:' + host + '\ n' + 'x-amz-date:' + amz_date + '\ n' + 'x-amz-target : '+ amz_target +' \ n '
# Шаг 5: Создайте список подписанных заголовков. Это список заголовков
# в списке canonical_headers, разделенные знаком ";" и в альфа-порядке.
# Примечание: запрос может включать любые заголовки; canonical_headers и
# signed_headers включают те, которые вы хотите включить в
# хеш запроса. "Host" и "x-amz-date" требуются всегда.# Для DynamoDB также требуются content-type и x-amz-target.
signed_headers = 'тип содержимого; хост; x-amz-date; x-amz-target'
# Шаг 6: Создайте хеш полезной нагрузки. В этом примере полезная нагрузка (тело
# запрос) содержит параметры запроса.
payload_hash = hashlib.sha256 (параметры_запроса.encode ('utf-8')). hexdigest ()
# Шаг 7. Объедините элементы для создания канонического запроса.
canonical_request = method + '\ n' + canonical_uri + '\ n' + canonical_querystring + '\ n' + canonical_headers + '\ n' + signed_headers + '\ n' + payload_hash
# ************* ЗАДАЧА 2: СОЗДАТЬ СТРОКУ ДЛЯ ПОДПИСИ *************
# Сопоставьте алгоритм с используемым алгоритмом хеширования, либо SHA-1, либо
# SHA-256 (рекомендуется)
алгоритм = 'AWS4-HMAC-SHA256'
credential_scope = date_stamp + '/' + регион + '/' + service + '/' + 'aws4_request'
string_to_sign = алгоритм + '\ n' + amz_date + '\ n' + credential_scope + '\ n' + hashlib.sha256 (canonical_request.encode ('utf-8')). hexdigest ()
# ************* ЗАДАЧА 3: РАССЧИТАТЬ ПОДПИСЬ *************
# Создайте ключ подписи, используя функцию, определенную выше.
Signing_key = getSignatureKey (secret_key, date_stamp, регион, услуга)
# Подпишите string_to_sign с помощью signature_key
подпись = hmac.new (ключ_подписания, (строка_то_знак) .encode ('utf-8'), hashlib.sha256) .hexdigest ()
# ************* ЗАДАЧА 4: ДОБАВИТЬ ИНФОРМАЦИЮ ДЛЯ ПОДПИСИ К ЗАПРОСУ *************
# Поместите информацию о подписи в заголовок с именем Авторизация.authorization_header = алгоритм + '' + 'Credential =' + access_key + '/' + credential_scope + ',' + 'SignedHeaders =' + signed_headers + ',' + 'Signature =' + подпись
# Для DynamoDB запрос может включать любые заголовки, но ДОЛЖЕН включать "host", "x-amz-date",
# "x-amz-target", "content-type" и "Authorization". Кроме авторизации
# заголовок, заголовки должны быть включены в значения canonical_headers и signed_headers, как
# отмечалось ранее. Порядок здесь не имеет значения.
# # Примечание по Python: заголовок host автоматически добавляется библиотекой запросов Python.headers = {'Content-Type': content_type,
"X-Amz-Date": amz_date,
"X-Amz-Target": amz_target,
'Авторизация': authorization_header}
# ************* ОТПРАВИТЬ ЗАПРОС *************
print ('\ nНАЧАТЬ ЗАПРОС +++++++++++++++++++++++++++++++++++')
print ('URL-адрес запроса =' + конечная точка)
r = requests.post (конечная точка, данные = параметры_запроса, заголовки = заголовки)
print ('\ nRESPONSE ++++++++++++++++++++++++++++++++++++')
print ('Код ответа:% d \ n'% r.status_code)
печать (r.text)
Использование GET с данными аутентификации в строке запроса (Python)
В следующем примере показано, как сделать запрос с помощью API запросов IAM без SDK для Python (Boto3).Запрос делает запрос GET и передает параметры и подписывающую информацию с помощью запроса строка.
# Copyright 2010-2019 Amazon.com, Inc. или ее аффилированные лица. Все права защищены.
#
# Этот файл находится под лицензией Apache License версии 2.0 («Лицензия»).
# Вы не можете использовать этот файл, кроме как в соответствии с Лицензией. Копия
# Лицензия находится по адресу
#
# http: // aws.amazon.com/apache2.0/
#
# Этот файл распространяется "КАК ЕСТЬ", БЕЗ ГАРАНТИЙ И УСЛОВИЙ.
# ЛЮБОГО ВИДА, явного или подразумеваемого. См. Лицензию для конкретных
# язык, регулирующий разрешения и ограничения по Лицензии.
#
# ОБ ЭТОМ ОБРАЗЕЦЕ PYTHON: Этот образец является частью общего справочника AWS.
# Подписание запросов API AWS вверху доступно на
# https://docs.aws.amazon.com/general/latest/gr/sigv4-signed-request-examples.html
#
# Пример подписи AWS версии 4
# IAM API (CreateUser)
# См .: http: // docs.aws.amazon.com/general/latest/gr/sigv4_signing.html
# Эта версия делает запрос GET и передает параметры запроса
# и информация об авторизации в строке запроса
импорт sys, os, base64, datetime, hashlib, hmac, urllib
запросов на импорт # запросов на установку пакетов
# ************* ЗНАЧЕНИЯ ЗАПРОСА *************
метод = 'ПОЛУЧИТЬ'
service = 'iam'
host = 'iam.amazonaws.com'
region = 'us-east-1'
endpoint = 'https://iam.amazonaws.com'
# Ключевые производные функции. Видеть:
# http://docs.aws.amazon.com/general/latest/gr/signature-v4-examples.html # подпись-v4-examples-python
def знак (ключ, сообщение):
вернуть hmac.new (ключ, msg.encode ('utf-8'), hashlib.sha256) .digest ()
def getSignatureKey (ключ, dateStamp, regionName, serviceName):
kDate = знак (('AWS4' + ключ) .encode ('utf-8'), dateStamp)
kRegion = знак (kDate, regionName)
kService = знак (kRegion, serviceName)
kSigning = знак (kService, 'aws4_request')
return kSigning
# Прочитать ключ доступа к AWS из env. переменные или файл конфигурации. Лучшая практика НЕ
# для вставки учетных данных в код.access_key = os.environ.get ('AWS_ACCESS_KEY_ID')
secret_key = os.environ.get ('AWS_SECRET_ACCESS_KEY')
если access_key - None или secret_key - None:
print («Нет ключа доступа.»)
sys.exit ()
# Создайте дату для заголовков и строки учетных данных
t = datetime.datetime.utcnow ()
amz_date = t.strftime ('% Y% m% dT% H% M% SZ') # Форматировать дату как YYYYMMDD'T'HHMMSS'Z '
datestamp = t.strftime ('% Y% m% d') # Дата без времени, используется в области учетных данных
# ************* ЗАДАЧА 1: СОЗДАТЬ КАНОНИЧЕСКИЙ ЗАПРОС *************
# http: // docs.aws.amazon.com/general/latest/gr/sigv4-create-canonical-request.html
# Поскольку почти вся информация передается в строке запроса,
# порядок этих шагов немного отличается от примеров,
# использовать заголовок авторизации.
# Шаг 1. Определите глагол (GET, POST и т. Д.) - уже сделано.
# Шаг 2. Создайте канонический URI - часть URI от домена для запроса
# строка (используйте '/', если нет пути)
canonical_uri = '/'
# Шаг 3. Создайте канонические заголовки и подписанные заголовки. Имена заголовков
# должен быть обрезан, должен быть строчным и отсортирован в порядке кодирования от
# снизу вверх.Обратите внимание на завершающий символ \ n в canonical_headers.
# signed_headers - это список включаемых заголовков
# как часть процесса подписания. Для запросов, использующих строки запроса,
# только "host" включается в подписанные заголовки.
canonical_headers = 'хост:' + хост + '\ n'
signed_headers = 'хост'
# Сопоставьте алгоритм с используемым алгоритмом хеширования, либо SHA-1, либо
# SHA-256 (рекомендуется)
алгоритм = 'AWS4-HMAC-SHA256'
credential_scope = datestamp + '/' + регион + '/' + service + '/' + 'aws4_request'
# Шаг 4. Создайте каноническую строку запроса.В этом примере запрос
# параметры находятся в строке запроса. Значения строки запроса должны
# быть в кодировке URL (пробел =% 20). Параметры необходимо отсортировать по имени.
# используйте urllib.parse.quote_plus () при использовании Python 3
canonical_querystring = 'Action = CreateUser & UserName = NewUser & Version = 2010-05-08'
canonical_querystring + = '& X-Amz-Алгоритм = AWS4-HMAC-SHA256'
canonical_querystring + = '& X-Amz-Credential =' + urllib.quote_plus (access_key + '/' + credential_scope)
canonical_querystring + = '& X-Amz-Date =' + amz_date
canonical_querystring + = '& X-Amz-Expires = 30'
canonical_querystring + = '& X-Amz-SignedHeaders =' + подписанные_заголовки
# Шаг 5: Создайте хеш полезной нагрузки.Для запросов GET полезная нагрузка - это
# пустой строкой ("").
payload_hash = hashlib.sha256 ((''). encode ('utf-8')). hexdigest ()
# Шаг 6. Объедините элементы, чтобы создать канонический запрос.
canonical_request = method + '\ n' + canonical_uri + '\ n' + canonical_querystring + '\ n' + canonical_headers + '\ n' + signed_headers + '\ n' + payload_hash
# ************* ЗАДАЧА 2: СОЗДАТЬ СТРОКУ ДЛЯ ПОДПИСИ *************
string_to_sign = алгоритм + '\ n' + amz_date + '\ n' + credential_scope + '\ n' + hashlib.sha256 (canonical_request.кодировать ('utf-8')). hexdigest ()
# ************* ЗАДАЧА 3: РАССЧИТАТЬ ПОДПИСЬ *************
# Создаем ключ подписи
Signing_key = getSignatureKey (secret_key, отметка даты, регион, услуга)
# Подпишите string_to_sign с помощью signature_key
подпись = hmac.new (ключ_ подписи, (строковый_знак) .encode ("utf-8"), hashlib.sha256) .hexdigest ()
# ************* ЗАДАЧА 4: ДОБАВИТЬ ИНФОРМАЦИЮ ДЛЯ ПОДПИСИ К ЗАПРОСУ *************
# Информация об авторизации может быть либо в строке запроса
# значение или в заголовке с именем Авторизация.Этот код показывает, как поставить
# все в строку запроса.
canonical_querystring + = '& X-Amz-Signature =' + подпись
# ************* ОТПРАВИТЬ ЗАПРОС *************
# Заголовок 'host' автоматически добавляется библиотекой Python 'request'. Но это
# должен существовать как заголовок в запросе.
request_url = endpoint + "?" + canonical_querystring
print ('\ nНАЧАТЬ ЗАПРОС +++++++++++++++++++++++++++++++++++')
print ('URL запроса =' + request_url)
r = requests.get (request_url)
print ('\ nRESPONSE ++++++++++++++++++++++++++++++++++++')
print ('Код ответа:% d \ n'% r.status_code)
печать (r.text)
подписать документы онлайн бесплатно — DigiSigner
Для подписания документа не требуется устанавливать программы и приложения. Наш бесплатный онлайн-сервис позволяет подписать документы прямо в браузере. Мы поддерживаем несколько файлов форматы и самое лучшее, что наша подписывающая сторона абсолютно бесплатна!
Просто перетащите документ в синюю рамку, как показано. ниже или нажмите ссылку «выбрать файл» и выберите файл вам нужно подписать.Ваш файл может быть в формате PDF, Word, TXT, IMG, TXT или Формат XLS.
Ваш документ почти сразу появляются на экране после завершения загрузки.
Наш инструмент полностью укомплектован всем необходимым, не только для создания электронной подписи, но и для заполнения из ваших форм в Интернете, добавив текст, установив флажки, вставка текущей даты или даже инициализация при необходимости.Как только вы войдете, вы можете выбрать тип изменений, которые хотите применить. к вашему документу.
Наведите указатель мыши на области где вы хотите поставить свою подпись, и нажмите на документ.
Не стесняйтесь подписывать документ любым способом тебе нравится. Это лицо, подписывающее документ, предлагает три различных вариантов подписи документов:
A) Нарисуйте электронную подпись с помощью мыши или тачпада.
B) Введите свое имя.
C) Отсканируйте изображение своей подписи и загрузите его в документ.
Как мы упоминали ранее, вы также можете добавить галочки, даты, текст или инициалы на любую страницу вашего документ. Просто выберите тип функции, которую хотите использовать, выберите область и введите информацию.
Включить единый вход с помощью SAML
Стандарт федерации удостоверений Security Assertion Markup Language (SAML) 2.0 обеспечивает безопасный обмен данными аутентификации пользователей между веб-приложениями и поставщиками услуг идентификации.
Когда вы используете протокол SAML 2.0 для включения единого входа (SSO), маркеры безопасности, содержащие утверждения , передают информацию о конечном пользователе (принципал) между органом SAML — identity
provider (IdP) , а потребитель SAML — поставщик услуг (SP) .
Adobe Sign, выступая в качестве поставщика услуг (SP) , поддерживает единый вход через SAML с использованием внешних поставщиков удостоверений (IdP), таких как Okta, OneLogin, Oracle Federated Identity (OIF) и Microsoft Active Directory Federation Service. . Adobe Sign совместим со всеми внешними поставщиками идентификационной информации, поддерживающими SAML 2.0.
Более подробную информацию об интеграции с этими поставщиками удостоверений (IdP) можно найти в следующих руководствах:
Вы также можете настроить Adobe Sign для единого входа (SSO) с другими системами, уже используемыми в вашей организации, например Salesforce.com или других поставщиков, поддерживающих SAML 2.0.
Adobe Sign использует федеративную проверку подлинности вместо делегированной проверки подлинности. Федеративная проверка подлинности не проверяет действительный пароль пользователя в Adobe Sign. Вместо этого Adobe Sign получает подтверждение SAML в запросе HTTP POST. Adobe Sign также поддерживает зашифрованные утверждения .
Утверждение SAML имеет ограниченный срок действия, содержит уникальный идентификатор и имеет цифровую подпись.Если утверждение все еще находится в пределах срока его действия, имеет идентификатор, который не использовался ранее, и имеет действительную подпись от доверенного поставщика удостоверений, пользователю предоставляется доступ к Adobe Sign.
Краткое изложение спецификации аутентификации Adobe Sign приведено в таблице ниже:
D4Sign, эффективная платформа для цифровой и электронной почты. Armazenar os seus documentos e Contratos eletronicamente. Assinatura digital. Assinatura eletrônica. Assinatura eletrônica São Paulo.Documento eletrônico. Assinatura documento. D4Sign. Como assinar documento digitalmente.
Perfeitamente válidas, соответствует Medida Provisória № 2.200-2 / 2001
A assinatura eletrônica está amparada pela Medida Provisória nº 2.200-2 / 2001, que instituiu a Infra-Estrutura de Chaves Públicas Brasileira — ICP-Brasil para garantir autenticidade, интегрированная и юридическая юридическая проверка документов.
A Medida Provisória № 2.200-2 / 2001, ст. 10, § 2o dispõe o seguinte:
«O disposto nesta Medida Provisória não obsta a utilização de outro meio de comprovação da autoria e integridade de documentos em forma eletrônica, включая os que utilizem Certificados não emitidos pela ICP-Brasil, desde quésé parlés de la de la de la de la de la de la de la de la de la de la de la de la de Pés de la de la de la de la de la de la de la de la de la de la la Brasil» quem for oposto o documento.«
Esta norma deixa clear que o Certificado ICP-Brasil não é o único meio para comprovação de autoria e integridade das assinaturas eletrônica, ou seja, desde que admitida pelas partes como válida, qualquer as sero válida, qualquer assoinálálátro meio.
Atuamos como uma autoridade Certificadora Privada, oferecendo meios de comprovação da autoria e da integridade de documentos com os melhores padrões de assinatura eletrônica.
Além da Medida Provisória, há inúmeros enunciados do Poder Judicário confirmando a validade das assinaturas eletrônicas, como, por exemplo, или enunciado 297 do Conselho da Justiça Federal:
«O documento eletrônico tem valor probante, desde que seja apto a conservar a integridade de seu context e idôneo a apontar sua autoria, independentemente da tecnologia empregada. «
Ainda, cada dia Surm novos entendimentos Favoris a outras modalidades de assinaturas eletrônicas, como por exemplo a Circular nº 3.829 от 09/03/2017, do Banco Central do Brasil, onde, acertadamente, passa a admitir dequer modalica nos Contratos de Câmbio :
«Altera a Circular nº 3».691, de 16 de dezembro de 2013, fim de permissionir a utilização de assinaturas eletrônicas em contratos de câmbio em qualquer formato admitido pelas partes como válido e aceito pela pessoa a quem for oposto o documento.
Link do enunciado
Integra da medida provisória 2200-2 / 2001
Integra da Circular do Banco Central
Рекомендации по доступности веб-контента (WCAG) 2.1
Руководство по обеспечению доступности веб-контента (WCAG) 2.1W3C Рекомендация
- Эта версия:
- https://www.w3.org/TR/2018/REC-WCAG21-20180605/
- Последняя опубликованная версия:
- https://www.w3.org/TR/WCAG21/
- Черновик последнего редактора:
- https://w3c.github.io/wcag/21/guidelines/
- Отчет о реализации:
- https://www.w3.org/WAI/WCAG21/implementation-report/
- Предыдущая версия:
- https: // www.w3.org/TR/2018/PR-WCAG21-20180424/
- Предыдущая рекомендация:
- https://www.w3.org/TR/2008/REC-WCAG20-20081211/
- Редакторы:
- Эндрю Киркпатрик (Adobe)
- Джошу О Коннор (приглашенный эксперт, InterAccess)
- Аластер Кэмпбелл (Номенса)
- Майкл Купер ( W3C )
- Редакторы WCAG 2.0 (до декабря 2008 г.):
- Бен Колдуэлл (Центр исследований и разработок Trace, Университет Висконсин-Мэдисон)
- Лоретта Гуарино Рид (Google, Inc.)
- Грегг Вандерхайден (Центр исследований и разработок Trace, Университет Висконсин-Мэдисон)
- Венди Чизолм ( W3C )
- Джон Слатин (Институт доступности Техасского университета в Остине)
- Джейсон Уайт (Мельбурнский университет)
Пожалуйста, проверьте ошибку на наличие ошибок или проблем сообщается с момента публикации.
Смотрите также переводов .
Этот документ также доступен в ненормативных форматах, доступных из Альтернативных версий Руководства по обеспечению доступности веб-контента 2.1.
Авторские права © 2017-2018 гг. W3C ® ( MIT , ERCIM , Кейо, Бейхан). W3C ответственность, товарный знак и использование документов применяются правила.
Абстрактные
Руководство по доступности веб-контента (WCAG) 2.1 охватывает широкий спектр рекомендаций по повышению доступности веб-контента.Следование этим рекомендациям сделает контент более доступным для более широкого круга людей с ограниченными возможностями, включая приспособления для слепоты и слабовидения, глухоты и потери слуха, ограниченного движения, нарушения речи, светочувствительности и их сочетаний, а также некоторые приспособления для лиц с ограниченными возможностями обучения и когнитивные ограничения; но не будет удовлетворять все потребности пользователей с этими ограниченными возможностями. Эти рекомендации касаются доступности веб-контента на настольных компьютерах, ноутбуках, планшетах и мобильных устройствах.Следование этим рекомендациям также часто делает веб-контент более удобным для пользователей в целом.
Критерии успеха WCAG 2.1 записаны в виде проверяемых утверждений, которые не зависят от технологии. Руководство по выполнению критериев успеха в конкретных технологиях, а также общая информация об интерпретации критериев успеха представлены в отдельных документах. См. Обзор рекомендаций по обеспечению доступности веб-контента (WCAG) для введения и ссылок на технические и учебные материалы WCAG.
WCAG 2.1 расширяет Руководство по доступности веб-контента 2.0 [ WCAG20 ], которое было опубликовано как рекомендация W3C в декабре 2008 г. Контент, соответствующий WCAG 2.1, также соответствует WCAG 2.0. РГ предполагает, что для политик, требующих соответствия WCAG 2.0, WCAG 2.1 может предоставить альтернативные средства соответствия. Публикация WCAG 2.1 не отменяет и не заменяет WCAG 2.0. В то время как WCAG 2.0 остается Рекомендацией W3C , W3C рекомендует использовать WCAG 2.1, чтобы максимизировать применимость усилий по обеспечению доступности в будущем. W3C также поощряет использование самой последней версии WCAG при разработке или обновлении политик веб-доступности.
Статус этого документа
В этом разделе описывается статус этого документа на момент его публикации. Другие документы могут заменять этот документ. Список текущих публикаций W3C и последнюю версию этого технического отчета можно найти в указателе технических отчетов W3C по адресу https: // www.w3.org/TR/.
Это Рекомендация WCAG 2.1 Рабочей группы Руководства по доступности.
Этот документ был рассмотрен членами W3C , разработчиками программного обеспечения и другими группами W3C и заинтересованными сторонами, и одобрен Директором как Рекомендация W3C . Это стабильный документ, который может использоваться в качестве справочного материала или цитироваться из другого документа. Роль W3C в создании Рекомендации — привлечь внимание к спецификации и способствовать ее широкому распространению.Это увеличивает функциональность и совместимость Интернета.
Публикуя эту Рекомендацию, W3C ожидает, что функциональные возможности, указанные в этой Рекомендации, не будут затронуты изменениями уровня 3 модуля значений и единиц измерения CSS или уровня 2 событий указателя. Рабочая группа будет продолжать отслеживать эти спецификации.
Чтобы прокомментировать, укажите проблему в репозитории W3C WCAG GitHub. Рабочая группа просит, чтобы комментарии общественности подавались как новые вопросы, по одной проблеме на отдельный комментарий.Вы можете бесплатно создать учетную запись GitHub для решения проблем. Если регистрация проблем в GitHub невозможна, отправьте электронное письмо по адресу [email protected] (архив комментариев). Комментарии, полученные по рекомендации WCAG 2.1, не могут привести к изменениям в этой версии руководящих принципов, но могут быть исправлены в исправлениях или будущих версиях WCAG. Рабочая группа не планирует давать официальных ответов на комментарии. Список поданных вопросов, а также Архив обсуждений списков рассылки РГ AG общедоступны, и будущая работа, проводимая Рабочей группой, может быть связана с комментариями, полученными по этому документу.
Этот документ был опубликован Рабочей группой по принципам доступности в качестве рекомендации.
См. Реализацию Рабочей группы отчет.
Этот документ был рассмотрен членами W3C, , разработчиками программного обеспечения и другими участниками W3C . групп и заинтересованных сторон, и одобрен Директором как Рекомендация W3C .Это стабильный документ, который может использоваться в качестве справочного материала или цитироваться из других источников. документ. W3C играет роль в создании Рекомендации, чтобы привлечь внимание к спецификации и способствовать ее широкому распространению. Это увеличивает функциональность и взаимодействие в Интернете.
Этот документ был подготовлен группа работает под W3C Патентная политика. W3C ведет публичный список любых патентов раскрытие информации сделано в связи с результатами группа; эта страница также включает инструкция по раскрытию патента. Лицо, которое действительно знает патент который, по мнению человека, содержит Essential Претензии должны раскрывать информацию в соответствии с раздел 6 Патентной политики W3C .
Данный документ регулируется технологическим документом W3C от 1 февраля 2018 г.
Содержание
- Реферат
- Статус этого документа
- Введение
- 0,1 Общие сведения о WCAG 2
- 0,2 WCAG 2 уровня руководства
- 0,3 WCAG 2.1 Вспомогательные документы
- 0,4 Требования для WCAG 2,1
- 0,5 Сравнение с WCAG 2.0
- 0.5.1 Новые возможности WCAG 2.1
- 0.5.2 Нумерация в WCAG 2.1
- 0.5.3 Соответствие WCAG 2.1
- 0.6 Более поздние версии рекомендаций по доступности
- 1. Воспринимаемый
- 1.1 Текстовые альтернативы
- 1.1.1 Нетекстовое содержимое
- 1.2 Мультимедиа, привязанные ко времени
- 1.2.1 Только аудио и только видео (предварительно записанные)
- 1.2.2 Субтитры (предварительно записанные)
- 1.2.3 Аудиоописание или альтернативные мультимедийные материалы (предварительно записанные)
- 1.2.4 Субтитры (живые)
- 1.2.5 Аудиоописание (предварительно записанное)
- 1.2.6 Язык жестов (предварительно записанное)
- 1.2.7 Расширенное аудиоописание (предварительно записанное)
- 1.2.8 Альтернативное аудио (предварительно записанное)
- 1.2. 9 Только звук (в реальном времени)
- 1.3 Адаптируемый
- 1.3.1 Информация и взаимосвязи
- 1.3.2 Значимая последовательность
- 1.3.3 Сенсорные характеристики
- 1.3.4 Ориентация
- 1.3.5 Определение цели ввода
- 1.3.6 Определить цель
- 1.4 Отличить
- 1.4.1 Использование цвета
- 1.4.2 Управление звуком
- 1.4.3 Контрастность (минимум)
- 1.4.4 Изменить размер текста
- 1.4.5 Изображения текста
- 1.4.6 Контраст (улучшенный)
- 1.4.7 Низкий или отсутствующий фоновый звук
- 1.4.8 Визуальная презентация
- 1.4.9 Изображения текста (без исключения)
- 1.4.10 Reflow
- 1.4.11 Нетекст Контрастность
- 1.4.12 Расстояние между текстом
- 1.4.13 Контент при наведении или фокусировке
- 1.1 Текстовые альтернативы
- 2. Работает
- 2.1 Доступна клавиатура
- 2.1.1 Клавиатура
- 2.1.2 Без ловушки клавиатуры
- 2.1.3 Клавиатура (без исключения)
- 2.1.4 Символ Сочетания клавиш
- 2.2 Достаточно времени
- 2.2.1 Регулировка времени
- 2.2.2 Пауза, остановка, скрытие
- 2.2.3 Нет времени
- 2.2.4 Прерывания
- 2.2.5 Повторная аутентификация
- 2 .2.6 Тайм-ауты
- 2.3 Захваты и физические реакции
- 2.3.1 Три мигания или ниже порога
- 2.3.2 Три мигания
- 2.3.3 Анимация из взаимодействий
- 2.4 Навигация
- 2.4.1 Обход блоков
- 2.4.2 Страница с названием
- 2.4.3 Порядок фокуса
- 2.4.4 Назначение ссылки (в контексте)
- 2.4.5 Несколько способов
- 2.4.6 Заголовки и метки
- 2.4.7 Фокус виден
- 2.4.8 Расположение
- 2.4.9 Назначение ссылки (только ссылка)
- 2.4.10 Заголовки разделов
- 2.5 Режимы ввода
- 2.5.1 Жесты указателя
- 2.5.2 Отмена указателя
- 2.5.3 Метка в имени
- 2.5.4 Срабатывание движения
- 2.5.5 Целевой размер
- 2.5.6 Параллельные механизмы ввода
- 2.1 Доступна клавиатура
- 3. Понятный
- 3.1 Читаемый
- 3.1.1 Язык страницы
- 3.1.2 Язык частей
- 3.1.3 Необычные слова
- 3.1.4 Аббревиатуры
- 3.1.5 Уровень чтения
- 3.1.6 Произношение
- 3.2 Предсказуемо
- 3.2.1 On Focus
- 3.2.2 При вводе
- 3.2.3 Последовательная навигация
- 3.2.4 Последовательная идентификация
- 3.2.5 Изменение по запросу
- 3.3 Помощь при вводе
- 3.3.1 Идентификация ошибок
- 3.3.2 Ярлыки или инструкции
- 3.3.3 Предложение ошибок
- 3.3.4 Предотвращение ошибок (юридические, финансовые, данные)
- 3.3.5 Справка
- 3.3.6 Предотвращение ошибок (все)
- 3.1 Читаемый
- 4. Надежность
- 4.1 Совместимость
- 4.1. 1 Анализ
- 4.1.2 Имя, роль, значение
- 4.1.3 Сообщения о состоянии
- 4.1 Совместимость
- 5. Соответствие
- 5.1 Интерпретация нормативных требований
- 5.2 Требования соответствия
- 5.2.1 Уровень соответствия
- 5.2.2 Полные страницы
- 5.2.3 Полные процессы
- 5.2.4 Способы использования технологий только с поддержкой доступности
- 5.2.5 Невмешательство
- 5.3 Заявления о соответствии (необязательно)
- 5.3.1 Обязательные компоненты Заявление о соответствии
- 5.3.2 Необязательные компоненты заявления о соответствии
- 5.4 Заявление о частичном соответствии — сторонние материалы
- 5.5 Заявление о частичном соответствии — язык
- 6.Глоссарий
- 7. Цели ввода для компонентов пользовательского интерфейса
- A. Благодарности
- A.1 Участники рабочей группы AG, активно участвовавшие в разработке этого документа:
- A.2 Другие ранее активные участники рабочей группы WCAG и другие участники WCAG 2.0, WCAG 2.1 или вспомогательные ресурсы
- A.3 Привлечение спонсоров
- B. Ссылки
- B.1 Нормативные ссылки
- B.2 Информационные ссылки
Введение
Этот раздел не является нормативный.
0.1 Справочная информация о WCAG 2§
Руководство по доступности веб-контента (WCAG) 2.1 определяет, как сделать веб-контент более доступным для людей с ограниченными возможностями. Доступность включает в себя широкий спектр нарушений, включая зрительные, слуховые, физические, речевые, когнитивные, языковые, обучающие и неврологические. Хотя эти рекомендации охватывают широкий круг вопросов, они не могут удовлетворить потребности людей со всеми типами, степенями и сочетаниями инвалидности.Эти правила также делают веб-контент более удобным для использования пожилыми людьми с изменяющимися способностями из-за старения и часто улучшают удобство использования для пользователей в целом.
WCAG 2.1 разработан в рамках процесса W3C в сотрудничестве с отдельными лицами и организациями по всему миру с целью предоставления общего стандарта доступности веб-контента, который отвечает потребностям отдельных лиц, организаций и правительств на международном уровне. WCAG 2.1 основан на WCAG 2.0 [ WCAG20 ], который, в свою очередь, основан на WCAG 1.0 [ WAI-WEBCONTENT ] и предназначен для широкого применения в различных веб-технологиях сейчас и в будущем, а также для тестирования с помощью комбинации автоматизированного тестирования и оценки человеком. Для введения в WCAG см. Обзор рекомендаций по обеспечению доступности веб-контента (WCAG).
Существенные проблемы возникли при определении дополнительных критериев для решения проблем когнитивных, языковых и обучающихся нарушений, включая короткие сроки разработки, а также проблемы в достижении консенсуса в отношении тестируемости, реализуемости и международного рассмотрения предложений.Работа в этой области будет продолжена в будущих версиях WCAG. Мы рекомендуем авторам обращаться к нашему дополнительному руководству по улучшению интеграции для людей с ограниченными возможностями, включая обучаемость и когнитивные нарушения, людей с ослабленным зрением и т. Д.
Доступность в сети зависит не только от доступного контента, но и от доступных веб-браузеров и других пользовательских агентов. Инструменты разработки также играют важную роль в доступности Интернета. Обзор того, как эти компоненты веб-разработки и взаимодействия работают вместе, см .:
0.2 WCAG 2 уровня руководства§
Люди и организации, использующие WCAG, широко варьируются и включают веб-дизайнеров и разработчиков, политиков, агентов по закупкам, учителей и студентов. Чтобы удовлетворить меняющиеся потребности этой аудитории, предоставляется несколько уровней руководств, включая общие принципы , общие руководящие принципы , проверяемые критерии успеха и богатую коллекцию из достаточных методов , методик рекомендаций и задокументированы общие сбои с примерами, ссылками на ресурсы и кодом.
Принципы — Вверху находятся четыре принципа, которые составляют основу веб-доступности: понятный, работоспособный, понятный и надежный . См. Также «Понимание четырех принципов доступности».
Руководящие принципы — Под принципами находятся руководящие принципы. В 13 рекомендациях изложены основные цели, над которыми должны работать авторы, чтобы сделать контент более доступным для пользователей с различными ограниченными возможностями.Руководства не поддаются тестированию, но обеспечивают основу и общие цели, чтобы помочь авторам понять критерии успеха и лучше применять методы.
Критерии успеха — Для каждого руководства предоставлены проверяемые критерии успеха, позволяющие использовать WCAG 2.0 там, где необходимы требования и тестирование на соответствие, например, в проектных спецификациях, закупках, нормах и договорных соглашениях. Чтобы удовлетворить потребности различных групп и различных ситуаций, определены три уровня соответствия: A (самый низкий), AA и AAA (самый высокий).Дополнительную информацию об уровнях WCAG можно найти в разделе «Общие сведения об уровнях соответствия».
Достаточные и рекомендательные методы — Для каждого из руководящих принципов , и критериев успеха в самом документе WCAG 2.0 рабочая группа также задокументировала широкий спектр методов . Эти методы информативны и делятся на две категории: достаточных для соответствия критериям успеха и рекомендательных .Консультационные методы выходят за рамки того, что требуется индивидуальными критериями успеха, и позволяют авторам лучше выполнять рекомендации. Некоторые рекомендательные методы устраняют барьеры доступности, которые не охватываются проверяемыми критериями успеха. Если известны общие отказы, они также документируются. См. Также Достаточные и рекомендательные методы в понимании WCAG 2.0.
Все эти уровни руководств (принципы, руководящие принципы, критерии успеха, а также достаточные и рекомендательные методы) работают вместе, чтобы предоставить рекомендации о том, как сделать контент более доступным.Авторам рекомендуется просматривать и применять все слои, которые они могут использовать, включая рекомендательные методы, чтобы наилучшим образом удовлетворить потребности как можно более широкого круга пользователей.
Обратите внимание, что даже контент, соответствующий наивысшему уровню (AAA), не будет доступен для людей со всеми типами, степенями или сочетаниями инвалидности, особенно в области когнитивного языка и обучения. Авторам рекомендуется рассмотреть весь спектр методов, включая консультативные методы, а также обратиться за соответствующими советами по текущим передовым методам, чтобы обеспечить доступность веб-контента для этого сообщества, насколько это возможно.Метаданные могут помочь пользователям найти контент, наиболее подходящий для их нужд.
0.3 WCAG 2.1 Подтверждающие документы§
Документ WCAG 2.0 разработан для удовлетворения потребностей тех, кому нужен стабильный технический стандарт, на который можно ссылаться. Другие документы, называемые вспомогательными документами, основаны на документе WCAG 2.0 и предназначены для других важных целей, включая возможность обновления для описания того, как WCAG будет применяться с новыми технологиями. Подтверждающие документы включают:
Как познакомиться с WCAG 2.1 — Настраиваемый краткий справочник по WCAG 2.1, который включает все рекомендации, критерии успеха и методы, которые авторы могут использовать при разработке и оценке веб-контента. Сюда входит контент из WCAG 2.0 и WCAG 2.1, который можно фильтровать различными способами, чтобы помочь авторам сосредоточиться на соответствующем контенте.
Понимание WCAG 2.1 — Руководство по пониманию и внедрению WCAG 2.1. Для каждого правила и критерия успеха в WCAG 2 есть краткий документ «Понимание».1, а также ключевые темы.
Методы для WCAG 2.1 — Набор методов и типичных сбоев, каждый в отдельном документе, который включает описание, примеры, код и тесты.
Документы WCAG — Схема и описание того, как технические документы связаны и связаны.
См. Обзор рекомендаций по обеспечению доступности веб-контента (WCAG) для описания WCAG 2.0 вспомогательные материалы, включая образовательные ресурсы, связанные с WCAG 2. Дополнительные ресурсы, охватывающие такие темы, как экономическое обоснование доступности веб-сайтов, планирование реализации для повышения доступности веб-сайтов и политики доступности, перечислены в ресурсах WAI.
0.4 Требования к WCAG 2.1§
WCAG 2.1 соответствует набору требований для WCAG 2.1, которые, в свою очередь, наследуют требования WCAG 2.0. Требования структурируют общую структуру руководств и обеспечивают обратную совместимость.Рабочая группа также использовала менее формальный набор критериев приемлемости для критериев успеха, чтобы гарантировать, что критерии успеха аналогичны по стилю и качеству критериям WCAG 2.0. Эти требования ограничивали то, что можно было включить в WCAG 2.1. Это ограничение было важно для сохранения его природы как точечной версии WCAG 2.
0.5 Сравнение с WCAG 2.0§
WCAG 2.1 был инициирован с целью улучшить руководство по доступности для трех основных групп: пользователей с когнитивными или обучающимися нарушениями, пользователей с ослабленным зрением и пользователей с ограниченными возможностями на мобильных устройствах.Было предложено и оценено множество способов удовлетворения этих потребностей, и ряд из них был уточнен Рабочей группой. Структурные требования, унаследованные от WCAG 2.0, ясность и влияние предложений, а также сроки привели к окончательному набору критериев успеха, включенных в эту версию. Рабочая группа считает, что WCAG 2.1 постепенно продвигает руководство по доступности веб-контента для всех этих областей, но подчеркивает, что не все потребности пользователей удовлетворяются этим руководством.
WCAG 2.1 основан на WCAG 2 и обратно совместим с ним.0, что означает, что веб-страницы, соответствующие WCAG 2.1, также соответствуют WCAG 2.0. Авторы, от которых согласно политике требуется соответствие WCAG 2.0, смогут обновлять контент до WCAG 2.1 без потери соответствия WCAG 2.0. Авторы, соблюдающие оба набора рекомендаций, должны знать о следующих различиях:
0.5.1 Новые функции в WCAG 2.1§
WCAG 2.1 расширяет WCAG 2.0, добавляя новые критерии успеха, определения для их поддержки, инструкции по организации дополнений и пару дополнений в раздел соответствия.Такой аддитивный подход помогает прояснить, что сайты, соответствующие WCAG 2.1, также соответствуют WCAG 2.0, тем самым выполняя обязательства соответствия, специфичные для WCAG 2.0. Рабочая группа по рекомендациям по обеспечению доступности рекомендует сайтам принять WCAG 2.1 в качестве своей новой цели соответствия, даже если формальные обязательства упоминают WCAG 2.0, чтобы обеспечить улучшенную доступность и предвидеть будущие изменения политики.
Следующие критерии успеха являются новыми в WCAG 2.1:
Многие из этих критериев успеха ссылаются на новые термины, которые также были добавлены в глоссарий и являются частью нормативных требований критериев успеха.
В разделе «Соответствие» третье примечание о вариантах страниц было добавлено к полным страницам, а опция для машиночитаемых метаданных добавлена к дополнительным компонентам заявления о соответствии.
0.5.2 Нумерация в WCAG 2.1§
Во избежание путаницы для разработчиков, для которых важна обратная совместимость с WCAG 2.0, новые критерии успеха в WCAG 2.1 были добавлены в конец набора критериев успеха в их рекомендациях. Это позволяет избежать необходимости изменять количество разделов критериев успеха из WCAG 2.0, что может быть вызвано вставкой новых критериев успеха между существующими критериями успеха в руководстве, но это означает, что критерии успеха в каждом руководстве больше не группируются по уровню соответствия. Порядок критериев успеха в каждом руководстве не подразумевает информацию об уровне соответствия; только индикатор уровня соответствия (A / AA / AAA) по самому критерию успеха указывает на это. Краткий справочник WCAG 2.1 предоставляет способы просмотра критериев успеха, сгруппированных по уровню соответствия, а также многие другие параметры фильтрации и сортировки.
0.5.3 Соответствие WCAG 2.1§
WCAG 2.1 использует ту же модель соответствия, что и WCAG 2.0, с несколькими дополнениями, которые описаны в разделе «Соответствие». Предполагается, что сайты, соответствующие WCAG 2.1, также соответствуют WCAG 2.0, что означает, что они соответствуют требованиям любых политик, которые ссылаются на WCAG 2.0, а также лучше удовлетворяют потребности пользователей в текущей сети.
0.6 Более поздние версии Руководства по обеспечению доступности §
Параллельно с WCAG 2.1, рабочая группа по рекомендациям по доступности разрабатывает еще одну основную версию рекомендаций по доступности. Ожидается, что результатом этой работы будет более существенная реструктуризация руководства по доступности веб-ресурсов, чем это было бы реалистично для точечных выпусков WCAG 2. Работа следует ориентированной на исследования методологии проектирования, ориентированной на пользователя, для получения наиболее эффективного и гибкого результата. , включая роли авторинга контента, поддержки пользовательских агентов и инструментов авторинга. Это многолетняя работа, поэтому WCAG 2.1 необходим в качестве временной меры для предоставления обновленного руководства по доступности в Интернете, чтобы отразить изменения в сети с момента публикации WCAG 2.0. Рабочая группа может также разработать дополнительные промежуточные версии, продолжая WCAG 2.2, в аналогичный короткий срок, чтобы обеспечить дополнительную поддержку, пока основная версия будет завершена.
1. Воспринимаемое §
Информация и компоненты пользовательского интерфейса должны быть представлены пользователям так, как они могут воспринимать.
Указание 1.1 Альтернативный текст §
Предоставьте текстовые альтернативы для любого нетекстового содержимого, чтобы его можно было преобразовать в другие формы, которые нужны людям, например, крупный шрифт, шрифт Брайля, речь, символы или более простой язык.
Критерий успеха 1.1.1 Нетекстовое содержимое§
(Уровень А)
Все нетекстовое содержимое, которое предоставляется пользователю, имеет текстовую альтернативу, которая служит аналогичной цели, за исключением ситуаций, перечисленных ниже.
- Элементы управления, вход
Если нетекстовое содержимое является элементом управления или принимает вводимые пользователем данные, то у него есть имя, описывающее его назначение.(См. Критерий успеха 4.1.2 для дополнительных требований к элементам управления и контенту, который принимает вводимые пользователем данные.)
- Временные СМИ
Если нетекстовый контент — это медиа, основанное на времени, тогда текстовые альтернативы, по крайней мере, обеспечивают описательные идентификация нетекстового контента. (Дополнительные требования к носителям см. В Руководстве 1.2.)
- Тест
Если нетекстовое содержимое является тестом или упражнением, которое было бы недопустимо, если бы оно было представлено в тексте, тогда текстовые альтернативы, по крайней мере, обеспечивают описательную идентификацию нетекстового содержание.
- Сенсорное
Если нетекстовое содержимое в первую очередь предназначено для создания определенного сенсорного опыта, тогда текстовые альтернативы, по крайней мере, обеспечивают описательную идентификацию нетекстового содержание.
- КАПЧА
Если целью нетекстового контента является подтверждение того, что контент доступен человек, а не компьютер, затем текстовые альтернативы, которые идентифицируют и описывают указывается цель нетекстового контента, а также альтернативные формы CAPTCHA с использованием режимов вывода для различных типов сенсорного восприятия предусмотрены разные инвалидности.
- Украшение, форматирование, невидимое
Если нетекстовое содержимое является чистым украшением, используется только для визуального форматирования или не представляется пользователям, то оно реализуется таким образом, что вспомогательные технологии могут его игнорировать.
Руководство 1.2 Временные СМИ§
Предоставить альтернативы для средств массовой информации, основанных на времени.
Критерий успеха 1.2.1 Только аудио и только видео (предварительно записано) §
(Уровень А)
Для предварительно записанных Только аудио и предварительно записанные только видео носители справедливы, кроме случаев, когда аудио или видео являются медиа-альтернативой для текста и четко обозначены как таковые:
- Только предварительно записанное аудио
Предоставляется альтернатива для временных носителей, которая представляет эквивалентную информацию для предварительно записанного только аудиоконтента.